Posted on

Team Status Report 11/12/2022

This week each of our team members spent most of their time polishing up their portions of the project and now plan to spend most of the remaining time collaborating and working on the routing/feedback features of the device. Colin finished most of the system level work to be able to output audio and interface with the cellular data network while on the go. Zach worked more on the routing/feedback functionality to be able to give good user feedback.

One of the hardest problems that our team is facing right now is the fact that we only have to avoid blind-unfriendly intersections if the user has to cross a crosswalk, otherwise the user could just continue on the sidewalk and turn down a different street. The APIs that we are using right now make it hard to incorporate that feature into our system so we are looking into the possibility of finding some sort of routing library that could help with this problem. As a last resort, our system would still be functionally correct if we did not route the user to these intersections, even if they did not have to cross a crosswalk, it may just create a more convoluted route for the user.

Next week we plan to incorporate the feedback into the physical device and run some simulations to be able to test the routing capability of the device, and hopefully have a device that we could walk a route and get feedback in real time.

Posted on

Colin’s Status Report for 11/12/2022

This week I worked on the system-level implementation of our project as well as improving the accuracy of the GPS unit. I played around with some configurations in the chip and changed to a configuration better suited for a person walking as opposed to a driving configuration which is default. With this different configuration, I gathered some extra route data that Zach and I can use to simulate a walk which should allow us to quickly debug and test our routing/feedback code.

I spent the majority of my time this week working on interfacing with the cellular data card, using the text-to-speech engine and outputting the audio form the pi to the user. By the end of next week I hope to be done with most of the system admin/device development so that Zach and I can collaborate more on incorporating the routing and feedback functionality into the device.

I finished most of what I hoped to do this week and I am happy with where I am on the schedule. At this point going forward I will be spending the majority of my time helping with the routing functionality and incorporating that into the pi.

Posted on

Zachary’s status report 11/5/2022

This week I began writing code to handle requests from the frontend while a person is on the trip. Specifically, I used an index to refer to the location in the cache, where the next checkpoint is for the individual, and I would take the coordinates given by the frontend to calculate the Haversine distance, which converts coordinates to meters. This is not completely done, because I still need to account for when I can increment the index, edge cases like telling the user that they need to wait for a (blind-friendly) crosswalk, and I need to come up with textual feedback to give back to frontend. I was also able to debug the Jupyter notebook app and display the routes I am planning for the user. I am also seeing that given a blind-unfriendly crosswalk, the route is successfully avoiding that crosswlak, which is good.

Tomorrow, I will work with Colin to implement a basic communication protocol between frontend and backend, for the interim demo on Monday.

Next week, I want to finish the request handling module and work more with Colin to develop the communication protocal between frontend and backend.

Posted on

Team Status Report 11/05/2022

This week our team was preparing for the interim demo that will be coming up next week. We built a physical device that contains all of the necessary hardware which will be capable of meeting the use case requirements. The device is able to generate geo-location data (latitude, longitude, and heading) along with a timestamp for each of the points. This data will be transmitted to the back-end routing thread to perform analysis on where the user currently is and where they need to go next.

For the demo next week we will show the physical device along with a visualization of a path that we walked with the device along some sidewalks. We also plan to show the ability for the device to generate a route that does not contain blind-unfriendly crosswalks, based off of the current coordinates of the device as a starting location.

Posted on

Colin’s Status Report for 11/5/2022

This week I made a lot of progress regarding building the device and gathering our first bit of test data. I decided to build the first (and possibly final) iteration of the device out of a lightweight aluminum casing material. This material provides strong structural support while also allowing us to hit our use case weight requirement. The aluminum also acts as a ground plane for our antennas, and I took particular care to make the dimensions of the box work well with the GPS antenna. The main frequencies that we will be using are 1.2GHz – 1.5GHz, which is a wavelength of about 10 inches. I made the dimensions of the box 10 inches (wavelength) by 5 inches (wavelength / 2) to attempt to get a better resonance and help with noise. I will look further into seeing if it is possible if we can use a particular band that would resonate better with the case because 1.2GHz – 1.5GHz is a fairly large range and it is impossible to tune to all frequencies in that range.

The case with all electronics not including the battery weighs ~18 ounces and the battery that we plan on using weighs ~14 ounces. This gives us a total weight of 32 ounces, which is under our use case requirement of ~35 ounces (1kg).

I used a 4000 mAh battery that I had to test with, however it will not be the battery that we plan on using in the end. For the 1-2 hours that I was using the battery, it only used up about 1/3 of it’s power which is a good sign and means that with the 26800 mAh battery that we plan to use, we should be able to hit our use case requirement of 16 hours of battery life.

I walked a route with the device to see if it gathers somewhat accurate data. Below is the route I walked, I started going down Forbes Ave towards the soccer field and then crossed the road and walked back up Forbes Ave. I gathered a location point once every second and used gpsvisualizer.com to visualize the data. It is obvious that I was walking down one side of the street and back up the other side of the street which shows that we have fairly good location accuracy. There are more settings and ways to increase the accuracy on the ZED-F9R GPS unit that I have not had a chance to change but they should get us even better results.


(The dotted line paths on the map is not data gathered by us, they are markers on the map for other purposes)

This week I accomplished most of my goals of gathering test data and building an iteration of the physical device to allow us to start gathering data. I did not end up buying the battery that we plan on using because I found one lying around that I was able to use to test with, and I will buy the real battery later on because the one that I have right now works well for testing. Next week I would like to collaborate more with Zach so that we can start incorporating more of the routing code into the device. I would also like to do more analysis on the heading of the device and see how accurate it is. The GPS device has different modes depending on the application, and I believe that if I use a different mode our results could be more accurate for the purposes of walking, so I would like to experiment with the GPS unit more next week.

Posted on

Zachary’s status report 10/29/2022

This week I finished implementing an initial iteration of initial routing and caching.  I implemented my cache using a list of lists, where the inner lists describe information about actions, which are verbal feedback from the HERE API, and coordinates of the next waypoint. I was also successfully avoid certain intersections using the API provided by here. The HERE API avoids areas by makign the user draw bounding boxes on the areas they want to avoid. For now, I’m drawing a 20m square around the intersection that needs to be avoided (I had to use lat/lng to meters conversion formula . I think this may cause issues like avoidin the entire street instead of just the intersection, but I will continue to look at that over the next few weeks.

HERE also has a map widget Jupyter Notebook that lets users visualize the routes they are drawing. Unfortunately even after spending several hours on it only a gray screen would pop up when I try to show the widget. I think this is a good testing tool so I will keep working on it and hopefully be able to display the widget.

Next week I want to create a communication protocol with Colin’s frontend code (integration), finish setting up the HERE map widget on Jupyter, and start implementing request processing from the frontend.

Posted on

Colin’s Status Report for 10/29/2022

This week all of our parts that we ordered came in and I was able to connect all of them to the RPI. I mainly worked on interfacing with the GPS/IMU. Zach and I think it would be a good idea if we could have something running by the end of this week that would allow us to gather location data while walking around. This way we can walk some routes and save the data so we can simulate walking the route at a later time for development purposes without having to physically be walking the route whenever we want to test.

This brings up the need for some mobile system that includes a power supply and a case to protect all of the components. I should be able to throw together some sort of case quickly, however I need to get the battery ordered. I did some research about batteries for the design report and found this 26800 mAh battery: https://www.amazon.com/Charmast-26800mAh-Portable-Li-Polymer-Compatible/dp/B07P5ZP943. The battery outputs 5v which is how much voltage the RPi runs at, and since our design constraint of battery life is 16 hours, this gives us 8.375 Watts maximum. The RPi uses about 5 Watts at 100% CPU load, and the peripherals will use less than 2 Watts combined, giving us about 7 Watts of power being used. This estimate is on the high end and we may be able to go much lower with careful attention to minimizing power consumption. This battery will give us an estimated 1.375 Watts of slack which is a comfortable amount, especially because I do not want to rely on the battery performing properly at less than 5% charge.

My goals and schedule have somewhat changed from our initial thoughts, with the need to get some real data quickly, I am now focusing more on the construction of the device and the battery. I aim to receive a battery next week and perform some route walks while gathering the location data along the way so that we can do testing/development. I will be somewhat ahead of schedule regarding the battery and device development, however I will be going slightly behind on schedule regarding the wireless communication aspect of the device in order to focus on the location data collection.

Posted on

Team Status Report 10/29/2022

This week each of us focused on getting our preliminary setup down so that we can start to collaborate much more this up coming week. Zach worked on interfacing with the HERE API, and Colin worked on setting up the RPi along with all of the peripherals that we will be using. Our goal is to walk some routes next week and gather the location data along the way in order to have some real data and to test the HERE API out with. We decided that our first goal will be to have the ability for the device to correctly navigate routes without re-routing. This offers us three advantages, the first being that it will be easier to develop without having to worry about re-routing at first. The second advantage is that we can quickly develop this due to the fact that re-routing will be the only reason that we will need to talk to the internet, so we do not need to focus time on the wireless communication aspect. Due to the fact that we can cache the route ahead of time we can connect the device to a WiFi network, download the route data from the HERE API, and then test the route out offline. The third advantage has to do with risk mitigation in that we will be able to reduce the scope of the project to only having to be connected to the internet at the beginning of the route process in case we cannot get the wireless communication to work over the cellular data network. An example of how this would be used would be that the user has to load the route into the device before they leave their house.

Due to the interim demo coming up quickly in a week or two, we would like to have some sort of working example of the main functionality which would be navigating based on the GPS/IMU output. This is what is driving us to our decision to not focus on the re-routing for now, and hopefully after next week we can have a good demo.

Posted on

Zachary’s status report for 10/22/2022

This week I spent most of my time on the design report. Aside from that, I read documentation on the HERE API (which we decided to pivot to from Google Maps API), and have obtained and API key for it, and was able to start sending and receiving requests from it.

Due to having a busy week and working on the design report, I wasn’t able to spend as much time on implementation. Next week, I hope to finish the route planning and cache implementation. I will also work with Colin on communication between our frontend and backend threads.

Posted on

Colin’s Status Report for 10/22/2022

This week I accomplished everything that I wanted to based off of my prior status report. I wanted to get all of our hardware ordered (except for the battery) so we could begin to experiment with the equipment as well as working out a framework for the software to run on the Raspberry Pi. Zach and I also spent a lot of time on the design review report.

Most of my time this week was spent on developing the software to run on the RPi. My main goal was to come up with a system where all three of our main threads could run while communicating with each other. I decided to add a fourth overall thread to the system which would be the controlling thread. This thread tells the other three threads when to run and handles the data communication. Since we will be using a single process and asyncio in python to be able to run threads, we do not have to worry about concurrency issues when communicating data since only one thread will be running at once. The controlling thread will initially tell the location thread to gather location data, and then put that data into a buffer. Then the second thread that will be interpreting the location data and communicating with the API’s will be called. That thread will be given the buffer to take the location data and then use it to determine what sort of feedback to give to the user. The feedback will then be put into a separate buffer and given to the third thread by the controlling thread. The third thread will then run the text-to-speech engine and output to the 3.5mm audio jack for the user to listen to. This process will continue until the user has reached their destination.

Next week I would like to hook up our components that have been ordered into the physical system. I would like to communicate to the components through the software and be able to gather the necessary location data to be able to know where the user is. I would also like to hook up the software to the blues wireless notecard API to be able to communicate to our external directions API. If I could get all of this done next week I would be on schedule and I would be able to begin to collaborate with Zach in order to start getting the skeleton of our entire system working. We would hopefully be able to have the hardware supplying data to the directions thread which would allow us to work out the next steps to a fully functional system.