Month: February 2019

Sunday:

• Implemented code on the Arduino for the speedometer. Built the circuit, tested the reed switch, implemented software debouncing for the switch, implemented the computation algorithm (the average of 4). The speedometer is essentially completed.
  TODO: Right now the Arduino simply transmits the speed over serial every second. When the RPi is up, make sure that only the latest value is transmitted and only when the RPi requests it. Also, make an interface to configure the wheel circumference.
• Worked more on the design document.
• I am concerned that the front LIDAR will not be accurate especially on bends.
• I am also concerned that the LIDAR will not work well against reflective cars.
• Tried to find research done on the effectiveness of car sensors. Seems like they don’t work particularly well. There is one by the National Highway Traffic Safety Administration on blind spots, and at the speeds CycleSafe is looking at it’s between a 3% to 20% delayed warning rate. The vehicle systems seem to prefer false negatives over false positives.
• The LIDAR on I2C works.

Thursday

• Estimated the power consumption of the bike and the jacket.
• Am concerned about the system being hard to put together on the bike itself (need mounting points, gluing, etc.)
• I was concerned that the front LIDAR will not be accurate when the bicycle is turning, but there’s a solution if that’s a problem. It would involve a compass on board the bike, obtaining the bearing of the road from the map API, and using accelerometers to determine the tilt of the bike. Given that the sensors are all securely fastened, then you would be able to determine exactly how the sensors are pointing with respect to the road. Then you can account for turn/tilt.
• Met with Prof Ken Mai, to discuss the power consumption requirements and weight.

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.

Tuesday night: Worked on testing the HC-SR04 ultrasound sensors and trying to see if a frontal collision pattern could be detected using the various algorithms I proposed. It worked very well sometimes and was rather noisy other times. I tried several different methods of filtering out the noise, mostly using low-pass filters, but they worked about as well as before. Nonetheless, it was a good test of the RPi-Arduino architecture on the bike, since I was using the Uno to control the ultrasound sensor and report distance values back to the Pi3, which ran the warning decision algorithm. The actual algorithm will be running with the LIDAR, not the HC-SR04, so noise will likely be less of a problem.

Wednesday morning: Helped out to figure out the Maps API problem.

Thursday afternoon: The LIDAR arrived!

Friday night: Worked on the rangefinder, speedometer and some of the Pi section in the design report. Figured out how many HC-SR04 sensors we need to use. Figured out that the Pi could actually handle the HC-SR04s, since the Arduino might have trouble with timing a lot of things at the same time. But it means we need to write an LKM.

Saturday: Tried to configure the LIDAR. Obtained a real bicycle speedometer and a reed switch. Will just use the reed switch instead of the Hall effect sensor for the speedometer. Made the circuit.

Schedule:

Caught up a little, still slightly behind because had to write up a lot in the report. However, design is a lot clearer now. Will work more this coming week.

Targets:

Make a working rangefinder frontal collision demo for Monday. Decide if we should order the rest of the rangefinders by Wednesday. Test and see if the rangefinder works well on glossy vehicles. Figure out the physical layout and position of the sensors on an actual bicycle, using my bicycle.

Accomplishments:

• Worked on Bluetooth module communication with mobile device
• Worked on Maps intersection detection API
• Wrote Arduino code for all peripherals
  • Piezo Buzzer, controlled sound and created notification sounds
  • Cell phone vibration motors
  • LED Matrix data
  • Bluetooth module
• Worked on design documents
  • Created LaTeX template for the report
  • Created specifications for power and refresh rate needed for peripherals

Future work needed on making a more solidified Bluetooth communication scheme, since right now it is very impromptu on how devices are triggered.

Also, I need to minimize the latency of how all the devices respond, while making communication still as readily available as possible.

Upcoming Work:

Some of the improvements I mentioned above I’d like to work more on. In addition, the major next step is to actually install the devices on a jacket. This will bring challenges for how to make the devices fit well while also working properly.

Some risks I foresee are that the devices will be very hard to power on low power. Fortunately, we should be using the bike for power for now, so power is not too much of an issue. Also, I am a bit worried about how comfortable devices will be on a wearable, and whether they will work well once they have to move around a lot with the wearer of the jacket.

Schedule:

On schedule, except for the LED strips which didn’t arrive. Since I already have a prototype with code, they should be very easy to set up once they arrive.