Dilution of Precision for ubisense measurements

[Kavitha]

Hi,

Has anyone calculated the dilution of precision for the ubisense measurements?

I see that the value GDOP is left as '0' in the .xcm file. I think this is intentionally left '0', so we cannot back calculate timing from the GDOP. Am I right? But I would like to calculate PDOP (position dilution of precision, atleast for a 2D case) as a metric to evaluate the accuracy of the ubisense, and this does not require timing information.

I have done measurements at certain static points within the cell, whose location is known (by surveying manually). I use the standard formula for calculating the PDOP (computing the pseudo ranges, directional derivatives etc.,) as the one suggested by Andy in one of previous posts in this forum. Can anyone point me to what is the optimal value for PDOP?

The problem I have is, for some measurement points, the PDOP value I calculate is much higher (in the order of 100's). I should like to filter out the bad measurements using PDOP as a metric. I am not sure, if this is already done within the location engine?

Also, can DOP be worked out for cases when number of sensors seeing the tag is less than 4?

Any pointer to this would be useful.

Thanks,
--
Kavitha

[Andy Ward]

Hello Kavitha,

> I see that the value GDOP is left as '0' in the .xcm file. I think this is
>intentionally left '0', so we cannot back calculate timing from the
> GDOP. Am I right?

No, the field is zero because it is currently unused, not because we are trying to hide something! Future versions of the location engine will compute the GDOP/PDOP on-the-fly and include this information here.

> I have done measurements at certain static points within the cell,
> whose location is known (by surveying manually). I use the standard
> formula for calculating the PDOP (computing the pseudo ranges,
> directional derivatives etc.,) as the one suggested by Andy in one of
> previous posts in this forum. Can anyone point me to what is the
> optimal value for PDOP?

I've had a look back through the archives, and I think the formula you are referring to is the one for GPS, which is a pure TDoA system. The Ubisense system is a hybrid AoA/TDoA system, for which the DOP calculation is much more complex. Unfortunately, I don't have a simple closed form for this which I can give you, because the version I have exposes a lot of the details of our location algorithm.

> The problem I have is, for some measurement points, the PDOP value I
> calculate is much higher (in the order of 100's).

If you are using the GPS PDOP, what you may find is that you're computing the full H-and-V DOP, but with a pure TDoA system (like GPS) and typical sensor placements (in a plane near the ceiling of your room), the VDOP is typically terrible. This may push the PDOP to the levels you are seeing (if you use that algorithm and consequently only look at the contributions of the TDoA measurements). It would be interesting to compute the HDOP and VDOP separately, and see which component is generating the biggest contribution.

Of course, even if you identify that the HDOP is good but the VDOP is bad, this doesn't really tell you what the Ubisense system is doing, because you aren't taking into account how the AoA information is affecting the DOP.

> I should like to filter out the bad measurements using PDOP as a
> metric. I am not sure, if this is already done within the location engine?

No, this isn't done in the location engine, but obviously we may do that in the future.

> Also, can DOP be worked out for cases when number of sensors seeing
> the tag is less than 4?

Yes, DOP can be calculated for any situation in which you generate a position. In the case of the hybrid AoA/TDoA architecture used by our system, we can compute a 3D position with only two sensors seeing the tag, and it would be possible to determine DOP in that case (with the more complex algorithm I mentioned above).

Regards,
Andy Ward

[Kavitha]

Hi Andy,

Thanks for your reply. Yes indeed I was using the formula meant for GPS. I agree that this excludes the use of AOA data. But I was under the impression that if I eliminate the readings with the number of sensors used less than 4 (or 3 for a 2D position), it should not matter as I thought the AOA are mostly used when a position fix with the TDOA cannot be worked out. But I might be completely wrong!

Anyway since the PDOP is not really giving anything useful, I am working out HDOP and VDOP seperately ( I expect that the VDOP is the factor that brings high PDOP values) and perhaps calculate DOP using AOA for cases when the number of sensors is less than 3. I am not sure if this is the right way, but anyhow shall give it a try.


Thanks anyway!

--
Kavitha

[Andy Ward]

Hi Kavitha,

> But I was under the impression that if I eliminate the readings with the
> number of sensors used less than 4 (or 3 for a 2D position), it should
> not matter as I thought the AOA are mostly used when a position fix
> with the TDOA cannot be worked out.

No, we always use all the information available to us, because it greatly increases the accuracy and robustness of the solution. If n sensors are reporting results, we get a total of 2*n angles (one elevation, one azimuth for each sensor), and n!/(n-2)!2! TDOAs. So for n<=5, the AOA contribution is at least as big as the TDOA contribution, and n<=5 for almost all situations in reality. Of course, this isn't the whole story, because as we've been discussing the different types of measurement contribute differently to the solution in different axes - in normal sensor deployments (sensors in a plane near the roof) the vertical accuracy is almost completely due to the AOAs.

> Anyway since the PDOP is not really giving anything useful, I am
> working out HDOP and VDOP seperately ( I expect that the VDOP is the
> factor that brings high PDOP values)

Right.

> and perhaps calculate DOP using AOA for cases when the number of
> sensors is less than 3.

Using the above formulae, with n=2 you get 4 AOAs, and 1 TDOA, so the AOA contribution will dominate but you can't completely ignore the TDOA component.

Regards,
Andy