Coordinates mismatches of the Tag even when connected with the same anchors

  1. Xtag: 15.86 Ytag: 123.52 Ztag: 0.0 Qf: 0 Anchor1 Name: 882E Anchor1 dis: 4.49 Anchor1 X: 12.05 Anchor1 Y: 124.7 Anchor1 Z: 4.4 A1 Diff : 0.11202129503982494 Anchor2 Name: 0B35 Anchor2 dis: 24.52 Anchor2 X: 15.19 Anchor2 Y: 99.44 Anchor2 Z: 7.71 A2 Diff : 0.014529182241776795 Anchor3 Name: 0F00 Anchor3 dis: 27.99 Anchor3 X: 1.38 Anchor3 Y: 98.59 Anchor3 Z: 7.71 A3 Diff : 0.2011847924133825

  2. Xtag: 14.0 Ytag: 122.86 Ztag: 0.0 Qf: 0 Anchor1 Name: 882E Anchor1 dis: 4.43 Anchor1 X: 12.05 Anchor1 Y: 124.7 Anchor1 Z: 4.4 A1 Diff : 0.10616578180295377 Anchor2 Name: 0B35 Anchor2 dis: 24.59 Anchor2 X: 15.19 Anchor2 Y: 99.44 Anchor2 Z: 7.71 A2 Diff : 0.06975326388414516 Anchor3 Name: 0F00 Anchor3 dis: 27.75 Anchor3 X: 1.38 Anchor3 Y: 98.59 Anchor3 Z: 7.71 A3 Diff : 0.326130431382456


Here in this case, Anchors are same in both the cases. Distance from anchors are almost same but still there is around 1.86m difference is observed for x coordinate.

This causes heavy flicker and error in getting the coordinates. Any help?

Who do you want to look into what?

You have a fairly poor geometry setup which means that small range differences can have large effects on position. That’s just how the maths works out, there isn’t anything you can do to change that.

If this is an issue for your application then either a) improve the geometry, b) implement a low pass filter on the output position to smooth out position noise or c) use your own position calculation algorithm that either has built in smoothing or uses more anchors to overdetermine the location and so average the noise down.

Hi Andy,

Thanks for your response. Can you elaborate please when you say we have a poor geometry setup?
As we have followed the guidelines to place the anchors.

Your anchors (to the nearest meter) are:
12,125,4
15,99,8
1,99,8

Your tag is at coming out as being at 15,124,0. Plotting these positions I get:

image

Good geometry is with anchors on all sides of the tag, it should be inside the square/triangle they define. As soon as you go outside of the area they cover your accuracy is going to go down. Ideally you don’t even want to be close to the edges of the area the anchors cover

It is possible to calculate something known as the GDoP (Geometric Dilution of Precision), that tells you the position error you can expect for given ranging errors and tag/anchor locations. It’s more often used for GPS but the same rules apply here. The actual maths is a little nasty but the upshot is that even if you have a constant uncertainty in range measurements your position accuracy can be all over the place depending on where things are.

Having said all of that putting your locations into my DoP calculator is only giving me an CEP of around 10 cm for your geometry (it’s about 4 cm in the middle of the area), far less than the >1m you are seeing. That would indicate that something else in addition to the geometry is having an impact on your accuracy here.

1 Like

Hi Andy,

These two coordinates were just an example where we found problem. We have a setup of more than 30 anchors in a large area wherein we saw this issue for one instance. It might be happening for other areas as well.

We wanted to understand the phenomena of the huge difference in coordinates being received even when the tag is connecting with the same set of anchors?

I took your locations and fed them into the excel sheet on this page: http://www.stonetabernacle.com/Trilateration.html

The first set give of data gives me a tag location of 12.8, 122.8, 0.5. The second set of data gives 13.4, 122.8, 0.6.

So given the range differences you got the numbers work out as giving a 60 cm difference in location. But oddly the locations don’t match the results from the Decawave position engine.

Does this mean that, there is a bug in Decawave Position engine?

This happens for us quite often, ~5% of times. It definitely causes errors and flickers in overall application which reduces the confidence in tracking the location accurately.

I wouldn’t go as far as to say there is a bug.

Their position engine produces positions that are not the same as would be produced by a simple trilatoration. But they may be applying weightings or corrections to the raw measurements when calculating a position and so the chances are that the differences are intentional. Or it could be that they made some shortcut or rounding in the maths to reduce CPU load that then results in a slightly different position result.

But ultimately the decawave system is a single implementation of a very generic positioning system. It is far from perfect and you could almost certainly produce a better system designed for your use. The question is whether it’s worth the effort.