Author: Thomas

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.