Fluctuating errors - lps anchors but other system

[IDaniele]

Hi,

I'm integrating your TDOA location system in ardupilot. I'm using anchors with your firmware(old tdoa) but the UAV runs arducopter.
To calculate the position I'm using a least squares on a linearized system.
The code I use to get distance differences is similar to yours but always referred to anchor 0 (i.e. every tdoa is between anchor x and anchor 0).

I've done some testing and the error on the position (least square solution minus real position) changes a lot based on UAV's position.
I've used 7 anchors (soon try with 8) they're placed as 2 triangles, one on the floor and one on the ceiling, plus one extra on the floor.

Here's a link with the data I got and some graphs:
https://drive.google.com/open?id=0B27wh ... ElqRktOUmc

So the error isn't spread equally but it seems to go bad on one axis at a time.
Do you have some suggestions on the matter? Have you noticed related issues while testing the crazyflie?

[kristoffer]

Hi!

We have not done any real investigations on error distribution and related properties for TDOA so this is interesting!

I have not had time to dive into your data yet, but I hope to do it soon. Until then you might find this paper interesting http://mikehamer.info/assets/papers/Led ... 202015.pdf if you have not already read it.
TDoA pretty much only works within the convex hull (https://en.wikipedia.org/wiki/Convex_hull). Are your problem areas inside or outside the convex hull? (Two way ranging on the other hand works surprisingly good pretty far away outside the convex hull)

It sounds a bit weird that you see problems on one axis at a time, not sure why you get this and it is not something we have seen. In our implementation we usually see more errors on the Z-axis (compared to X and Y) but we think this is possibly related to the velocity estimation in the Kalman filter and vibration noise from accelerometers, but we don't really know.

It would be interesting to hear what kind of errors you get with 8 anchors configured as a cube, when you have one more anchor.

I'm not sure if it is a problem to always use anchor 0 as a reference, but I don't think it is.

Please keep us posted on your progress!

[IDaniele]

Thank you for your answer kristofer.
So far I've test only inside the convex hull.

Until then you might find this paper interesting

Yes, I already found that paper but it seemed a bit too difficult to put into practical use. I'll check it again though.

It sounds a bit weird that you see problems on one axis at a time, not sure why you get this and it is not something we have seen. In our implementation we usually see more errors on the Z-axis (compared to X and Y) but we think this is possibly related to the velocity estimation in the Kalman filter and vibration noise from accelerometers, but we don't really know.

So far I didn't use EKF. The data I'm referring about is the position calculated by doing the least squares on the data from frames of 7 packets.

[IDaniele]

Hi, now I have 8 anchors placed as a cube and I also upgraded them to TDoAv2.

What I'm seeing now is that the position that I get (with least sqares) is shifted toward the center of the cube... by a lot, it moves just a little.

I also tried to modify the method that I used so to utilize the same TDOAs as you (between anchors 0 and 7, 1 and 0, 2 and 1...ecc).
This is the data of the TDOAs taken with still position: https://drive.google.com/open?id=1ca3Zm ... Ps4QLW8GER

Is this data similar to yours? (I mean the variation among every measure)

The final result varied just a tiny bit between the 2 methods.

[kristoffer]

Cool, trying TDoA V2 is really on the bleeding edge! Kudos!

We added sequence numbering of the UWB packets (among other things) in TDoA V2 to be able to detect packet loss and understand when to reject data. I can see in your data set that there are a few 0:s here and there, (if your implementation is similar to ours) this is when we reject data due to a missing packets or similar.
I can also see that there are a few outliers in your data set. We were hoping (and still are) to be able to get rid of those by improving the algorithms, but obviously we need more work

What I'm seeing now is that the position that I get (with least sqares) is shifted toward the center of the cube... by a lot, it moves just a little.

Do you mean that it is shifted to the wrong position or closer to the true position?
Are you using the "0" data and outliers in your calculations, or do you discard them?

Is this data similar to yours? (I mean the variation among every measure)

I think it is about similar, I have not analysed the data very thoroughly so this is just my gut feeling.
TDoA V2 is not finished yet and when we worked on it last time I know we had some issues with outliers that we did not detect yet. I think that the more outliers/bad data that can be detect on a protocol level, the easier it will be to make a good estimation of the position.

The current implementation of TDoA V2 is a good step forward from TDoA V1 though even if it is not ready yet. In TDoA V1 we have this line

Code: Select all

if (tdoaDistDiff > -MAX_DISTANCE_DIFF && tdoaDistDiff < MAX_DISTANCE_DIFF) {

which is a pretty crude way to reject outliers and lost packets

[IDaniele]

Hi kristoffer,

Do you mean that it is shifted to the wrong position or closer to the true position?

I'll make an example, the cube of anchors have a center point (more or less)... if I measure the tag position near that point the measure is very precise, if I move the tag away from it the measured position will move less than it does, kind of like a scale model. So getting away the error gets bigger.

Do you have any Idea to improve this?

Are you using the "0" data and outliers in your calculations, or do you discard them?

For now I use them, it's difficult not to use the "0" since they can be perfectly elegible values, about the outliers I still have to think about that.
But in my case I wait to use a whole frame at once so I might be able to do something.

Also, how much near the side of the cube can you go getting good measures? To me they start to get bad already about a meter from it.

Do yi

[IDaniele]

Checking around I found that the Time of flight in

Code: Select all

uint16_t distances[LOCODECK_NR_OF_ANCHORS];

its different from what I would've expected.

The values that it gets with my configuration go around 33000-34000 clock ticks. Multiplying this for

Code: Select all

SPEED_OF_LIGHT / LOCODECK_TS_FREQ

yelds 155-157 meters. I don't understand this.
My anchors are 4-6 meters apart and the time took from packets to travel should be around the thousand clock ticks.

Setting the tof to 0 makes the TDOAs go to 155-157 metes (again).

Can you explain this behaviour?

Also... why do you use the light' speed in the void? Shouldn't it be the light' speed in the air?

[kristoffer]

Hi!

The weird distances (155-157 meters) is due to the antenna delay. It basically takes a while for the radio waves to propagate through antenna and this adds a delay of about 154.6 meters in our hardware. In our SW implementation you can find this in the .antennaDelay member of the algoOptions struct in https://github.com/bitcraze/crazyflie-f ... locodeck.c. To get the correct distance you have to subtract the antenna delay from the measurement. In TDoA the antenna delay is cancelled out since you are calculating the difference between two anchors (and we assume the same antenna delay in all anchors, which might not be completely true, but probably close enough).

[IDaniele]

Thank you, that makes it clear about the time of flight.

What would you say about my other questions berfore?
I think the position being shifted to the center is the same behaviour that I described in the first post but more regular because of the more regular anchors' placement.
I checked the error in the measured TDOAs and it's under what the algorithm I use can handle compared to synthetic data with random noise. That made me think of a correlation among measurement's errors (which is why I checked the tof).

Do you have any suggestions?

EDIT:
Do you think my anchors are too close?
x y z
0.000, 0.000, 0.000
0.071, -0.270, 2.950
0.161, -4.880, -0.011
0.300, -4.820, 2.901
5.111, -4.470, -0.012
4.886, -4.380, 2.937
4.901, -0.350, 2.980
5.184, -0.216, -0.031

[IDaniele]

I've done various tests to try to mild the possible correlation among the TDOAs, the results (so far) are really mixed, in some areas it really improved the outcome but in other it either worsen it or had little to no effect. I'm not sure if there's a proper method to do this, so far I'm proceeding by trial and error.

Do you think the problem is somewhere else or am I doing right?