Risks
- Power requirements: There may be additional power needs for all the devices over what we initially thought. It really depends on the usage of the devices, because not everything is active all the time. This would be mitigated by using additional batteries, but this would add additional weight.
- Latency: For the Nano on the jacket, there may be latency trying to manage communication devices and PWM devices at the same time.
- Accuracy of Intersection Data: apparently Google Maps doesn’t have support for sending in intersection data, so we are using a separate API, and have to develop our own algorithm for figuring out which intersections we are approaching.
Updates
- The HC-SR04 sensors will go on the Pi and not the Arduino, since there are six of them. An LKM is necessary to insert interrupt service routines into the Pi’s kernel to time the HC-SR04 pulse. The Pi has sufficient GPIO pins to trigger interrupts on all six sensors; 2 pins per HC-SR04 is required, so 12 in total will be allocated to short-range sensing.
- The peripherals on the Arduino Nano work well individually and not under huge stress. A little concerned when there is high-stress on the commands the Nano receives, so we will need to develop a scheduling algorithm on the Nano to make sure it is not overwhelmed.
- The Mobile App works with Bluetooth very smoothly as expected. The next step is to build a more robust communication protocol with the Raspberry Pi.
- We found APIs to use with the Mobile app to find intersection and navigation data. They will be important as inputs to the Raspberry Pi as safety conditions.