Author: jrchen

Significant Risks

The most significant risk we currently face is that we have finally gotten our localization system with at least 3 anchors up and running, and yet, we are seeing less than desirable results with regards to localization frequency (not quite < 2 Hz)  and position accuracy (the tag’s distance measurements seem to have variance of up to +/- 0.75 meters). To improve the latency, we are implementing various optimization strategies such as running a thread in the background to process the data, and are already seeing slight speedup. For position accuracy, we are currently tinkering with slightly different methods of calculating the position using the 3 distances. We are also implementing smoothing that averages at least the last 3 measurements. We might also see accuracy gains if we use more anchors.

Changes to System Design

We were able to successfully set up a webserver and send localization updates to the webserver. Because of this, there was no need to make any updates to the system design. 

Schedule

This week we were able to further test the localization system. We were able to have the tag find the positions of at least five anchors simultaneously, and we also found that the maximum distance we could communicate between a tag and an anchor appeared to be approximately 35 meters, which is above the 25 meter benchmark we were aiming for in our Design Report. 

Next week is the runup to our midpoint demo; hence, we would like to continue improving our localization accuracy, augment our user orientation using the IMU data, and continue making improvements to the throughput between our webserver and the client by testing websockets. 

An updated schedule with our current progress can be found here.

Significant Risks

This week we resolved the issue of forming a network with our DWM1001 development boards due to Weelie working on a multithreading task to communicate between multiple anchors. The volume of anchors a tag can communicate has not been verified yet, as we have not had the chance to test it with a larger number of anchors. We still need to find if there is an upper limit of anchors we can communicate with. Suppose we are only able to communicate with a limited number of anchors at once. In that case, we will need to tweak the tag’s routine so it initiates communication with a smaller subset of the anchors at once.

Finally, we still need to try setting up the “gateway” with the RPi4 reading from the DWM1001 board’s serial to make the RPi suitable for creating our connection to the internet. If our USB connection doesn’t work, we can try using SPI instead, which should work based on the datasheet.

Changes to System Design

This week was spent focused on the initial design of the network of ultrawideband transceivers. Our initial testing seemed positive; hence, we did not make any changes to the system design.

Schedule

This week was spent working on more of the initial setup for the DWM1001 development boards and making progress on the webapp.

We hope to spend next week working toward our midpoint demo. We would like to be able to localize our device within a room or a table, along with creating a connection to the webserver.

The following schedule includes the current progress we have made on our respective tasks.

18500 Gantt Chart 3-16

Progress

A video demo of some progress on the webapp’s “floor view” can be found here.

A video demo of progress made on the tag/anchor communication can be found here.

 

Significant Risks

This week was spent mostly working on the design review report; hence, our significant risks are still similar to those discussed in our previous report. Namely, 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. Also, 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

Our research into the design requirements whilst working on the design review report revealed that a DWM10001-Dev board paired with a RPi 4 might be a better solution using the ESP32-UWB module. This is because the RPi 4 offers significantly higher computing power that can run the localization algorithms faster, as well as any processing that needs to be done with the IMU.

We also discussed integrating sensor fusion techniques with the IMU, using a Kalman filter to decide whether to use readings from the localization network or a prediction estimate from the IMU. We think this technique could lead to an improvement in localization and are planning on continuing with it.

Schedule

This week we primarily worked on the design report. We revamped our Gantt chart to better show the work breakdown, as well as adding milestones we would like to hit.

18500 Gantt Chart breakdown

Prompt

Part A was written by Jeff, Part B was written by Ifeanyi, and Part C was written by Weelie.

Part A: Our project is named “Scotty Maps” because we wanted to create an application tailored specifically to the CMU campus. Although our web application will be specifically based around in CMU, it is not to say the project will not have a global impact. We hope to design a localization system such that it is easily adjusted to fit other buildings. By creating a localization cheaper than others, as well as well as developing tooling to help map buildings, it is entirely possible that our project can be used in a myriad of other locations, whether it still be in academic buildings, or any other commercial location in need of a navigation system.

Assuming there is widespread demand for indoor localization systems, our device could provide a massively improved quality of life for people trying to find locations in buildings by making navigation more interactive. It could affect the way navigation “assistance” is currently accomplished in buildings such as shopping malls: instead of needing to hire people to provide directions or using large monitors displaying the floorplans of the building, our product would be able to provide shoppers with a more interactive experience, showing directions and easily leading people to where they need to go.

Part B: Our project has a significant cultural impact for students across campus. This comes from the fact that students design their entire lifestyle around being on time and organized for everything that they take part in on campus. Part of these considerations involves sticking around the parts of campus that they are most familiar and can therefore navigate the most easily. This leads most students to frequent the same spots on campus for the majority of their time at the university. With our device, students can more confidently explore and traverse new parts of the campus that they are not at all familiar with. Another part of student culture is that in preparation for urgent events, such as midterm exams or finals, students have to make out time to visit the venue and learn how to get to it so that they don’t arrive late to the exam on the day. But with our device, there won’t be nearly as much of a time sink in finding a new place on campus that you’ve never been to before. Finally, students have a culture of sometimes wanting to keep to themselves. This may be for all sorts of personal reasons, such as social anxiety. With our device, they wouldn’t have to approach strangers to ask for directions to places when they get lost trying to find their way somewhere.

Part C: Our project used a lot of UWB devices to send and receive signals, and we will use wifi to transfer the location data to the web server. This may bring the concern that the signals may impact people’s health. Although UWB devices has shorter range than WIFI signals, we can get more precise location by using UWB devices than using WIFI signals. There always concerns for WIFI and  phone signals. Some people believe that the radiation will harm human bodies. However, the power of using UWB is actually lower than WIFI signals. And WIFI signals’ power is lower than an iPhone’s power.  Even iPhone’s power radiation will not do harm to humans. Thus, our devices’ radiation will not exceed the limit for human body.

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.