Posted on

Team Status Report for 04/25

What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plans are ready?

The most significant risk currently is firmware and hardware not being integrated well and us having to physically remove prints again. The enclosure is not fully designed yet so it hard to get a feel of the device. We need to conduct user testing starting Monday. There are also a lot of deliverables due next week so we need to forward plan.

Unit Tests:

GPS accuracy (Firmware): logged GNSS points over 10 minutes at a known location across 500 samples. Target was ≤5m error. Mean error was 3.2m. Pass.

PDR accuracy (Firmware): walked multiple paths including straight, 90-degree, and 180-degree turns to validate distance calculation. Target was ≤2.5m error. Mean error was 2.5m. Pass.

Bearing computation (Software): fed known lat/lon pairs with known expected bearings and compared output. Target was ≤1° error across all cases. Max error was 0.3° across 16 cases. Pass.

Server latency (Software): ran two simulator clients for 10 minutes and logged server processing time per update cycle. Target was 90th percentile ≤50ms. 90% of updates completed within 35ms. Pass.

SUCCESS detection (Software): simulated two devices converging to <3m across 16 scripted cases. Target was SUCCESS event firing at ≤3m in ≥15/16 cases with DB write confirmed. Fired in 16/16 cases with DB write confirmed. Pass.

Battery endurance (Hardware): ran device continuously under campus-day state distribution. Target was ≥6 hours runtime. Achieved 8 hours. Pass.

System Tests (In Progress):

Navigation update latency: timing full update cycle across 10 trials. Target is 90th percentile ≤200ms. In progress. Session setup timing: measuring device wake to invite sent, invite to arrow displayed, and WiFi connection time across 10 trials. In progress.

Planned: Usability and stress reduction: user survey measuring mean ≥3/5 across usability questions and ≥70% yes on spontaneity question. Planned.

No failing tests were recorded across completed unit tests. PDR accuracy hit exactly the 2.5m threshold . This is worth monitoring under more varied terrain or longer paths to confirm robustness. Server latency outperformed the target significantly (35ms vs 50ms),  System-level tests are still in progress and may surface integration issues not visible at the unit level.

Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?  

No changes were made here

Provide an updated schedule if changes have occurred.

No changes to schedule were made this week


Posted on

Katherine’s Status Report for 04/25

ACCOMPLISHED: 

This week, we worked on our final presentation and testing. We had to collect all testing numbers for our presentation. I put together the slides for the presentation and delegated tasks. I finished putting together and rehearsing slides. I also started designing final poster and decided on what will go into the demo video.

PROGRESS / SCHEDULE:

My progress is on schedule as we made a few changes last week.

DELIVERABLES / NEXT STEPS:

Next Week, I will:

  • Finish full integration testing
  • Finish poster
  • Finish Report
  • Work with Brandon and Lata on video
Posted on

Katherine’s Status Report for 04/18

ACCOMPLISHED: 

This week, we worked on our final presentation. We went through feedback from the last presentation and decided we needed better documentation for software tradeoffs and software system structure. We also created plan for user surveys as oppose to full on user testing. This rescoping was necessary because we are still working on software firmware integration, and hardware firmware integration.

PROGRESS / SCHEDULE:

My progress is on schedule.  However, we are a few days behind integration, which is why we needed to rescope our testing plan.

DELIVERABLES / NEXT STEPS:

Next Week, I will:

  • Finish final presentation
  • Begin working on final deliverables
  • User test
Posted on

Katherine’s Status Report for 04/04

ACCOMPLISHED: 

This week, we had our interim demo. I helped create the gantt chart. I also finalized my dashboard. I created a powerpoint for the demo and a script that allowed my part to be under 3 minutes. I also planned for the next deliverable and solidified plans for integration.

PROGRESS / SCHEDULE:

My progress is on schedule.  The software and software demo is complete.

DELIVERABLES / NEXT STEPS:

Next Week, I will:

  • Create readme for software so lata can create firmware code based on my software endpoints
  • Start working on final design report
Posted on

Team Status Report 03/21

What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plans are ready?

The most significant risk is that firmware and hardware needs a certain amount of integration. Software is more of an isolated system, but in order for firmware to be ready for the monday interim demo, we need to make sure the hardware components (gps, microcontroller, screen) are all working properly.

Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?

No changes were made to the existing design.

Provide an updated schedule if changes have occurred.

This is also the place to put some photos of your progress or to brag about 
component you got working.

No schedule was updated. We are all working on completing our individual sections to make sure we can demo our full individual systems properly. We are on track to meet the interim demo deadline on Monday. 

Diagram showing Firmware and Software Interactions

Software Dashboard

Posted on

Katherine’s Status Report 03/28

ACCOMPLISHED: 

This week, I focused on getting everything ready for the interim demo. I hosted  the server on Google Cloud and created a simulation dashboard. The dashboard mimics the entire registration, invite, and navigation process. I created a map that shows all users within 75m radius. I also had the dashboard show the UI and arrow direction as the 2 users navigate towards each other. I also worked on documentation. Brandon and I discussed what information will be stored on firmware (RAM and local vars) and what will be stored on the server (sqlite and local vars) . We also met with Prof.Theo to discuss libraries and how hardware will interact with software

PROGRESS / SCHEDULE:

My progress is on schedule.  The software and software demo is complete.

Software Dashboard

Brainstorm of what will be stored where for firmware

Document for firmware and software interactions

DELIVERABLES / NEXT STEPS:

Next Week, I will:

  • Integrate firmware with my software
Posted on

Katherine’s Status Report 03/21

ACCOMPLISHED: 

This week, I focused on restructuring the route planning system and establishing a clear separation between firmware and software, which allowed me to define the necessary API endpoints for the software. I also implemented a few unit tests targeting these endpoints. I met with Prof. Theo for guidance on how to best separate firmware and software systems. Previously, I had been thinking about it as full systems (route planning system, friend system). However, these full systems involved both firmware and software, which meant I was creating software, but also trying to integrate it with firmware at the same time.

I received feedback that the software was underdeveloped compared to the hardware, so I prioritized technical documentation. I developed a breakdown of design choices and trade-offs for each software component. This documentation is not part of the live demo (which is our next deliverable), it provides a framework for my design choices and satisfies requirements for the final report.  I will continue iterating on these documents based on team and advisor feedback.

PROGRESS / SCHEDULE:

My progress is on schedule. This week I took some time to step back and reflect. However, it follows the schedule we have laid out and doesn’t impact plans.

DELIVERABLES / NEXT STEPS:

Next Week, I will:

  • Get feedback/ iterate on software documentation(tradeoff, use survey, test plan for individual software components)
  • Create more comprehensive unit tests for software features
  • Help w the firmware integration process
Posted on

Katherine’s Status Report for 03/14

ACCOMPLISHED: 

This week, I debugged and tested my code for the route planning system. Currently, the microcontroller can communicate with the server, it can connect to wifi, after a few minutes of standing outside, the gps starts to output location data. This data gets sent to the server, and it creates nodes between the microcontroller and a hard coded destination location. It sends back an arrow direction that points towards the next node in the route. When I get to the next node (within 3m), the server updates and points to the next node. The current issue I hope to address is when wifi goes out. During testing, this happened more frequently than I had anticipated. I will need to further test the system to see if this is something we need to fix, or if the wifi outage is short enough so that navigation is not impacted.

PROGRESS / SCHEDULE:

My progress is on schedule. I aimed to finish debugging and start testing this system last week and I was able to accomplish this goal.

DELIVERABLES / NEXT STEPS:

Next Week, I will:

  • Integrate Lata’s firmware PDR code into my gps code
  • Create user testing plan 
  • Write out justifications/ come up with justifications to all our assumptions in our design writeup.
  • Continue testing my route planning algorithm
Posted on

Team’s Status Report for 03/07

What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plans are ready?

Our most significant risks is that our second iteration of the PCB isn’t going to work. Each iteration takes time, so we want to get it right. However, with the mid semester demo coming up, we need a working MVP of our project, which will heavily rely on our PCB doing its core functions. Our contingency plan is to have a bread board version done so we can test out our software, continue iterating on our PCB designs and rushing the shipping times so they arrive quicker.

Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?  

We currently don’t have any changes to the design.

Provide an updated schedule if changes have occurred. This is also the place to put some photos of your progress or to brag about a component you got working.

We have delegated tasks for spring break. Lata is going to test the PDR algorithm in MATLAB, Katherine is going to work on the route planning system, and Brandon going to work and order the second iteration of the PCB.

No changes to our schedule.

This is the second iteration of our PCB design

This is our code for wifi registration and sending location data

 

Posted on

Katherine’s Status Report for 03/07

ACCOMPLISHED:

This week I received the microcontroller, the IMU, and the GPS. I was able to start testing with these three pieces. I also was able to register the microcontroller to the school’s wifi. This will allow the microcontroller the communicate with the server.

PROGRESS / SCHEDULE:

I wrote out the arduino code to send gps location to server and receive direction arrow from the server. I’m still debugging the logic for this code. The goal is to have the route collection process done by the end of this week. I am on schedule as I was able to figure out wifi registration.

DELIVERABLES / NEXT STEPS:

Next Week, I will:

  • Have the arduino code for sending location and receiving arrow direction working