Tag: status report

This week was mainly focused on unit testing, holistic testing, and fixing any bugs with our project. We focused on issues dealing with the GPS system. In addition, we also made changes to our encasing. During our testing the device fell, which weakened the connection of our sensor to the acrylic case. We decided to apply more glue for a better stick, and extended the wire, so that there was less pressure pulling on the sensor when connected to the Raspberry Pi. 

Image: Broken Joint

Image: New Case

RISK:

One risk we noticed was that it takes a considerable amount of time for our GPS module to lock in with a satellite ( > 5 minutes ). So, we changed the orientation of the GPS module to see if that would result in a shorter connection time. This seems to have reduced the problem because we are able to connect to our device in less than 5 minutes. 

TESTING

We did comparative testing to see if the current location of users being shown by our gps script, matched that of which the user actually was. In order to have a reference point, we used the IPhone’s internal GPS as a standard measure of GPS accuracy.We used this to map out four points on each journey route we had, and measured the differences in latitude and longitude as a metric for the accuracy of the GPS module.

We ran 50+ tests this week with the doppler radar sensor to measure its field of view and accuracy. Through testing, we noticed the orientation of the sensor played a large part in how accurate the distance detection was so  removed the sensor from our encasing and changed the orientation. Also, the sensor had no false positives as it never detected an object that wasn’t there. Lastly, since the sensor’s FOV is so limited it’s best for our device to be attached slightly angled towards the left hand side of the user to get a better view of incoming objects as people usually take a wider angle when passing bicyclists and don’t come up directly behind them.

For our overall system testing , we spent a few hours this week riding a bike with Rid3 to collect data. We also simulated certain scenarios with a car and on another bike. Various kinks arose with testing off campus that we had to resolve throughout the week. Once again, one of our biggest setbacks was the bike mount piece broke while we were testing. The device fell and our encasing broke so I took time this week to put it back together and reprint a sturdier mount. This was an inadvertent strength test of our encasing as our device held up pretty well and there were no cracks in the encasing, we only had to attach the sides back together.

NEXT WEEK DELIVERABLES:

We will primarily be focused on wrapping up our project and preparing for the final demo. We will continue testing to ensure the product performs as expected.

 

This week, we made finished the integrating all our hardware pieces together. We have encasings for the raspberry Pi which is holding our GPS, battery, fan, and our distance sensor. We have the encasing for our wristband, which we can feel vibrations through when the sensor detects something in it’s field of view. We also decided to pivot from having a speaker + microphone attached to the raspberry Pi. Instead we are using a wireless headset which is acting as both a microphone and a listening device for the instructions. We were able to integrate this headset with the Raspberry Pi, using a bluetooth connection. After we got the encasings for all the devices we attached the connection to the gopro mount, and it is now able to be put on our bicycle for wholistic testing.

In terms of testing, we did more testing with our speech to text and our text to speech because we decided to use another speech model that was better for our bluetooth headset. This model also seemed to have more accuracy than the previous API we were using. We also tested our distance sensor to make sure it was good for detecting the motion of cars and when the user is in motion with the sensor.

RISKS:

There is potential strength of the connection piece for the mount not being strong enough to hold our device, so we need to see how it is riding quickly different terrain. There is also the risks of bluetooth connection not being the best with devices moving and every device being in encased, which could lead to choppy connection at times, but we will see with testing.

NEXT WEEK DELIVERABLES: 

Continuous testing for the device still needs to be done, testing with actual cars and different journeys. We also need to get varying user feedback on the practicality of the device. We will be working on final presentations and getting working demo videos out.

This week, we made solid progress on all subsystems of our project.

We were able to integrate all of our scripts and have them running simultaneously on the RPi4 . So, the GPS tracking, blindspot detection, and navigation instructions with voice recognition system are able to work together by using threading. The navigation script is able to get continuous updates of longitude and latitude from the GPS through a shared global variable.

There were many pivots with the wristband system. We replaced the Micro Arduino device for the wristband with the Blues Swan, which also has Arduino pairing capabilities. The reason for this change was due to the Swan including a PMIC accessible via a JST PH connector, this allows us to power the board with a LiPo battery but also recharge the battery if need be, through the USB port.  Additionally, we to changed our bluetooth system from operating with 2 HC-05 modules to using the RPi4 bluetooth and one HC-05 module because we were having trouble sending data with the previous setup. Lastly, one of the biggest changes we made was to switch from the ultrasonic sensors to the OPS243 Doppler Radar Sensor because during interim demo week the ultrasonic sensors were having connectivity issues. Also, it was apparent they would be insufficient in meeting in our use cases.

Our  audio and navigation components are integrated with our GPS tracking and we have been actively testing their accuracy and functionality by doing test routes ( ex. Porter Hall to Phipps Conservatory). Right now we have instructions being inputted manually but we are actively fleshing out kinks with the audio input.

We 3D printed our bike mount piece and got it to match the GoPro sizing and are actively working to have the wristband and main device encasing finished printed soon.

RISK:

In regards to the GPS subsystem, our encasing could potentially block satellite signals, if not positioned properly. Another separate risk, is the fact that HC-05 device and Bluetooth earbuds would need to be connected to the Raspberry Pi 4 simultaneously. Unfortunately, it may not be possible for the RPi to connect to multiple bluetooth devices. As a result, it is important that we spend sufficient time in attempting to integrate these bluetooth devices to the system to work at the same time. If that is not possible, then the audio aspects of the system will have to be done via a regular microphone and speaker that do not rely on Bluetooth connectivity. 

There is risk with our new sensors as well. There’s risk with the new OPS243 Doppler Radar Sensor because the field of view is very limited compared to the ultrasonic sensor. Although it’s fairly accurate in detecting incoming objects, its field of view to do so is very limited and poses a threat of objects being missed in a user’s blindspot. We might have to change or specify our guaranteed coverage zone in our final use case.

 

TESTING:

We are still early in our testing but overall it has been going well. We tested inputting a journey manually and having directions update based on a small sample set of GPS coordinates.  For our audio input portion we aim to test 5 different voices (from different people) for 20 different destinations within the Pittsburgh area and checking the accuracy from the output of the speech-to-text system. To test the navigation accuracy we’ll test multiple GPS coordinates on 10 different routes and check that the generated navigation instructions are accurate by comparing with the actual turns on a map. Our validation is ensuring that GPS coordinates are occurring in real-time and the navigation suggestion system is outputting the correct instruction.

In order to meet use case requirements such as users receiving audio instructions within 200 feet of a turn, the GPS system needs to accurately measure where the user is.  We’ve done a couple of bike trips to Phipps Conservatory and captured the longitude, latitude, and distance from turn for each of these trips to ensure the user is at the right location. Another test that has been done is putting the GPS sensor in a box, and reading GPS data while outside, to ensure that when the actual encasing is finished, we are not blocking GPS signals. We still need to test more locations and routes but so far testing as been going well and the results are aligning with our use case/

For the blind spot detection and wristband system, we have tested the basic functionalities. When stationary and indoors non moving objects infront of the sensors don’t trigger a wristband vibration but and incoming object at certain speed will.  Tested when objects are incoming at different angles relative to the sensor and it does have a more limited field of view than the ultrasonic sensors but it’s better at filtering out unnecessary objects. The wristband system is able to meet our use case in a limited setting. When the system is stationary, a vibration haptic feedback response is generated within a second of an incoming object being detected.  We still need to create an explicit plan to test the accuracy rate of the blindspot system. 

 

NEXT WEEK DELIVERABLES: 

We are primarily focused on extensively testing our subsystems independently.  We will  also work on getting all the encasings 3d printed to properly secure our project so that we can test our integrated systems on a bike.

 

Gantt