Posted on

Team Status Report for 03/16/2024

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.

 

Posted on

Jeff’s Status Report for 03/16/2024

What did I do this week?

This week I primarily worked on the web application, as well as provided some support for my teammates as they worked on the DWM1001 development boards.

For the WebApp, I focused on editing the page displaying the floorplans of the building. I changed the HTML of the page, putting the image in its container, adjusting the CSS so I could use Javascript to manually center the image in the middle of the screen over the user’s hypothetical location. Additionally, I learned how to draw lines over the image to represent the path the user should take, utilizing a canvas HTML element to draw lines, and positioning it over the image.

A short video demo can be found here.

The demo consists of mock data embedded in the Javascript. Obviously, this is not going to be useful for the final product, so I worked on creating a model to hold the position of tags on the server. Then, I added the API endpoints necessary to support updating the models (sent by the tag) and obtaining the data from the models (requests from the browser running the webapp. Overall, this was successful, and I was able to create a Python script emulating the tag, sending random positions to the server, and the positions being accurately represented in the Browser.

I briefly helped Weelie test the communication of tags with multiple anchors, which was successful due to his troubleshooting.

Is my progress on schedule?

This week I was able to make significant progress on the web application, meeting the goals I set for development of the Map view page.  However, I did not end up making progress on the A* pathfinding algorithm. This is because I opted to make more progress on next week’s task, communication between webapp and Raspberry Pi, because this task has significantly more immediate importance for our Midpoint demo milestone that is upcoming. Altogether, I believe that my progress for this week is on track.

Next week’s deliverables:

I would like to continue working on the server to ensure that communication between webapp and RPi is set up correctly. I will also need to work on running the server on AWS instead of my local machine to test the full functionality of communication.

I would like to work on a version of A* algorithm implemented, though this is still second in priority to the former task, as we are not in the stages of mapping a building floor yet.

Posted on

Ifeanyi’s Status Report for 03/09/2024

This week, I did a lot of research into the chip we are using for our project and how it works. I learned that it has multiple threads to be able to communicate with multiple devices at once. This will be necessary to take into account when developing the multilateration localization routine. I learned that the chip has a built-in accelerometer (though we decided not to use it). I also learned that the chip can be connected via both SPI or USB to a Raspberry Pi, of which we chose to use USB for our final tag device. In addition to this, I also found and ordered the appropriate accelerometer and Raspberry Pi board for the project.  Finally, I wrote my part of the design document, which included explanations of some choices of parts, detailed testing methodology for the project, explanations of how the work was split up, how the mapping works, how the navigation system works, as well as many technical details about both the anchor and tag devices.

DWM1001 Firmware User Guide

DWM1001 Firmware API Guide

MDEK1001 User Manual

I am currently on track with my work as I am currently in the phase where I’m supposed to be setting up and configuring the chip in preparation for developing the localization capabilities.

Next week, I hope to get a working trilateration routine working with a single tag device and 3 anchor devices. From there, all we will need to do is add the ability for the tag to communicate with more anchors simultaneously. Then we can add the navigation routine on top of that.

Posted on

Weelie’s Status Report for 3/9/2024

  • What did you personally accomplish this week on the project?

Last week I mainly did two major things.

  1. I helped writing the design report. Mostly I finished the algorithm part, the system design part, and some of the tradeoff part. After that, I helped change some minor errors in the design report.
  2. I implemented a general trilateration algorithm that could take in 3 distances and locations of UWB devices and return an estimated current location. I also started working on setting UWB devices to be tag and anchors such that a tag can receive multiple signals from anchors. The details can be found at our github repo: https://github.com/weelieguo/18500-dw1001
  • Is your progress on schedule or behind?

Based on the current schedule, I should work on localization algorithm for the following 2 weeks. Thus, my process is actually on schedule.

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

Since we haven’t retrieve our Raspi 4 yet, I will start working on the transaction between the tag(UWB device) and Raspi 4. And make the trilateration algorithm works on Raspi 4. Then, I will implement the protocol to choose between all the anchors devices because we only want to use 3 strongest signals (closest to the tag) to measure distances and used them for trilateration, which could include multithreading for UWB devices.

Posted on

Team Status Report for 03/09/2024

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.

Posted on

Jeff’s Status Report for 03/09/2024

What did I do this week?

This week I focused my attention on working on the design review report, making sure to address several topics we had put less thought into developing, as well as responding to the feedback that was provided to us from the presentation.

Specifically, I wrote the introduction to the project, trying to better describe the motives around “why the problem is important to solve”, as suggested by feedback.

I worked on the Use Case requirements more, adding some of the ethical issues that are surrounding a location tracking device. Most use case requirements didn’t change, but I addressed feedback regarding the total system cost for installing the UWB anchors inside buildings (this cost is variable given how large a floor is, so I wrote it in terms of a “per hallway” cost).

I worked on the “ARCHITECTURE AND/OR PRINCIPLE OF OPERATION” section, which was mostly a rehash of the presentation.

For the Design Requirements section, I researched the time accuracy of the DWM1001 development boards when utilizing the TWR TOA protocol for distances. I made calculations regarding the required precision needed for our accuracy goal (which the devices meet).  From this, I also learned of the latency of communication for the devices (around 1.2 ms on successful communication). Regarding the feedback presented from the presentation, I also focused on why exactly 25 meters is a good range requirement for the ultrawideband transceivers. Again, the optimal minimum range is dependent on many factors, so I tried making clear that this requirement was likely sufficient for a typical hallway in a building.

For design trade studies, I researched other ultrawideband receivers we could use for our project. Most of these were more expensive than the DWM1001 Development board we are interested in using, so I made note of that in the report. I also improved the values in our “technology tradeoffs table”. As Professor Tamal mentioned in the presentation, we should have noted prices for installing systems. I made estimates of how much it would cost to map out a single hallway using Wi-Fi, BLE, or UWB.  I assumed it would take 3 devices to map out a single hallway (this estimate is different than mapping out an entire building, as we can overlap the devices for the hallways in a building. Looking back, I am not sure I was clear enough in elucidating this).

I also worked on the system implementation for the webapplication, developing a few mockups of some user interfaces.

Is my progress on schedule?

I was unable to make any meaningful progress on the Django webapp this week, though I was able to instead focus my efforts on planning what I want the design to look like going forward, as well as making contributions to significant portions of the design report. With this in mind, I will work on the “map view” page further next week and try to finish it after spring break.

Next week’s deliverables:

For the web application, I hope to work on the map view, implementing how I want the image frame to function, as well as working on drawing shapes on it to visualize the student’s location. Then I will get started on the shortest paths algorithm and work on visualizing it on the map.