Author: zemingbh

Sunday

• Worked on design review report

Monday

• Worked on the design review report.
• Further refined the testing procedures. Interestingly one of the things brought up during the design review presentation will help a lot with testing. The fact that the speedometer will be connected to the Pi via an Arduino will enable easier testing because bicycle speed can be simulated simply by programming the Arduino to report a certain speed.
• Noticed from looking at vehicle system testing procedures that generally very few tests are carried out. The primary metric is the time and distance at which the warnings go off, and whether warnings persist all the way through the danger. So the test were designed similarly to have the main metric for a successful test be the time-to-impact when the warning goes off and the persistence of the warning.

Wednesday

• Started working on the Bluetooth interfaces between the Pi and the rest of the system. Worked on hashing out the communication needs and protocol between the Pi and the Arduino on the jacket.
• Realised the communication needs between the Pi and the jacket are not very significant, and some communication requires guaranteed transmission while some communication just needs to get to the jacket quickly and can just be constantly transmitting. Will be interesting to see how the Bluetooth can be utilized for this.

Saturday

• Starting working on the LKM for the Pi. Need to get interrupts going for the ultrasonic sensors.

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.