Posted on

Lata’s Status Report 04/26

Lata’s Status Report  for 04/26

ACCOMPLISHED: 

The firmware is being integrated with the software, it is sending the correct updated, and the ESPs are detecting each other. Currently, in the process of debugging the GPS module and the navigation updates for the arrow; however, sending and accepting invite works as well as detection. 

PROGRESS / SCHEDULE:

In terms of progress, we are still slightly behind schedule; however, I do believe that I will finish up my last few sections by the beginning of next week, leaving enough time for testing. 

 

 

DELIVERABLES / NEXT STEPS:

Next Week I will: 

  •  Figure out the arrow mechanism for the UI so that it is smooth and does well with the updated of the user moving
  • Figure out the issue with the GPS module so that I can move away from using pre loaded locations
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

04/18 – Brandon’s Status Report

What did you personally accomplish this week on the project? Give files or photos that demonstrate your progress. Prove to the reader that you put sufficient effort into the project over the course of the week (12+ hours).

I implemented the battery charging system on the pcb using a lipo and a usb charging module with a boost converter. I also submitted our pcb, which we received yesterday.

Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?

We are slightly behind as we need to do validation and testing.


What deliverables do you hope to complete in the next week?

I want to fully solder everything and help with integration between firmware and software.

As you’ve designed, implemented and debugged your project, what new tools or new knowledge did you find it necessary to learn to be able to accomplish these tasks? What learning strategies did you use to acquire this new knowledge?

We recognize that there are quite a few different methods (i.e. learning strategies) for gaining new knowledge — one doesn’t always need to take a class, or read a textbook to learn something new. Informal methods, such as watching an online video or reading a forum post are quite appropriate learning strategies for the acquisition of new knowledge.

I learned a lot about kicad and how to work with manufacturing teams like jlcpcb and the way that people design, particularly the standards for how a pcb should work like implementing a ground plane and things like that. This was very necessary in order to have a pcb that doesn’t have bugs outside of the circuit designs, I mostly did online research to learn these things.

Posted on

04/18 Team Status Report – Brandon

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 just not completing the work on time, we have had problems identifying exactly how the system is going to be built in terms of firmware and software and the way they interact. We have a plan to implement, so this next week will be integral into meeting the demo goals.

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?  

The only change we’ve made is separating some more components from the firmware to the software. This isn’t a large change, but it is one we need to acknowledge.

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 got our pcb! We have to solder everything together and get it into the hardware enclosure.

 

Posted on

Lata’a Status Report 04/18

 

ACCOMPLISHED: 

This week, I’m in the process of integrating the firmware with the software so that we are able to get and send the GPS coordinates and update then as necessary through the Google Maps API so that we have the available route necessary for the project. 

PROGRESS / SCHEDULE:

In terms of progress, we are still slightly behind schedule; however, I do believe that we will get ot done wth enough time to finish the testing necessary and have it up and running as long as we are fully integrated by the end of next week. 

DELIVERABLES / NEXT STEPS:

Next Week I will: 

  • Finish the integration of GPS and PDR and connect it to the Server 
  •  Figure out the arrow mechanism for the UI so that it is smooth and does well with the updated of the user moving 

NEW TOOLS AND NEW KNOWLEDGE:

Understanding how the firmware works together and how to debug when running into issues with Aurduino and testing a lof of learning has changed to a degree due to the fact that we do have the ability to use AI and rather than having to learn a lot of it ourselves through google searches I was able to use AI to debug additionally It was also a lot of reading the specs of the different parts so that I could understand what conections I needed makse to have teh system working.

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’s Status Report 04/04 – Lata

03/04 – Lata 

The whole team should answer the following questions in the Team Status Report:

 

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 that we are facing right now is getting the PDR properly integrated with the GPS and the new iteration of the PCB arriving on time with enough time for us to test the firmware on it as well. We realized with testing for the interim demo that there were some errors in our initial PCB. We are ordering the PCB this week, on Monday, when ordering opens, and ideally, it will be here within the week, and we will be able to begin soldering and integrating the firmware onto the PCB fairly quickly 

 

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?  

 

The design of the system is staying the same; we just had to make some changes to the PCB because we faced some wiring issues, but every piece on the PCB is staying the same. The cost of this change is just financial because we made an error initially. 

 

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.

 

Link to video of UI: https://drive.google.com/file/d/1uB-YKRFpqOqrMi1vG3DI5HIbTuG1QIWU/view?usp=sharing

VALIDATION TESTING: 

 

For validation of the product, we will be sending out user surveys and having different users use the product for a few days to see if they enjoy it and if it results in less stressful and easier navigation that we are looking for. Additionally, we will also be testing the device once it is fully integrated before we user test it with others. We will be testing battery life through the use of a full day and seeing how long it lasts in that time frame. Additionally, all of us are currently individually testing all of our parts and testing everything as we begin to integrate them piece by piece through walking tests, navigation and routing planning comparisons, and direct tests by seeing if firmware is working on hardware and being sent to software.

 

Posted on

Lata’s Status Report  for 04/4

ACCOMPLISHED: 

This week, we had our interim demos, and for these demos, I finished coding out a major portion of the UI process. It was being controlled by my laptop due to the fact that, in testing our firmware and hardware together, we also found some major issues with our first iteration of the PCB, so the buttons that we have on our current PCB don’t work. Additionally, I have completely finished implementing the PDR in C++, added a Kalman filter to it, and began testing and tweaking it to detect straps and distance accurately, some things that I am struggling with is the fact that because I am the one strictly testing the PDR the stridelength and step tracking is adjusted and tuned to my steps specifically so I need to do some research on what values would be best for distance ad step length for an average person so that it can work for everyone who is using the device. 

PROGRESS / SCHEDULE:

In terms of progress, we are still slightly behind schedule; however, looking at our interim demo, I am not as worried as I was before about integrating our biggest issue, is getting our new iteration of PCBs here on time. For the next week, we will be integrating the PDR with the software and GPS so that routes are properly updated and tracked. 

TESTING PLAN: 

  • For PDR, I am currently testing both indoors and outdoors with different distances. I’m testing 5m and 10 m walking straight to see if it can detect my step counts correctly and the distance correctly. Additionally, I am also testing distances with 90-degree turns to see if it is able to detect a turn and step. This will meet the USE case requirements as our main functionality is our device being able to navigate you correctly to the next device and if step length and distance predictions are wrong the navigation to the other device will also be wrong. 
  • For the UI, there isn’t really much testing to be done; it is just stepping through a false/real navigation and seeing if the screens are outputting the correct screens at each state. 

DELIVERABLES / NEXT STEPS:

Next Week I will: 

  • Finish integrating the PDR with the GPS routing – next Saturday 
  • Finish implementing all stages of the GPS- need to implement the idle stage – next Saturday 
  • Figure out how to get the ESPs to detect each other and send the information between them, and depending on whether they are a receiver/sender, have the screens display differently – two weeks

Link to video of UI: https://drive.google.com/file/d/1uB-YKRFpqOqrMi1vG3DI5HIbTuG1QIWU/view?usp=sharing