Category: Thomas’s Status Reports

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.

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)!

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.

I couldn’t get the hardware to start integrating the entire system. Instead, I focused on getting the AR portion working, since, as I said last week, I think the localization system is as good as it will get without improving with real data. Currently, the AR portion is a python script, able to do self-tracking with updates every 50 mS and overlay spheres when a ‘target location’ is passed into it manually.

Next week will be doing what I should’ve been doing last week, integrating the system together and getting the basic ToF measurement working. Since PicoScenes doesn’t seem to be able to work with ACK packets, I’ll just reimplement the Scapy code already written by other members onto the Esp32.

Hello.

Currently, my main problem is I feel like the intricacies I’m testing are mainly on this current data set and may not apply to our finished product. I’m going to try and spend next week focused on product assembly. Hopefully, by the end of the week, we will have a working setup to collect data which I can then use to test my localization algorithm.

I’m still investigating the larger errors in the localization. It looks like our data set has errors that linearly correlate (r=0.519) fairly strongly with each other. This means that targets that are further away under-estimate their locations, while targets that are closer over-estimate locations. So, in data traces where we have very directional samples or are slanted towards being far or close, we will see systematic errors. I still need to think of a way to address this, but I think it will involve some weighting based on the ‘diversity’ of a location for each point. So, every ‘location’ which was scanned contributes an equal amount to the final total.

I spent a lot of time this week on the design report, redoing our architecture figures to be more detailed and discuss through all subsystems. The report also gave me a chance to formalize all of the equations I’m using for my localization system, which will hopefully make it easier to explain and demonstrate how it works in the future.

I got a chance to implement the improved ToF-based ranging (with SIFS measurement including, as discussed in last week’s post) and even without angle, we seem to be getting close to the margin of performance which we expect. There’s currently an error a median error of around 1 m in both x and y, with some systematic bias based on where the access points are. I’ll be looking into the more extreme cases (namely the middle and bottom) to see if we can detect the faulty measurements that are contributing to the shift in position, either through restricting the SIFS measurements, restricting longer ranges (more likely to be NLoS), or balancing samples depending on the transmitter’s location at the time.

Investigat ed where the errors in our current localization scheme were coming from. It looks like the SIFS (short interframe spacing) time or multipath time is not accounted for by our current data set – which will reflect real-world conditions betters, thankfully. Looking at the plots below, each AP (Access Point) has some spread to the error, with the mean error differing between each unit. The solution to this will be adding a constant error term into the MLE optimizer, which, as it seems, is different for each AP.

I’m a little behind schedule now due to this issue. I can’t prioritize this class over exams/travel next week, but I will be working on the localization over spring break.

I hope to integrate the SIFS time into the MLE problem we are currently solving for the location of targets, which will hopefully get the 2m performance I discussed last week.