Category: Team Status Reports

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.

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.

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.

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.

We cleared out a big obstacle this week – doing ToF measurements. We were donated a copy of PicoScenes Premium, which will allow us to integrate ToF and RSS sensing on the same platform/WiFi chip. This will make our system cheaper and simpler to implement than our previous plan of using an ESP32 chip for ToF.

Next week we will be actually wiring and hopefully starting to run our physical system. We feel like we’ve reached the limits of what we can do theoretically so we need to start collecting physical data to get feedback on our system.

Most significant risks right now are that our progress from our individual work may not transfer over into the integrated implementation. Now that we understand the solutions and how they work, we think that we would be able to reimplement them much quicker than our first time.

Currently the risks are getting ToF measurements that are not accurate enough, and integration of individual parts that we have been working on.

We’ve committed to using ESP32 for our ToF measurement, as the measurement from PicoScenes would not be accurate enough. Additionally, since PicoScenes only runs on a specific linux kernel version with a specific ubuntu version, we are not going to use Raspberry Pi. The changes are documented within the Design Report. As mentioned in the previous status report, this change would cost us about 1 week of implementation time.

Since we decided on using ESP32, we will have to learn to use its API, but its documentation is fairly well done so it would not be a significant risk.

Going into next week, we will be working on the design report with the feedback we got from the presentation. Mainly, we will be refining our test plan and making sure all of our metrics align with the tests we are proposing.

The most significant risks right now come down to integration with all of the hardware we are using – the two antennas, the RasPi, and our WiFi card(s).  We will order an ESP32 card as a back-up, which we know we can get working based on some of our reference papers.

We’re considering maybe using a different WiFi module for measuring ToF, depending on whether we can get a rough ToF estimation working on picoScenes – the free implementation only comes with rough time measurement, not the 320MHz fine-time measurement possible with WiFi. We would probably end up buying an ESP32 to use and only 1 antenna for measuring ToF, but we haven’t committed to making the change yet. This would increase our implementation time by around a week.

To date, we are mostly up to speed with deadlines, with Thomas falling slightly behind on the localization front due to changing requirements/system topologies. He has started working with a sample data set from Intel to prototype the localization system until we can get real data to work with, which should be able to make up for lost time. Ethan can now start working on scripting measurements now that Polite Wifi is working. Teaming is generally working fine, since most work in the beginning can be done individually and we are communicating via Slack. Once integration starts, we will be working more in teams.

We spent some time this week reviewing the feedback from our project proposal and ensuring that our project scope was well-defined, including constraining our use-case to static devices in an indoors environment, but also adding the requirement that we be able to distinguish multiple devices physically close to each other. These are already requirements that we had in mind, so the main change is just documenting them properly. As a result, there are no added costs or schedule changes.

We were able to test the CSI data produced by the AX200 wifi card using PicoScenes, and saw that moving the device around / moving ourselves in front of the antenna would affect the measured signal-strength and phase data; so we know that we are able to get meaningful measurements. We also verified that we are able to get individual signal-strength data from each antenna, which is useful for verifying

The main risk we are worried about is whether the fidelity of our data (in terms of noise and quantization) will be high enough to get the level of accuracy we want. Our contingency is based on the fact that we have a variety of different measurements which we are fusing together, so we’re expecting that with all the data combined, we’ll be able to get sufficient accuracy and meet our 1m requirement.

The main principles of engineering we’ve been using so far include electromagnetism and RF (in terms of choosing antennas and the considerations of multipath propagation); signal processing (interpreting the data we get from the wifi card, phase-difference-of-arrival, etc.); and some probability/statistics (in implementing the filtering algorithm to deal with noise in our measurements).

Below image shows our current experiments using an open-source dataset (“Intel Open Wi-Fi RTT Dataset“) of time-of-flight data between client devices and access-points, and attempting to find the location of the APs using this data.

 

 

Our proposal presentation was done by Thomas on Monday, 2/6. We worked on getting started on our project after the proposal, which included submitting an order for AX200 wifi card to be used with PicoScenes, conducting further research on our respective areas, and getting PicoScenes set up.

Right now, our biggest concern is making sure all of our hardware will correctly interface together. We have double-checked the documentation and made sure that there will not be too much leg work required, but are still worried we have missed something. Our first chunk of development will happen on a laptop, so other than antennas or the wifi card, we don’t rely on other extra hardware which means getting parts is less of a concern. We’re currently ahead of schedule since this week was reserved for the proposal and initializing. There are no changes to be made to the schedule; likewise, there are no changes to be made to the existing design.

Our project includes considerations for privacy of individuals – our project aims to enable the users to be aware of what kind of IoT devices exist around them, which is especially valuable since IoT devices that can spy on people can be prevalent and hard to detect by visual means; while this may be a concern for locating individuals from their devices, we are building our system assuming access to walk around the space and constant devices, both of which we think will minimize possible harms to individual privacy.