Better Hardware, Better Research - workshops
Workshops on low-cost, open-source "community sensing"
This workshop was organised by the Floods and Droughts Research Infrastructure project; Jo's attendance was supported through the Software Sustainability Institute Fellowship
The workshop was organised by members of Wouter Buytaert's research group at Imperial - Luke Tumelty and Tom Rowan. They're central to the "Innovation" work package of the Floods and Droughts Research Infrastructure project. (I've done a small amount of work on an unrelated part of FDRI, on an open source library to manage proprietary dataloggers that are used in the key sites).
This group come from a background in running participatory, community science projects, often with a developing world focus. Their engagement with open source hardware stretches back a decade, and their Riverlabs project is an effort to spin out a commercial entity to keep up with research demand for their prototypes.
Their process is full of the joy of discovery - being able to produce the same results at a larger scale for a fraction of the cost of the proprietary hardware common in their field. That process - learning the detail, starting with Arduino and Adafruit boards, then designing custom hardware, setting up their own local radio networks - comes across in how open source hardware for environmental sensing is presented. As researchers they've become caught up in the technology, learned to swim in it, but that's come at the expense of their science.
The workshop also serves as stakeholder engagement and community building. FDRI is a big ambitious infrastructure with a lot of support. The aims are not only to build a prototype river monitoring and data dissemination network, but to welcome others into it - offering open access to data and also to installations, working with different groups - whether focused on research, national-scale government agencies, local authorities or charities - to onboard their sensor hardware.
The workshop lasted two days; hosted in a hall on-site in a community farm where the group has a sensor network installed for trials, along the River Chess, a small chalk river. The activity was mostly very structured - presentations about hardware design, network design, their reasoning for pursuing this path - interspersed with hands-on exercises based on a kit - learning to work the Arduino IDE, running and modifying the built-in examples on an Arduino, a Feather M0 and the Riverlabs custom board, the latter with material from the UNESCO Open Hardware Cookbook developed for previous teaching.
There was a real mix of backgrounds - from some people doing their own prototyping, through to folks who had never written code or wired up a sensor before. But no-one struggled (apart from the inevitable restrictions installing programs on corporate hardware) - the couple of us who had signed up as helpers were hardly needed - the exercises were well structured and prepared.
I was wishing I'd brought more with me - I have a sensor starter kit at home that I've mostly used with the Pi Pico, but I'd been on the road for a few days and all I had in my makeup bag were the ESP32 with LoRa hat birdbox workshopthe more involved sensors I'm still trying to get a handle on, the MEMS microphone, the accelerometer-gyroscope. But I did have a NeoPixel LED strip with me, and was glad to offer this to the small group that were way ahead on the exercises to play with; it's a good conversation-starter.
There was a "pitch session" in the middle of Day 2 for people to share their problems and ideas. There were still open slots so I brought out the card deck based on the Matrix of Convivial Technology paper that I'm starting to work on - a workshop prop to help people identify and plan to avoid unintended consequences of their technology work - talked about its origins, and the link to Catwigs cards that started at Bristol Hackspace. I got to try them out once, listening to Wouter describe the FDRI infrastructure and picking out cards that fit the story. And was offered a reference to the fantastic-looking work of Chris Skinner who has specialised in developing tabletop games for geoscience themes with a flood community management focus. A lot to follow up on there.
Lessons learned
Having had this experience, I would introduce simple sensors earlier in the process. We got well into the weeds of writing to EEPROM, integrating an SD card, while this is all valuable as a "look how approachable this is" for people who are already working with high-cost proprietary devices, it shifts the focus away from the applications ("what are we trying to understand?") to the integration ("what can we build?")
Pat Devine from Slow the Flow in Hebden Bridge had a fascinating pitch for a web-based generator for Arduino code - add and configure new probes quickly with a form-based interface, generate code behind the scenes, abstract away the build tools which can be both awkward to work with and not offer a clear path to automation for scaling up experiments and keeping them reproducible.
The "design session" at the end was a very free-form, small-group conversation. I'd have liked a way to keep this more hands-on - chat while working alongside on something, rather than sit for an ideation session. But this came late on the second day, by which point most people had already taken a lot in. The Nature Listening workshop opened with this - a paper-based, poster-drawing exercise first to encourage people to think about how they think about birds, what they'd like to understand about them better, before moving onto setting up acoustic sensors with Raspberry Pis
This was very much oriented to people already working in hydrology, with strong ideas about the problems they have and are trying to solve. I learned a bit by inference - ultrasound depth sensors mounted under bridges to give you continuous readings of river levels along a network, soil moisture sensors set back along banks at set distances to feel the impact on the land after a flood subsides, floating turbidity sensors to offer you a picture of the strength of current more immediate than you could get from imagery. I learned a lot about the challenges of testing circuits designed to work near water in flood conditions. But coming to this as a technologist I could have done with a picture being drawn of the things hydrologists take for granted.
Day 2 was a kit assembly rather than an experimentation. Satisfying but also lacking flexibility - a fully realised single-purpose prototype rather than an unfinished work with potential. The piece I'm really interested in that's still work-in-progress is this, the "rubber duck" - a buoy with a £8 turbidity sensor that's a replacement part for dishwashers. Once you've got the buoy floating out there, what else can you do with it? Would an onboard microscope make sense, if you could miniaturise a FlowCam and look at water samples, or add Ph and salinity sensors into the vehicle? What would you learn by installing a Hydromoth underwater microphone in there, how could you compress what it senses enough to travel over low-power local radio? What would you gain by networking a river-bound sensor with a bank-based one, and where do you stop?
There were plans to install devices created during the workshop under a bridge next to the venue - ironically, this couldn't happen because the water levels were too high! But there was a walk across the farm to see one deployed nearby along with the Rubber Duck. And this seemed to prompt the most engaged conversation about potential sites, purposes and extensions. It was a lovely opportunity to do this work in a real field site rather than a lab.
text notes from Tom Rowan's talk full of insights about hydro sensor design
