Result
Overall the project was executed successfully in measuring the water level and communicating these values to the server to be displayed on the flood wall. Various levels of testing were implemented on the system. Initially we tested the performance of the system by moving an object from the ultrasonic sensor and the result was precise. Later we tested the system on the river prototype model which also resulted in good performance. Also, the LEDs were correctly synchronized with the increase or decrease in the water level and performed accurately in communicating the change in the river height.
Through this project we had a wonderful oppurtunity to work with the Landscape Architecture department and have an actual industry like experience. We also feel an extension of this project by integrating other sensor systems like fish detection can have a huge environmental impact and could potentially save the endangered fish species and thus we are grateful we had an oppurtunity to work on such an impetus cause.
Conclusion
The project progress was on-track for most of the weeks but we ran into multiple issues at times and had to spent extra hours in resolving them. Listing out the few major issues or challenges we faced:
Sensor setup: Setting up the sensor was the first part of the project and it apparently took more time than expected. We understood the ultrasonic working and made the connections quickly but it wasn’t detecting any obstacle as were not able to observe any callback event to ECHO pin of RPi0. We tried different delay times, used different types of objects but it didnt help. We tried different power supplies for the sensor but that also didnt help. As advised by the professor, we also checked previous years projects to see if our code was having bugs, but we didnt find anything suspicious. Finally we changed the breadboard also to make sure we are not missing out on anything, which didnt help either. At the end, we decided to use a different sensor which made the difference. It means that everything was right with the circuit and the code, and only non-working component was the sensor itself. We learnt that we should try replacing the most critical component first whenever the things go wrong.
2. Charlieplexing: The display system at the client side, which was based on charlieplexing of 4-pins, turned out to be more complex than expected. We first implemented the circuit on breadboard and tested it thoroughly. Then we moved on to implement it on the PCB via soldering. It took a significant amount of effort to finish the whole implementation but unfortunately few of the LEDs were not working properly at the end. Luckily, we didnt remove the breadboard circuit which we implemented at the start, and simply replaced it PCB board with it. We would have preferred to have used PCB since it is more robust but the with proper wire insulation and bread-boarding, we were able to make the breadboard work perfectly.
3. RPi-3 crashdown: We ran into a major logistic issue just three hours before the demo. Our system was working perfectly and we were giving the final touch-ups to our design when we ran into that issue. We suddenly observed that the Raspberry-Pi 3 (base station) is not able to receive messages via bluetooth. On rebooting the board and running startx command, it gave the error’ Xinit server failed‘. We were out of ideas at that time on how to debug the issue. Luckily, we had been pushing our codes on github regularly and we also had backups from our previous labs. So we took the backup of Lab3 which had non-RT based kernel and pulled the code from github. We had to spend some more time in re-installing bluetooth libraries and setting up the connection with the client but we were able to get the system up and running within time.
4. Out-of-range sensor values:We observed a peculiar behaviour while sensing the water-level and sending it via bluetooth. Initially, both the RPIs were connected to the monitors to properly track the values being received from the ultrasonic sensor and the values received by the server. At that time, the values were very accurate and varied according to the water-level changes. But as we removed the monitor from the client RPi, we observed a significant noise in the sensor readings. The observation was 100% reproducible i.e. as the monitor was connected back, the sensor values became proper and noise came back when monitor was disconnected. As discussed with the professor, we think the RPi is waiting for an HDMI connection by default which might cause some unbounded delay in sensor processing. When HDMI is connected, the wait is avoided and sensor might be getting more processing time by CPU. We could have tried to configure the HDMI setting in the board but couldn’t do it due to the lack of time.
Future Work
There is a large scope for extension in this project. The model that we have developed basically completes the entire loop of the responsive floodplain idea but still it is an initial prototype. One major scope for extension is connection of multiple sensors since the current system can support multiple clients. There is also a wide scope for the type of sensors that could be included like for example detecting water quality in terms level of oxygen and nitrogen which can be extremely useful especially considering the impact of globalization on river ecology. Also, Susquehanna river is home to many endangered fish species and developing effective fish detection sensors by utilising RFID tags can also have prudential impact on protecting the river ecology.
Additionaly, the water level detection sensor that we have used can be replaced by LIDAR sensors to enable more accurate and precise readings when the model is to be implemented on the real river. Also bluetooth can be replaced by radio communication to enable long distance interaction between the flood wall and the sensor systems. Overall we believe by implementing necessary changes the responsive flood plain model can definetely have a significant impact in strongly connecting the community with the river environment and thus enabling mutual benefits for both.
Work Distribution
Anwitha Paruchuri: Worked on getting the LED system running by desgning and building of the charlieplexing circuit. Also worked on setting up of the ultrasonic sensor to measure the change in the water levels and helped in the overall hardware assembly of the sensor model essentially the integration of the ultrasonic sensor with the LED system. Also helped in designing the display wall using python games to efficiently portray the communicated water level information.
Deepak Agarwal: Worked on Bluetooth socket programming and basically in getting the display wall and the sensor system to get integrated. Also worked on the designing of the display wall using python games and helped in the hardware bulding of the sensor prototype especially soldering of all the LEDs and mechanical assembly of the pipe. Also, helped in the LED system design and setting up of the ultrasonic sensor.
Website: Website work was divided and contributed equally by both.