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

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

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

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

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 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.

Posted on

Team’s Status Report for 03/14

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 risk is that for the interim demo, when we go to integrate our hardware and separate software services, it won’t work; however, I do think we will be able to have our parts working such that each thing can work in its own, and we are working to. We are mitigating some of these risk but splitting up tasks more so that one person is not struggling to finish everything at once. Currently, our plan is to haven’t everything working at a very base level; however, if we are unable to integrate, then together/ don’t have time, we will still show that they work separately, and we will integrate after the interim demo. 

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 major changes to the design except that we now want a bigger screen the cost should not be to significant as the screen only costs around $20. We did get some responses to our design report in regards to it not being as fleshed out as it should be for certain things such as design requirements and data to justify why we are working on adding more justification. 

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.

This week we met as a group and decided that our current screen is smaller than we want it to be for our project, so we have pivoted from a circular screen to a rectangular screen. Additionally with the intern demo coming up we have split up the work a bit more in terms of the software and what each of us needs to do for the project. 

No changes to our schedule. 

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

Team’s Status Report for 02/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?

One of the most significant risks is that our 1st pcb design doesn’t work and subsequently our second design doesn’t work as well. While we have about $300 dollars to spend on pcb design and 3d printing it does make our team a bit nervous. Our contingency plan is to have our breadboard design ready and make changes to our hardware enclosure to ensure that the breadboard design would work.

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 yet, everything we fleshed out from the design review has stayed the same. Initial feedback from the design review seems to be that we should change a bit about how we present the product, but from a technical perspective nothing has changed.

The only change that we can think of is the pcb design, initially we had the esp32 on the top of the pcb, but due to clearance issues we have moved the esp32 to the bottom of the pcb to allow for smaller modules, mainly the IMU and GNSS to the top, in order to have clearance for buttons and the screen.

 

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.

This week we presented our design review, yay! Also we have divvied up the work for the design review report which is important as this upcoming week will be a busy one for all of us. We believe we are all on the same page which makes other work easier to finish and helps us identify problems with our design and timeline.

No changes to our schedule, but we have some work to show off.

Here is a part of our pcb design, we have also got a server up and running which is making and parsing API requests to the google routes api.

Posted on

Team’s Status Report for 02/14

Our most present issue was the fact that by Monday’s meeting, we were still fairly unsure of some of our MVPs, and we had a lot of maybes in what we wanted to do. Additionally, we still hadn’t thought about many situations and edge cases, such as how we were going to go through the process of connecting our device to Wifi as well as what our UI was going to look like. 

We made some changes to our design. After meeting with Prof. Theo on Monday, we decided that we need to scope down our MVP. We ultimately decided that we will continue to implement PDR for outdoor tracking however we decided to scope down from including indoor tracking as we would rather have one component working very well rather than two components kind of working, because we are still implementing PDR for outdoor we do still have the ability to implement indoor tracking if time allows however it is no longer a part of our MVP. Additionally, we figured out what we want our UI to look like, and we decided that we want to implement both a friends list and a random list, which was still open for a bit. 

Our testing plan and schedule remain the same because we still need all the components we used for indoor testing for outdoor testing as well.

Posted on

Team Status Report for 02/07

Currently our most significant risk is that our PCB may not be ready in time. Because this process takes so long, and can take more than one iteration to get it right, the PCB is our bottleneck. To manage this risk, we will be ordering our PCB by the end of the week to ensure we have as much time as possible to test and iterate if necessary.

We did not make changes to the overall design of our device. This is because we had a good idea going into our proposal presentation of what exact features we wanted to implement. However, we did ad user requirements to include more emotional user requirements, like spontaneity of meetup. This change was necessary because our device at its core is designed to connect and build community. It is not faster, smoother, or better designed than an iphone, but people will still gravitate towards it because it makes connecting with friends easier. Our previous requirements didn’t capture this nuance.

After making this change, we also had to change testing plans. Now our testing plans include user surveys and interviews. We have allocated 3 days for these plans. Our current schedule already includes these changes.