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.

Posted on

Ifeanyi’s Status Report for 02/24/2024

After the team picked up our UWB boards for localization, we needed to set them up and program them. This week, I read the full documentation of both the boards themselves as well as the kit they came in. I downloaded and installed the many softwares required to program the boards, and since the kit sellers flashed a starter code on the chips, I had to reflash the chip to remove them. Then I setup the special IDE used to program the chips, and wrote my first starter program, that simply prints a “Hello, World!” message from the boards to my Mac Terminal over UART. I also researched a self-localization technique that involves using 4 or more anchors to calculate a scale-accurate point cloud of all anchor positions relative to each other.

I am personally on-schedule, as at this time, I am supposed to be setting up the hardware for my part of the project (developing the anchors). Since the hardware is acquired and everything to do with the coding environment is now set up, I can begin that development immediately.

In the next week, I hope to complete the self-localization routine, by solving a simultaneous equation for all anchor positions. This means that when mapping, all we have to do is align this 3d anchor point cloud with the real building layout by standing at a few sample positions (I think 2 is all that is required) and marking them on the building map.

Posted on

Team Status Report for 02/24/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

Posted on

Jeff’s Status Report for 02/24/2024

What did I do this week?

This week I spent time rehearsing the Design Presentation before delivering it on Monday.

I spent time putting together several of the views of the web application, keeping in mind the need to make it as mobile-friendly as possible.

I set up a Google Maps API key so I could embed a map centered over the CMU campus, as well as working on customizing the map such that it would display fewer types of “default” pins. I followed the best case practice of utilizing a proxy on the webserver to load the map instead of including it on the client javascript to prevent unauthorized access to the API key. A header was also added, using Bootstrap to display a menu.

I worked on two models, a “Location” and a “Floor” to represent pins in the database. I added an API endpoint on the server to fetch the data for the locations, before adding client-side javascript to fetch the data using an AJAX call before creating the HTML necessary for the pins. Overall, the current map page (as viewed on a phone) looks something like this:

I also started working on another view to display the floor of the building. Current functionality allows the user to drag the image around, though I would like the image to sit in its own frame before adding javascript to move it around, and UI elements to allow the user to select a room to go to.

I worked on the Design Review Report, writing drafts of several sections such as the Use Case Requirements and Design Trade Studies.

Is my progress on schedule?

Yes, I was able to all of the Django web application tasks I wanted to accomplish this week, particularly with regards to setting up some of the main frontend pieces we need as, well as developing some models.

Next week’s deliverables:

Next week I will be working with my team to finish the Design Review Report. More research needs to be done for some of the contents, as well as a nontrivial amount of writeup.

For the web application, I hope to work on the display of the buildings. I need to work on the HTML to put the image in its own container with no overflow, along with some javascript to manipulate the position of the image.

Posted on

Weelie’s Status Report for 2/24/2024

What did I do last week?

Last week I started to work on UWB 1001. First of all, I tested the range of the UWB devices to check if that could fit our MVP requirements and use case requirements. I used two UWB devices that are seperated around 25 meters. And there were also some walls that could mitigate the signal strength. I set one of the devices as the sending and the other device as the receiver. At the last, I found that even with such distance and block, the receiver can still receive the signals from the sender. After that, I programmed the devices to measure the distances between two UWB devices. For the protocol of the two devices, I used RTT to measure and calculate the distances between two devices. And I made a Github Repository to keep all of our codes for UWB.  After uploaded onto the devices, I get that the accuracy of the distance measuring is very high, and is about 10 centimeters differences.

https://github.com/weelieguo/18500-dw1001

My process is on schedule as decribed on the Gantt Chart.

What will I do next week?

Next week, I will work on making the tag devices to be able to receive multiple distances and implement the localization algorithms for the tag devices. Also, since we might acquire a Raspi, I could also implement on the interfacing between UWB devices and Raspi.