Need Higher Data Rate for Smooth Live Tracking

[Rubinius01]

Dear @jremington, dear @pizzo00 ,
First of all, thank you for your work and for making it open source. I work in the field of event technology, where we have a 3D audio system. My initial idea was to use the UWB system to quickly determine the positions of the microphones on the stage so that the positions wouldn’t have to be manually entered into the software, which is time-consuming and not as accurate.

Later, I thought it would be useful to build a tracking system to track an artist in 2D and potentially in 3D space. I wanted to use the Makerfabs UWB chips and, if successful, make the system open source as well. I know there are commercial systems that already use UWB for tracking, but they are quite expensive and not open source.

After some research, I discovered your @jremington GitHub repository and gave it a try. My approach was for the anchors to send their data via Wi-Fi to a Python server, which would perform the trilateration and then send the calculated position data via OSC to a lighting console or other peripherals, such as a sound console or laptop.

With a colleague, I managed to send the position data to his laptop into Isadora (see Isadora), and generate a circle that tracked the tag, which we then projected onto our 10m by 9m stage. It worked quite well. We had some stuttering here and there, and the circle sometimes moved away from the stage due to high negative values. We didn’t implement any data smoothing. Our calculation error was about +/- 10cm, which is quite good.

Now, to the question I have: We’ve reached a data rate of 10Hz for the distance data from the anchors. To implement data smoothing and improve tracking performance, we’re aiming for a higher data rate. In your experience, have you achieved higher data rates, or do you think they are even possible? I know it depends on many factors. For clarity, I used your code and the library you provided, @jremington . Today, I tried to get @pizzo00's code to run, but I wasn’t very successful so far.

What do you think of the project? Do you think it could be suitable for live tracking, given the data rate constraints?

[jremington]

Thanks for your comments, and I'm glad that the work is useful to you.

I'm impressed that you are getting a data rate of 10Hz, and doubt you can do much better with the current version of the Thomas Trojer library in the repo. There is a lot of information being transmitted between the various nodes.

However, if you have followed the discussion about @pizzo00's version of the library (still a work in progress), you will understand that the library could be improved substantially. That could result in transmission of more compact packets, which could improve the position update rate significantly. However, I doubt that a factor of ten increase is possible.

I suggest to try implementing a data smoothing option that would allow 3D path interpolation.

[AndyA1002]

When tracking moving objects you hit an issue that the position calculation is assuming all the ranges were measured at the same time. Since they aren't you get a position error depending on the movement speed and the relative ages of the data.
As you indicated a higher update rate will always help with this. You can go a lot higher with the DW1000 but this becomes very dependent on the ranging library used and often involves other compromises. If you go all out for speed over flexibility then you can go a lot faster, there are commercial DW1000 based systems that output 12 anchor positions at 100 Hz.

Assuming the ranging rate is fixed you can still improve things. Rather than using the most recent ranges for each anchor instead take the history of the ranges and calculate the line of best fit for range Vs time. If you have an equation for range over time for each anchor you can then use those to then calculate values for the exact same time for each anchor. This has the advantage that the line fitting also acts as a smoothing filter to reduce the noise a bit. It does mean assuming a constant velocity so you can't take too much time into account but can help a bit.
If you have enough points you can always try for a quadratic line of best fit but that does require either a fairly high measurement rate or a long amount of time being taken into account.