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

Anish’s Status Update 04/08

This week I made substantial progress on the system integration. I ported the pinging-initiator code to run on an ESP8266, and added an interface to configure and pull data from the ESP32+ESP8266 combo, over the UART, in real-time (the need for two microcontrollers comes from the inability to precisely timestamp outgoing packets, so we must send packets from one microcontroller and timestamp both the request and the response on the other). I’ve tested this against the rest of the system (by generating CSV files and piping them into the MATLAB pipeline) and it works quite well in terms of efficiency and reliability.

My next step is to finish integrating it with the rest of the stack by completing the wireless interface (which means the computer running the system doesn’t need to be carried around with the user while they are doing their scan) and writing the Python interface to allow integrating it with the device-detection and localization code. I’m a little worried about wireless reliability with the XBee radio I’m currently using, but there should be a way to make it work with a proper handshaking interface. As such, I feel like we are pretty on-schedule although will need to do substantial testing and debugging-integration in the next two weeks to get everything working.

The testing we need to do once everything is working is to walk around in a room and collect data; and then take various subsets of this data (to test for different timescales and movement patterns) and determine the accuracy of locating the different devices. This, combined with some unit-testing of the self-localization and visualization accuracy, should allow us to quantifiably verify our use-case requirements and metrics.

 

 

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

Anish Status Report for 04/01

Over the past week I worked on fixing some bugs in the ESP32 code and using it to start collecting data traces to test our algorithms with. It works better than expected; after filtering outliers and doing smoothing, the results are pretty consistent with what they should look like (at least over a several-meter range). We’re still trying to get it working on short ranges as well. There are no major roadblocks that I see blocking us going forward. I also started taking data measurements with the Yagi directional antenna to see if that data can be useful to our final algorithm or if the ToF data is sufficient.

In the next week I’m hoping to work on the end-user interface and figure out how we’ll actually stream the results out of our algorithm and display it to the user.

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.