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

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

Lata’s Status Report for 03/14

ACCOMPLISHED: 

This week, I began PDR testing in the breadboard and began my implementation of the UI on Arduino for our March 26th interim demo. Additionally, we talked about the fact that our screen may be too small for the information that we want displayed on it, so we have decided to buy a larger square-shaped screen. I also began wiring up our current screen on the breadboard to the ESP and Eyespi breakout, so that we can confirm that the Arduino code is outputting onto the screen correctly I have not begun testing this yet. 

PROGRESS / SCHEDULE:

My progress is not mostly on schedule; however, some of the tasks I was initially doing have changed because we realized how much more work certain sections were than others. In the next 2 week I need to finalize setting up the UI stages and the interface of what each step of the process will look like, and we will integrate the PDR with the GPS code that we have. 

DELIVERABLES / NEXT STEPS:

Next Week, I will:

  • Fix the issues that I am having with my basic Arduino display code showing up on the Screen 
  • Finish coding the main states for the UI 
  • Implement the PDR from MATLAB into C++ and test it there to see if it works before we combine with the GPS code.

PDR code(matlab):

 

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
Posted on

Brandon’s Status Report for 03/07

03/07 – March 7th

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 completed 2 iterations of our pcb and ordered the pcb which arrived on Friday. The team also worked together in order to complete the Design Report that was due last friday. These were very large projects that needed to be completed immediately in order to move forward to our interim demo and get started on finishing our project.

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 behind schedule because of the pcb ordering time and it was not cheap to order the pcb which might be a concern. To catch up we need to complete key integration that is planned for this week.What deliverables do you hope to complete in the next week?

I hope to solder all components together to get a size reference for our hardware shell along with starting to code the large state machine for the firmware. Because I am hardware lead a key component of my work is integrating all of our hardware to our firmware and confirming it works correctly to match our MVP.

Posted on

Lata’s Status Report for 03/07

ACCOMPLISHED:

This week I implemented an iteration of PDR on MATLAB additionally now that our order of the IMU has come in I can now test it on a breadboard to see if my implementation of PDR is accurate enough or if I need to update it to a bit to make it more accurate for tracking and drift reduction.

PROGRESS / SCHEDULE:

My process is a bit behind schedule because it took a bit for the IMUs to come in however now that they are here and and almost everything we need to order is here I can go through and set up and test on a breadboard now with the IMU.

DELIVERABLES / NEXT STEPS:

Next Week, I will:

  • setup for UI and stages for firmware
  • Test the IMU + PDR on a breadboard and tweak as needed
Posted on

Katherine’s Status Report for 02/21

ACCOMPLISHED: 

This week I worked on setting up the server, integrating the Google API, creating designs for firmware and software (block diagrams), and creating user flow diagrams. For the design presentation, I created slides for design requirements, overall system diagram, firmware system diagram, and software system diagram. For the design presentation, we heavily focused on creating the user work flow that was easy to follow and also calculate power consumption in order to meet user requirements. I have also started testing our server system with our gnss module. 

PROGRESS / SCHEDULE:

My progress meets the schedule. I was able to finish Google maps API integration this week as well as the design presentation. Because of the design presentation, we also have a good idea of what the next few weeks looks like for software. We also were able to solidify task delegation since we decided what is going to be on firmware and what is going to be on software. This makes separating work and responsibilities a bit easier going forward. 

 DELIVERABLES / NEXT STEPS:

Next Week, I will:

  • Learn how to connect devices (microcontroller) to wifi
  • Implement the route planning system
  • Implement database
  • Learn how software will communicate with firmware 
Posted on

Brandon’s Status Report for 02/21

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

In creating the pcb I have run into some problems, namely enabling the buttons while also having a screen, initially I hadn’t fully understood how much verticality the buttons would need to be able to be pressed through the hardware enclosure. So I mainly worked on redoing our PCB design in order to accommodate for vertical clearance and allow us to create the hardware enclosure without worrying about button height. This is all in order to order the pcb on tuesday before break.

Below is an example of a small breakout board that won’t hurt to have on the top of the board.

 

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 behind schedule, we were supposed to order the pcb last week, but due to redesigning the pcb we will order it on Tuesday next week. This means we will get the pcb during spring break, which pushes back our physical integration schedule by a week. However to combat our mistake we have planned to order expedited shipping to get back on track.

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

PCB Design and Design Review Report

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.