Month: February 2024

Significant Risks

This week we found we were able to successfully program the DWM1001 development boards as well as measure distances between them.

There is a risk in the fact that there could be difficulties in setting up an ultrawideband network of DWM1001 boards communicating amongst each other. We need to ensure we can create this network of devices, as well as find the limit (if there is one) to the number of devices the tag can communicate with at any given time. We would like to have these figured out next week so we know the limits of the devices relatively early on into the development cycle. If it turns out that there is a limit to the number of devices communicating, our contingencies consist of opting towards utilizing multiple UWB channels for our communication networks.

We also need to make sure that the DWM1001 boards can be connected to the internet so we can communicate data to the user. To do this, we need to make sure to set up a Gateway using a RPi. If there are issues in getting the RPi to interface with the DWM1001, we can try to use a ESP32 UWB as our gateway instead.

Changes to System Design

Because our initial progress with the development of both the web application and the DWM1001-Dev boards seemed to be overall positive, we did not make any changes to the design of the system.

Schedule

We made some slight changes to our schedule to accurately describe our tasks. Some existing tasks were reorganized.

18500 Gantt Chart 2-24

Next week’s goals:

Jeff: Continue development of the web application, making improvements to the building view to add functionality for navigation.

Weelie (also Ifeanyi): Accomplish a full “network test” this week to get unique distances from multiple devices. Is there a limit to how many devices we can talk to?

Ifeanyi (also Weelie): Put in an order form for a RPi. Then see if you can use the RPi to talk to the internet while interfacing with the DWM board. Research a good IMU (or use the one already on the DWM1001 board) to use with the RPI.

Team: work on Design Report.

Web App progress

The most significant risks that could jeopardize the success of the project are difficulties in programming the DWM1001-DEV boards, as well as UWB being less robust than we initially assumed. The DWM1001 development boards use the nRF52832 microcontroller, and programming it with the functionality that we want might be more difficult due to possible lack of support in areas such as maintaining a larger network of devices or accurately calibrating for antenna delays. If these aspects seem to interfere with our project, we can either work on implementing some of the capabilities ourselves or try pivoting to using a different microcontroller with the DWM1001 boards, such as the ATMega328p, which could have more library support. Additionally, UWB could be less robust than initially assumed, providing less accurate readings indoors. The possible contingencies we are thinking of right now are to add more sensor fusion from IMUs, or in the worst case pivoting towards using a different technology altogether.

 

This week we finished flushing out a design of the system using UWB instead of Wi-Fi, and we were able to create an updated block diagram that more precisely reflects our understanding of the design. 

 

Last week we said that we were going to include a new schedule, and this week we spent some time developing it. 

18500 Gantt Chart 2-17

 

Goals for the next week

Put in order forms for all the all the components we want. 

Run initial testing DWM-1001 MDEK boards. Try to find distance between an anchor and a tag using to way ranging time on arrival (TOA) and make sure that it is accurate.

Continue working on setting up the webapp. 

 

Status Report Prompt: A was written by Ifeanyi, B was written by Jeff, and C was written by Weelie. 

 

Part A: With regards to health, safety and welfare, our project relieves anxiety related to being lost in unknown parts of campus. This anxiety can be especially severe when one is alone, as there would be nobody to ask for directions. And even in the presence of others, finding somebody willing to lead you all the way to a class can be hard, and time consuming, much like the alternative solution of wandering the building until the desired room is found by trial and error. In general, our project greatly aids the mental well-being of students by providing convenient access to anywhere they need to go, as well as saving students from the stress of arriving to events late by saving them time in the room-finding process.

 

Part B: One way our project could affect social factors is to help students navigate campus better, which could bolster or provide an incentive for students to explore campus. Some students may often feel stressed when they are tasked with going to a new building, and this device may alleviate some of the negative feelings those students may have. Our mapping software could help students save time looking for classrooms or offices, making their schedules more efficient. 

Our device could lead to privacy concerns for students, as it would consist of placing a tracking device on every student. A bad actor would be able to see the locations of students using the device. It would be important to avoid this from occurring by placing safeguards so that the privacy rights of students are respected. The device could also create dependency of students on the navigational technologies, hindering their abilities to navigate among rooms on campus without it. 

 

Part C: We use 12 different UWB devices for anchors, IMU and esp32 for the tag. The tag itself is not expensive, which may only take 15 dollars. However, combining with UWB devices, since each floor probably needs 12 UWB devices, for a whole building, this could be pretty expensive. For a 3 floor building, the total cost could be over 1,000 dollars. For individual users, the tag itself is easy to buy and for distribution. But for all of the anchors, it’s better for a company or the owner of the building to buy the whole system, and provide services for individual users. Since companies can also charge users for buying their services, depending on different companies, this could save their cost. For individual users, their cost will increase if they need to buy the services from companies, but it should not be as expensive as purchasing a single anchor($33). 

This week we spent time researching the various technologies and algorithms that could be useful in indoor localization and navigation. Overall, our findings reveal that high localization accuracy indoors might be able to be achieved in reality.

The project is still in an early planning phase, hence, we have chosen to pivot from using Wi-Fi to using UWB due to the hopes of being able to achieve higher accuracy and precision in localization. Finally, we also discussed the complexity of the project and are possibly investigating methods that could expand the scope of the project. For example, other localization techniques, such as doing computer vision on the surroundings of the user, could also accurately localize the user. Effecting such sensor fusion of UWB and CV could improve the accuracy of localization.

We are still in the midst of discussing how best to go forward and will create an updated schedule for next week.