Posted on

Thomas Status Report for 4/29

I think I figured out the error in the localization that we were seeing –  the ToF is getting multiplied by 2 somewhere in the new pipeline, so dividing it back out now solves the issue. Temporary fix, but it makes our system work overall.

This past week, I’ve been working on the poster design and preparing it for our testing to get final accuracies tomorrow. The overall style looks goo,d now we just need to add graphs that show accurate the system is and how closely we’ve achieved our goals.

This keeps me on track with the schedule.

Posted on

Team status report for 04/29

We’re all caught up to our requirements. We spent last week polishing our system and getting it ready for presentation. We will be recording our final data to use tomorrow now that we are all in Pittsburgh.

We will reuse the theming from our final presentation slides for our poster, which is under construction.

The worst-case scenario is our demo breaking the day it gets shown. We will make sure the video can be used as a substitute in case of failure.

Our tests involved unit tests for individual components, i.e. device detection, device pinging, device localization, and self/AR localization, and integration tests. For device detection, we put several devices in a network and tested if it detected all the devices; for pinging, we pinged a known device and observed the ACK packets; for device localization, we localized a known device at known location, and measured the error from the expected to the actual location; and for self and AR localization, we put an AR object in a known location and checked visually. For integration testing, we moved through different traces with devices in different locations and networks.

Posted on

Ethan’s status report 4/22

This week we worked on preparing for integration and the final presentation. For integration we worked on testing individual parts and putting the pinging and localization script together. We are not fully finished with integration in that we still need to connect having multiple device detection with localizing a device, but other than that we’ve seen steady progress. For my part, I’ve tested that device detection works on multiple devices with the devices we bought. Next week, we will do the presentation and work on finishing integration and making it presentable for the final demo, as well as start working on the report.

Posted on

Thomas Status Report 4/8/2023

I figured out how to make the localization gradient descent converge better: we either need to fix the SIFS measure or optimize it some other way. All of our traces, even ones we thought were failures before, work with a value for the SIFS that doesn’t cause avalanching in the localization. I still need to figure an alternative to optimize for this SIFS initially, or if it needs to be fixed to a constant.

I also got the Matlab program running in the python engine – so our entire program stack can be run together now, just need to add in the data collection.

Next week, I’ll be working on polishing the AR interface for users (adding text, instructions, and consistent updates)!

Posted on

Ethan’s status report 4/8

This week, we worked on getting a demo working and started working on integration. The demo was integrating the ESP, pinging, and localization to get a sense of how accurate the localization algorithm is. We decided to not use PicoScenes as we were able to get data we need from the ESPs, so some of what I’ve been doing is no longer useful, but it is good that we can get all necessary data from the ESPs since I wasn’t able to figure out a way to make PicoScenes detect the ACK packets from our pinging. Meanwhile, I worked on testing and cleaning up the device detection script, which it does work. I’ve changed from manually sniffing beacon frames to using iw for the access points, since manually sniffing can sniff access points from adjacent channels which show up as two same access points on different channels. I’ve also tested how long it takes for the devices to respond to my beacon packets, and it seems like about 7 seconds is enough. This can’t get too long, as there may be arbitrary number of access points and our aim is to have everything (from device detection to localization to visualization) be within 5 minutes.

I am testing my part on my local network, and have verified that it detects my phone and ipad consistently. More tests would be possible when our device arrives, with multiple access points that we have control of. Next week, we will continuously work on integration, and I will personally look at device identification to show the users, such as manufacturer, the transmission rate, etc. I am a little bit behind on the device identification, but it should be possible to catch up by next week.

Posted on

Team status report 4/8

This week, we worked on getting the demo working. Our demo consists of our laptop pinging a phone, and measuring ToF of the ping from an ESP; the data from the ESP is then fed to a MATLAB script that localizes the device. We were able to get localization within 1 meter accuracy in the demo, and we also video recorded the process. We started working on integration of our individual parts, and we ordered some IoT devices that we will use for testing our integration as well.

Not much was changed from the design, except that we could not get PicoScenes to work so we are using ESPs to do the ToF and RSS measurements. We got two ESPs that we worked with, and there is no significant cost because we already had more than enough budget.

Posted on

Team Status Report 4/1/2023

Last week, we actually verified all of our individual parts together and collected our first data traces. Results are promising, as we see increased accuracy from the higher clock speed of the ESP over the prototyping data we were using. No changes have been made to the system, but we’re considering working with a different infiltration method (RTS/CTS frames) if we can not get picoScenes measuring ack frames.

The biggest question mark for us is the clock drift in devices we saw occurring. This means that one of our wifi devices was taking longer and longer to respond to packets (due to overheating or clock slowdown), even if the distance between the RX/TX was the same. Our contingency plan for tackling this is using shorter windows, and possibly restricting the users movement to when we want them to. This would allow us to know when clock drift is occurring and when it is user movement causing an increase in ToF.

Posted on

Thomas Status Report 4/1/2023

Hey, happy april fools.

Last week, Anish and I collected our first actual data trace with the ESP32 for ToF logging. I finished up scripts for self-localization and visualizing the data traces, while Anish coded the ESP back end for measuring ToF. This should put us back on track for our schedule and on pace to meet the demo on Wednesday.

General thoughts about the data: ToF is a super noisy measurement, we might need to increase our scanning time in the final system. The accuracy is a little low, but this is mainly due to some clock drift that’s happening in our transmitting laptop just because its super old. We’ll have to figure out how to distinguish the clock drift from actual SIFS timing or movement next week.

Next week, I’ll focus on preparing for the demo and improving the processing with the actual data we collected. Results are promising (the trace where we got everything working was within a meter of the target), but we need more testing to verify it.

Posted on

Ethan’s Status Report 4/1

This week I worked on cleaning up the scripts I wrote. I couldn’t figure out a way to make PicoScenes detect null/ACK packets, so we might not be able to use it for ToF measurement. I think we can use it to measure RSS data because it doesn’t really matter if the timing is not too accurate, but at that point perhaps using PicoScenes is more of a burden than what it’s worth. For next week, I’ll be working on preparing for the demo and cleaning up rest of the scripts.

Posted on

Team Status Report for 03/25

This week we started working on integrating our individual parts. We are a little bit behind since some of the parts aren’t working optimally, but we at least have prototypes of the ESP32 pinging, Scapy device analysis, 3D localization, and the localization filter (in Matlab) that we are working on integrating together.

Next week we will be working further on integration and also testing our components with the testing devices we ordered. We hope to have a proof-of-concept (even if it still requires some tuning and polishing) of all of the components integrated together ASAP. Additionally we will work further on building out the end-user interface.

Most significant risks right now are that PicoScenes is not detecting our ping packets, which our approach for measuring ToF and RSS data depends on. The backup would be to rely on a combination of Scapy and the ESP32, which is less accurate but at least we know that it works.