May 16-19, 2016, Propeller, Public Lab, IDIYA, and Water Works hosted an event to invite communit...
Public Lab is an open community which collaboratively develops accessible, open source, Do-It-Yourself technologies for investigating local environmental health and justice issues.
Public Lab chatroom
Reset your password
Read more: publiclab.org/n/13170
May 16-19, 2016, Propeller, Public Lab, IDIYA, and Water Works hosted an event to invite community members to participate in a flood sensor build challenge. The premise was that flood sensing could help the City of New Orleans track where street flooding is occurring throughout the city, which will help public safety, City services, and the community stay safe and make informed decisions during rainstorms. (For background information on this issue see the Depth/Flood sensing in New Orleans wiki)
The first day of the event included a panel with two representatives from the city, an engineer from Public Works, and the founder of I See Change. Some of the questions discussed included:
People who came to this event also explored the questions:
The panelists discussed challenges of shared governance, validating data, and the limitations of social media reports. The City perspective included wanting to gather as much data as possible at the lowest cost, noting examples of other cities that used sensors to collect everything from weather data to whether gunshots were fired. Of those who attended many people discussed issues around how they were personally affected by flooding, these included: transportation issues and the safety around it, flooded cars, hidden potholes, clogged street drains, sewage overflows, property damage, and related stress. Issues they noted through the city were: traffic problems, EMS delays, commercial flooding, and closing schools.
In the second day of the event participants gathered at the IDIYA maker space to build out a version of a depth sensor that uses an adafruit ultrasonic rangefinder.
IDIYA started the workshop out with an introduction to arduino, over the next two days, makers from IDIYA finished this project and brought a version to the last day reflection. The tool that came out of this is probably able to measure changes in water depth up to a millimeter in accuracy, however, its power needs and price was slightly more than the tool explored in the second day.
There were several questions around :: What were the real issues behind the problem? Here are some major issues that were identified:
The second build day we met at IDIYA again and built out the Public Lab Coqui version. Unlike day one, this version is based off a breadboard design with basic circuitry and uses a capacitor to detect the depth of water.
Rami Diaz's design for a sensor that could indicate the presence of water
If you break down the questions that were asked in build day one, it becomes clear that we’re looking for different tool options to answer different questions. For example:
Emergency: can I use the underpass?
What sensor: simple local switch
What data communications modality: local display, blinking sign
Power: low power, only turns on when switch is flipped
Data Access: no need
Format: Flooded man image
Where to put them? Only in underpasses
Model verification, is the model the city uses correct?
What sensor: higher precision sensor
What data communications modality: local data storage
Power: higher power
Data Access: city
Format: calibrated water data
Where to put them? Cross section, triangulate them
EMS, where can the emergency vehicles go?
What sensor: simple, but robust sensor
What data communications modality: real time communication
Power: higher level
Data Access: only EMS or city
Where to put them? Based on the model
In our wrap up event we hosted a roundtable discussion. For those who attended the build days, it became clear that we had not picked one simple question that we wanted a tool to help us advocate for. However, as one participant put it, “building clarified where there were still open questions.” So for the last day we posed the question:: “What is the one question you want a flood sensor to answer?” Below is what we heard:
Over the course of the four days, a lot happened. It was exciting to see interest from so many stakeholders coming to the table on the issue. One thing that was noticeable was that: of the people who came on the first day and spoke on the panel about the issue, only one came to the build days where we dove deeper into the questions and how to address them. Several underlying issues emerged such as:
From a Public Lab point of view, participants who define the problems statement should also be the ones who help to work towards the answer. They know the issue best, are vested in the outcome and can further articulate the necessities and nuances of solving the problem as we work through tool development ideas. As we progressed into the event from the first day, different flood sensing questions came up, and each could potentially have a tool array that fit the use the best.
Participants who came to the event had different needs, interests and expectations in what everyone:
Some expectations people had included:
While everyone got something out of the event, having a broad needs, interests and expectations made it challenging.
Some things went really well, some things could have gone better, but that’s characteristic of any event! Some of the challenges we had in organizing the event were:
Before the event:
During the event:
You must be logged in to comment.