Water is one of the world’s most stressed resources. Usage has shot up by more than double the rate of population increase, meaning we are guzzling more water per head than ever before.
The impending crisis - which has already created a “water war” in southern states of the US and been immortalised in award winning musical theatre production Urine Town - has prompted varied reactions, from cries over the privatisation of this most vital resource in reaction to the Water Sustainability Act in North America, to grass roots and stakeholder initiatives to improve water infrastructures, such as Clean Water Action and the UN’s Water Action Hub.
We have been researching water usage and the potential of environmental sensing for both home and remote use and have decided to develop an open hardware sensor that will allow users to measure how much water they are using, and have the option of taking part in a citizen science experiment on water usage. We are calling it Droplet.
Over the course of Droplet’s development we are going to be asking for feedback from the community to make sure we’re designing the best piece of kit that we can. For now, our design principles are that:
To the latter end, we’re designing different interface components to give different types of feedback, be that visual, audio, complex or simple. We’re also making sure that everyone can design interface components by making it easy to interact with the sensor component. Droplet will for example have the ability to store the measurement data locally or in online databases, but to prioritise users’ rights to privacy, they will be in control of the sharing and will opt-in rather than opt-out.
The citizen science element comes in if you do share your data. Shared data will allow us as a community to look at how different variables - such as length of monitoring, and type of feedback (live, latent, visual, audio, etc) - changes our water usage over time. Any data made available publically will be anonymised - and we’d like your feedback on that too as we progress with the design. And hopefully together we can find ways to enjoy water without having to feel guilty about what we’re using.
Our first meeting saw us playing with bike lights and open source Geiger counters, and talking about 3D prints and form factors. Sam is getting busy with the first steps to prototyping, while Kat is working on 3D designs for the form factor.
This is the first part of a series on tools for open collaboration. This first part will focus on managing content in an open way with collaborative editing platforms. In the next posts we’ll look at file sharing and document management, task management and communication tools.
One way I like to procrastinate is by trying to find betters tools. When things aren’t as smooth and natural as I would expect, then after a while I go for a round of search and trials, fill up comparison spreadsheets - like for project management software - or think about how to build tools to compare tools better (no really). I find it edifying to see how different people think differently about organising the way they work. Well that’s my justification anyway, sometimes it’s just me spending too much time thinking about doing rather than doing…
Our team is tech savvy, willing to experiment and push the boundaries of how we do things. For instance, with the Open Integrity index, we’ve tried to be as open as possible during the implementation of the project. In her art and writing, Kat is a supporter of Open Access publishing and Creative Commons. Sam is completely dedicated to the principles of sharing, such as his log about his time at Open Source Ecology, with the aim of allowing to build on top of what he’s done.
As when I start any new project, I’ve been researching the best ways to work together openly for Droplet. I’ve used different approaches for different projects, both to try them out and to cater for different audiences and teams. There are some great experiments out there to learn from: from the more business inspired to the more community driven.
Gittip’s founder - also one of the initiators of the (Open Company Initiative]()http://www.opencompany.org/about/) - made it a practice to hold partner calls “on air”. There are also some formal methodologies out there to implement an Open Design process like the Open P2P Design Toolkit - “a simple tool for helping people approach design thinking on a metadesign level”. Sounds simple to me! Though it would be nice to see the source for the toolkit on github…. And the Open Design Definition which however probably will focus on the nature of the knowledge shared rather than the processes that enable it.
Droplet aims to adhere to the principles of the current version (v0.3) of the Open Design Definition and in particular commits to ensure that the “source documentation is made publicly available so that anyone can study, modify, distribute, make, prototype and sell the artifact based on that design.” So then what about our processes and tools?
There’s a spectrum of choices out there from using “ready made” tools that are proprietary and cost money or to integrate various existing open source components to achieve desired functionalities. I’ll mention both approaches, but often in order to test if a process is the right one, it’s good to be up and running fast and online platforms can be a good way to do that. You can then migrate to open source tools when you know the process works for you.
For us text means rich text, our design documents, engineering documents, blog posts but also sometimes spreadsheet data like our budget data. Allow a team to work together on text during various moments in the project - when face to face, in a call, when we’re working separately - is a way to make sure you capture things as you go along and that people are on the same page.
Real-time collaborative editing is a good way to capture the important elements of a conversation and have a easy to access place where everyone can jot down their ideas without interrupting the conversation. In fact sharing links and pictures can help enhance a conversation as long as participants keep the right balance between face time and screen time.
We like Markdown and the alternate flavors of markdown because they allow you to write your formatting without interrupting your writing of content. I particularly like interfaces which format your text live - such as Penflip, but alsoFoldingText, Task paper is also an interesting variation on live formatting for task management - and I find them much better than interfaces that require to click on buttons to achieve the same goals, so while we started on google docs (because of the Google Drive integration, the Spreadsheet and the new Track Changes add-on) we’ve been looking into other approaches.
We also need versioning and commenting and ways to allow the public to contribute in these ways. Ideally we want to blur the lines between content publishing and collaborative documentation where various circles in the community contribute and have the permission to “publish” (which might mean the same thing as merging or accepting pull requests).
In summary the features we are looking for are:
I feel that the tools in this space have been changing fast in the past year. I think that organisations need to invent the processes that will work to make the most of them. I’ve been told before that the most important is to just put your code out there. You can’t claim to be “wanting to be open source” and have nothing out there for others to look at. There is a shyness and counter-intuitive thing about putting your unfinished work out there, but I find it’s a healthy practice, very much worth the effort. To be honest, we can’t claim to have any open source project that has garnered enough attention for it to reap the benefits of the collective intelligence and cognitive surplus pouring our way. But Panic Button might become that, and hopefully Droplet and our other projects too. Until then, it just puts the right sort of pressure on us to deliver better work and think more about how to engage with contributors beyong traditional boundaries of organisations, roles and status.
We’d really love to hear from you about your thoughts on open collaboration. Have you got a project where you’re trying similar things out? Is there anything you think we could improve on? At the moment the best way to do that is to comment here on the blog, submit a change to this blog post to improve it or contact us through firstname.lastname@example.org - but we’re going to continue to try to improve on those means too!
Open Droplet is by no means the first gizmo out there to measure water usage, and like anyone who is designing anything, we’ve had a good look at what’s out there. We’d like to share what we’ve found and open up the discussion to interrogate our own design decisions. We have stuck to non-invasive flow metres, as we would rather plumbing wasn’t required for fitting Open Droplet.
There are absolutely stacks of timers out there that measure how long you’re in the shower - some of them also have calibration so that they estimate - by timing your shower and multiplying this by the calibration constant you set at the beginning of your relationship with the device - how much water you’ve used. These don’t have a direct measurement component.We haven’t yet found one that is networked. They are quite different from what we’re trying to achieve with Open Droplet.
We’ve found one device, the waterpebble, that senses - we think through conductance, although it could be a motion sensor - when your shower turns on, and then works on a time based calculation to tell you when to stop showering. It iteratively decreases the advised shower time every time you shower and alerts you by a traffic light system. It doesn’t seem to have much of a presence any more and is no longer available on a number of its distribution platforms. A nice touch was that you don’t have to install it - it lives at the bottom of your shower basin.
There’s also the Sprāv, not yet to market, which is a networked sensor that uses a piezo to monitor flow and then indicates by a traffic light system when you should stop showering. It also has an app interface that collects and visualises the data for QS folks. The designers say there’s going to be an open API, but I’m not clear if the hardware is open.
Outside of the water sensing realm, there’s also the Open Energy Monitor which is very much aligned with our own approach of openness and also uses the Nanode (which our Lead Hardware Engineer Sam contributed to). We’re looking into their software stack to see if we could reuse an contribute to it.
Our first investigations into using piezos and accelerometres for measuring water usage, combined with a few experiments, led us to question the most feasible method of measuring flow in domestic settings. We’ve now decided to move towards a scaled series of prototypes, with the first responding automatically to flow, but not directly measuring the volume of water discharged.
Designing the Power Supply component
The water usage is then determined (after calibration) by the length of time for which the flow is detected… Which is to say, the first iteration of Open Droplet will be a bit like the timers we mentioned in a previous post - but below you’ll see how Open Droplet incorporates an automatic trigger, and will be networked so users can keep a record of their water use. In terms of networking, we’re looking at incorporating a hub (building on the Open Energy Monitor architecture) to store and relay information to the network.
Microphone, OpAmp and our new Ersa i’CON PICO soldering station
We are now in the middle of a 2 week development and experimentation period where Alex and Sam are doing wizardry with the hardware. The guys are using a microphone to detect water flow - it starts recording when it registers sustained noise at the right frequencies. It also saves power by only activating the relevant circuits after detecting flow, and will switch off when things quieten down in the bathroom.
For supplying power, we have plug and play battery charging system that can charge with the mini-USB plug (like you’d use for a phone or camera). It uses a linear regulator and an analogue system on a chip to control the charging rate. For the first prototype we’re using a phone battery (1S1P 1600mAh LiPo cell). We have been having discussions around the pay-off between the charging time and the amount of heat generated, and have sensibly decided on safety first - ie: a longer charging time, to avoid any (probably very exciting but maybe damaging) explosions.
Our Power System prototype: plug and play battery charging, linear regulator, analog SOC binary output, 1S1P 1600mAh LiPo cell
The next hurdle is around making the prototype waterproof, for which we’re thinking of encasing it in either epoxy of polyurethane by pouring the mixture directly onto the kit. We’d then have just the one weak n’ wet point - the usb connector for power - which we’d plug with a winged rubber cap. If that doesn’t work, we have a back-up plan involving screws, but more on that if we need to go there.
With encasing come a number of problems, not least overheating. So we’re going to be testing the two materials for acoustic and heat conductance in the first instance - and resilience to dropping, of course.
Elements of our workspace
Putting the prototype together