Weelie’s Status Report for 4/27/2024

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

Last week, I mainly worked on 2 things.

First of all, I prepared for my final presentations. I spent the whole last weekend and monday on preparing it.

Second, I continued to work on optimizing the localzation algorithms.  I added a filter that could check the walking speed. If we detected that the walking speed is too fast (unreasonable), the filter will block the location updates.  Also, I helped Ifeani to incorperate the rotation to the localization system. Now our system should be able to generate proper rotation.

Besides the above changes, I worked with the whole team to set up the system in a broad area that is similar to the gym. We made sure that signals are covered everywhere.

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

  • Is your progress on schedule or behind?

Based on the schedule, we should work on the final testing stage, which is on schedule.

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

This week, we will make our poster and do more testing to make sure that our system is stable on the final demo day.

Jeff’s Status Report for 04/27/2024

What did I do this week?

I spent this week assisting my team by working on the final presentation and collecting data whilst testing various facets of the verification/validation portion of the project. I also spent time developing user authentication and profiles for the web application portion of the project.

I worked with my team to collect material for the final presentation, doing some additional testing on Sunday to get more solid numbers on metrics regarding localization accuracy and total system latency by testing the system in the hallways of ReH 2 and 3. I also worked on capturing a short video demo to include in the demo presentation.

After the final presentations, I spent time addressing some of the ethical concerns that spawned out of our ethics readings and discussions done previously in the semester. In particular, I wanted to improve the security and privacy of the application by introducing user authentication and profiles. Django conveniently has authentication built into its framework. However, I needed to go through a bit of the documentation to understand what exactly I needed to implement. For example, I learned that Django had prebuilt forms and views specifically for handling logging in and creating accounts. However, I had the option of writing my custom HTML page to display the login form to have the design of the website conform to the rest of the website.

Then, I tinkered with some of the capabilities of the “account registration form”, having a custom inherit the built in form to help me easily create a database model of associating additional information with the default Django User model (such as the person’s name, or the tag ID they were using). I created a view for handling creating new accounts, in which I added some capability of returning errors to the browser in case the user entered in something incorrectly. The video below displays the capabilities of the authentication system, with the user being directed to create a new account, as well as being able to edit some aspects of their account and sign out using a profile page.

Link

Near the end of the week, I met again with my team to test the rotation capabilities of the device, as testing the localization system in a larger, open area that might somewhat resemble the Wiegand Gym (in this case, the Engineering Quad). Additionally, I worked on mapping out the Wiegand Gym, creating several graphs of areas that we could have the navigation system operate in. These images are shown below (with the assumed available navigation paths shown in green, representing “hallways”). I have previously measured the dimensions of the gym; hence, the former image involves a ~30×15 meter walkable path, and the latter image involves a ~40×30 meter walkable path.

 

Is my progress on schedule?

From the progress with the user authentication system and the progress with mapping out the Wiegand Gym, my progress aligns with what I have planned to do this week.

Next week’s deliverables:

Next week I will be working on the final deliverables for the project to round out the semester. I will also be doing further testing with my team to ensure that both the navigation and localization systems are ready for demo day. Additionally, there are some aspects of refinement I can still implement before demo day. One particular aspect is the frequency of new navigation system GET requests the browser can post to the server. Currently, the browser’s JS can spam the browser with GET requests with no delay; however, I do wish to increase the minimum delay to ~3 seconds.

Team Status Report for 03/30/2024

Significant Risks

This week we made progress on creating smoother localization calculations, improving the stability of our location estimates by using distance averages, 4 anchors instead of 3, and using gradient descent (decreasing the volatility of a “bad” distance measurement).

Through our testing this week, we have stumbled upon an issue regarding the configurations of our anchors. Currently, each anchor is configured as an initiator. From our understanding, this means that if a set of anchors is sufficiently far from another, they may choose to create a separate network of anchors. The problem arises in our tag device, which can only read distance measurements from a single network at a time. However, we believe it is possible to resolve this issue by reconfiguring our network of anchors to only have one initiator.

Additionally, the IMU we are using seems to have a few systematic inaccuracies when we are reading from it. Ifeanyi is currently working on resolving these issues with calibrating the IMU.

Changes to System Design

This week we made improvements to both the webserver as well as the localization system. We have found an issue with our network of anchors; however, we believe that reconfiguring the anchors will allow them to function the same way we originally envisioned. Because of this, there was no need to make any updates to the system design. 

Schedule

We would like to continue improving the localization system for the following week. Firstly, we would like to make improvements to our network of anchors and possibly try decreasing some of the latency present in our localization system getting positional updates. Additionally, we would like to finally incorporate the IMU’s orientation data. Finally, the navigation system needs to be worked on to display the path between the user to rooms.

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

Progress

Here is a video of our localization system posting updates to the user’s phone as we walk down the HH A-level main corridor. We see a significantly more stable localization than the previous week. Please ignore the orientation of the arrow; the tag is generating random angles (they are there for a visible indication of the update frequency).

Video link

 

Here is a video showing our browser with more clarity (using randomly generated data). It showcases the higher update frequency and decreased latency as a result of using the websockets instead. Additionally, the video displays the indicators present for when the tag is not connected.

Video link

 

Introduction and Project Summary

Have you ever gotten lost trying to find a classroom in a building at CMU? Rhetorical questions aside, we wish to create an application and device to aid students in easily finding their classes. Our goal is for our device to use indoor localization to accurately provide the location of the student’s location from within a building. We wish to create a portable, lightweight device the student can easily carry around. Furthermore, we will create a responsive webapp user interface that displays instructions of the best path the student should take to their desired location. Ultimately, we would like Scotty Maps to be a tool for students to save time and learn how to navigate the buildings on campus.