This week I spent time doing testing, and finding and fixing bugs in our state machine code. I also spent time with Colin preparing for what we plan to show for the demo. We will be doing a integrated test run on our fake route tomorrow to prepare for our demo on Monday, and also plan a separate fake route to show off our rerouting capability if time (and space) allows. After the demo, the remaining week will be spent on working on the final video and final report.
Team status report 12/3/2022
This week we spent time refining our project, implementing our state transitions, and gathering test data (battery life, test routes). Additionally, we are also rescoping our project to be within the area of Pittsburgh. This helps us specify which unfriendly crosswalks we will be avoiding, instead of tailoring our algorithm to a more general case.
This upcoming week, we will be preparing for our final presentation, and doing testing and fine-tuning for our project. We expect both team members to present, with each presenting around half of the content.
Zachary’s status report 12/3/2022
This week I spent most of my time implementing the state transitions for routing the user, and testing that implementation. The state transitions are working correctly on our default test case of forbes-morewood to craig-fifth, but I will spend more time next week to do testing to make sure that it is correct. Tomorrow, I will be working with Colin on the final presentation, and I will be spending the next week performing testing, polishing our project, and getting ready for the final demo.
Team status report 11/19/2022
A hard problem we are facing this week is coming up with a heuristic to determine whether a crosswalk can be avoided or not. If a route has multiple blind unfriendly crosswalks, choosing to avoid or not avoid one can have consequences on subsequent unfriendly crosswalks as well. Currently, we think a flat rate distance may be the right option (ie. avoiding blind-unfriendly crosswalks should not increase trip length by X meters in total). If we do it by crosswalk instead of in total (avoiding blind unfriendly crosswalk should not increase trip length by more than X distance of percentage), this may cause the aggregate trip length to be very inflated, even if each individual crosswalk does not increase trip length by that much.
Next week we plan on doing more integration and testing as a group, as we need to make sure that the software and hardware components are working together well, and that we are covering edge cases properly. We hope to be able to run a full cached route with feedback by the end of next week.
Zachary’s status report 11/19/2022
This week i worked on finishing up code for how to direct users/verbal commands for users, and also outputting that feedback using a text-to-speech API (pyttsx3). I also wrote code to orient users at the start of the trip. This is to help users know which direction they need to rotate to begin the trip (left, slight left, right, slight right, turn around, no action). Tomorrow, I will meet with Colin to do integration and testing for our mini-demo on Monday.
Next week I want to start implementing two of the more advanced concepts, which are redirecting, and heuristics for whether to avoid an unfriendly crosswalk (distance based). I will also start doing testing by writing a suite of units tests for my code.
Zachary’s status report 11/12/2022
This week I spent some time setting up a basic communication protocol with Colin for the interim demo. We were able to get good feedback from the instructors about what issues need to be solved, which I’ll talk about at the end. I also continued working on the response request for the backend. particularly retuning a string to indicate how far the user has left till the next action (ie. turn). If the next action is <5m away, I instruct them to prepare to do the next action. Once their distance from the previous checkpoint is >5m, and their distance to the next checkpoint is decreasing, I increment my cache index, indicating that the user is on the next portion of the trip.
A critical piece of feedback we got this week was, how do we know which of the street we’re on, and if there is a crosswalk when we turn? I have been doing reading on the HERE API to address this problem, but have not been able to see a feasible solution so far, as most features on the API, such as this, are focused on car routing instead of pedestrian routing. Another alternative I’ve been considering is reviewing other APIs, such as Google Maps, to see if they potentially have functionality that can solve this issue. In the worst case, if we are unable to solve this, the most brute force way to solve this issue is to assume that on any checkpoint, the user may have to cross a crosswalk. That is, we would tell the user that they may have to cross an intersection, and to use their walking cane/other senses to determine if they actually need to.
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.
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.
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.
Team Status Report 10/08/2022
Some risks that could jeopardize the success of our project: we have to make sure that when our device is mounted on a user, that it does not move/tilt significantly with respect to the user, as that could affect the coordinates given by our IMU/GPS. As such, we need to come up with a way to design our device so that it is stable on the user’s body. Another problem is something we discussed during the presentation, which is detecting whether a person is deviating from the route that the device has given them. A significant challenge here is that just because someone’s distance from their next checkpoint is increasing, does not necessarily mean that they are deviating from the path (ie. road could be curved, etc.). There are several ways we could approach this issue; one way could be detecting if a person’s distance to their next checkpoint has increased over the past n epochs. If it has, then we assume they are deviating and reroute them.
Although we haven’t made any explicit changes in our design, we are thinking about adding an input system (probably auditory) that will prompt the user to give directions to where they want to go. This will make our system more complete and give a more well-rounded user experience. We will discuss this in the upcoming week and change our design accordingly.