TDOA measurement debug

[Guglie]

Hi,
first of all thank you for all this amazing work with Loco Positioning!

I'm debugging a TDOA setup with 8 nodes, here's the 3 raw TDOA readings using the first 4 nodes:



Here's roughly the 0-3 nodes placement and in green the 5 positions where I moved the tag.




The nodes are in forceTxPower mode, the readings were worse using smartPower, maybe that mode is too weak for the size of this setup which is about 5.8 x 9.5 meters.


To have a closer look at the graph I've also attached it, while the TDOA 1-0 behaves like expected, the other two have a lot of oscillations, the 3-0 TDOA reaches 3 meters error.

Another strange behaviour emerges looking at the 3-0 TDOA (magenta) in last two positions, P2 (near node 0) and P5 (near node 3). The distance between 3-0 nodes is 11.2m, so I expect a TDOA value in the [-11, 11] range, but the true reading goes from 15 to -7.5. What can cause this bias?

Is this a known problem? What configuration/settings can I try to solve it?


Note that I've tested all the nodes placing every couple (1-0, 2-0, ...) in the same place, with the tag in various positions between them. Every couple worked well in that setting with little or no error and no bias.

Thanks!

[arnaud]

The oscillation looks odd and this is not something we have observed before. Intuitively it looks like multipath to me, are the anchor close to a very radio-reflective material like metal or concrete and is the line of sight clear of obstacle?

I am curious as of how the estimator behaves with these input data, is the position estimate stable?

Ps. A random though: how are you getting these values? The TDoA algorithm in the Crazyflie is capable of skipping anchors and so it will calculate TDoA between A0 and A2 if the packet from A1 was not received or discarded, so when taking log of TDoA both anchor from and to should be checked and filtered.

[Guglie]

Hi Arnaud, thank you for your reply!

are the anchor close to a very radio-reflective material like metal or concrete and is the line of sight clear of obstacle?

The anchors are at 20cm from concrete, the line of sight is clear.

it looks like multipath to me

I suppose it is not, I swapped anchor 1 (closest to anchor 0) and anchor 3 (farthest) and result weren't significantly changing: TDOA1 was optimal, TDOA3 bad.

I am curious as of how the estimator behaves with these input data, is the position estimate stable?

I don't know, I'm studying a custom localization algorithm for a research project, so I'm trying to figure out "good" settings and sensor readings.

when taking log of TDoA both anchor from and to should be checked and filtered

I'll double check that, but I think it is done correctly, by the way I'm calculating the TDOA between anchor 1-0, 2-0, 3-0, and so on..



I've tried to set TDMA_SLOT_BITS to 27 in all four anchors as suggested here:

then adjust the TDMA_SLOT_BITS to 27, the wrong value reduce, but occurs once Occasionally.

And the results are quite promising, except some spikes with a very big value (around 150 meters) that can be filtered out:

But (obviously?) setting TDMA_SLOT_BITS to 27 in all 8 anchors led to very bad results for half of them.

I suppose that the answer is no, but are there any settings that you change when you add 2 anchors from 6 to 8?

Thank you!

[arnaud]

Are you using the stock firmware in the anchors? If so can you tell me the commit/version you are using and the configuration of each anchor so that I can try to reproduce the problem here.

The anchors communicates one after each other following a TDMA scheme: Anchor 0 is the master and sends its packet on timeslot 0 then each anchors will send their packet on their own timeslot. TDMA_SLOT_BITS is setting up the width of the timeslot. If the width is too small, collision can happen between anchor which might leads to the kind of problem you are observing.

I have had this kind of problem during development but I have not seen it since TDoA has been stabilized. This is why I am interested about your exact configuration.

[Guglie]

Are you using the stock firmware in the anchors?

Yes, I'm using the last commit, I've only added a serial submenu for power settings (I'll make a pull request soon with that)

If so can you tell me the commit/version you are using and the configuration of each anchor so that I can try to reproduce the problem here.

Thank you! The tests where on 4 anchors with IDs 0-1-2-3, forcetxpower mode at 33.5dB (0x1F1F1F1F), placed at 17cm from the floor on small wood stands with the antenna pointing up and facing the center of the room, the positions are like the ones in the "map" from the first post, setup size 5.8 x 9.5 meters, the distance from the concrete walls is at least 50cm. The next graphs are obtained with 17dB power which seems the minimum in this setup to make all the anchors receive well the packets from anchor 0.

By the way yesterday I've made a lot of tests and I'm quite sure that it is not an hardware or configuration problem. I've swapped a lot of anchors, moved them, changed power mode and value, changed the anchor 0... what I have found is that some IDs (not physical anchors, just changing ID) seems to influence the reading of some other anchor IDs. For example this is a much better result achieved using 4 anchors in the same positions as in the previous graph, but setting their IDs to 0-3-5-6:

Here's a more comprehensive graph with 0-3-5-6-7 plus various combinations of 1-2-4, clearly when turned on they affect other readings:

(the horizontal lines below the graph represent when the anchors are turned on)
The n.1 seems to add oscillations to 2-3, n.4 to 5-6, n.2 a little to 5...

I suspect that the problem is in the tag reading code, as you suggested in your first reply, do you agree? I'll review that!
Have you any other suggestions apart from the anchor skipping?