Ubisense Research Network

Sensors :: RE: Dilution of Precision for ubisense measurements

Author: Andy Ward
Subject: Re: Dilution of Precision for ubisense measurements
Posted: Fri Aug 01, 2008 9:03 am (GMT 0)
Topic Replies: 3

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

Sensors :: RE: Dilution of Precision for ubisense measurements

Author: Kavitha
Subject: Re: Dilution of Precision for ubisense measurements
Posted: Thu Jul 31, 2008 9:54 am (GMT 0)
Topic Replies: 3

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

Sensors :: RE: Dilution of Precision for ubisense measurements

Author: Andy Ward
Subject: Re: Dilution of Precision for ubisense measurements
Posted: Thu Jul 31, 2008 8:25 am (GMT 0)
Topic Replies: 3

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

Sensors :: Dilution of Precision for ubisense measurements

Author: Kavitha
Subject: Dilution of Precision for ubisense measurements
Posted: Wed Jul 30, 2008 2:59 pm (GMT 0)
Topic Replies: 3

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

General :: RE: Status code: Location engine synch error?

Author: twilson
Subject: Resolved
Posted: Mon Jun 02, 2008 8:36 pm (GMT 0)
Topic Replies: 2

Hi;
Yes, it was a timing issue and I resolved it last week after your response. I had one bad timing cable and one timing cable plugged into the wrong port. System has been calibrated and is now up and running well.

I did wonder whether this might be a different kind of indication because it was different from the basic pattern you mentioned. I think it would merit specifying the general reboot pattern in the documentation of the light codes, along with any other patterns such as the one I saw. Overall, though, I think this is a pretty good system for debugging basic problems as the sensors are coming up, especially since there may be no other way to gather information from them under certain error conditions. In fact, all the Sensor Status page told me was that its status was "unknown".

Thanks;

Tim

General :: clipping distance / peak detect threshold / standard error?

Author: NiekBouman
Subject: clipping distance / peak detect threshold / standard error?
Posted: Mon Jun 02, 2008 12:57 pm (GMT 0)
Topic Replies: 0

What means the 'clipping distance' ? I can only find in the documentation that this parameter 'should be set', but nowhere how it is defined and how one should determine the right value for it.

Secondly, what means the 'peak detect threshold' in the user tab of the sensor properties, and how do I determine a suitable value for it?

Thirdly, what is the definition of the standard error? (In what way is this related to the real accuracy of the position estimate?)

Niek Bouman
Dept. of Electrical Engineering, Mathematics and Computer Science, University of Twente, The Netherlands

General :: RE: Status code: Location engine synch error?

Author: Pete Steggles
Subject: Re: Status code: Location engine synch error?
Posted: Wed May 28, 2008 10:33 am (GMT 0)
Topic Replies: 2

twilson wrote:

Problem: One sensor, continuously blinks red/green/red/green (no pause) after downloading. The Loc Engine Config manual says this indicates, "Location engine synch. failure", whose definition is: "There may be an inconsistent boot file for the version of location engine services installed. Check your location engine services are up to date and consistent, then reboot the sensor." Occasionally one of the other slaves does this briefly, but then goes to solid green. We haven't changed or upgraded any software. (I can't swear by it, but I'm pretty sure it's not blinking orange/green/orange/green, which indicates memory test failure.)

Tim

I think you have misinterpreted one error mode for another (perfectly understandably, given our somewhat primitive means of error communication!).

This is not actually one of the boot sequence error codes as described in the Location Engine Config manual. Those codes all follow this sequence: (long red flash; off; four colour error code; off) * 3 repeats; reboot.

What you are seeing is: (red ; green) * infinite repeats and no reboot. This indicates that the sensor is not receiving a stable timing signal. Most likely the timing cable is either plugged into the wrong port or is faulty in some way. The other sensor that is flashing is getting this problem intermittently.

I will check out the documentation (because I suspect that the 'timing cable out' indicator didn't find its way into the manual) and get the manual fixed if need be.

Pete

General :: Status code: Location engine synch error?

Author: twilson
Subject: Status code: Location engine synch error?
Posted: Tue May 27, 2008 11:20 pm (GMT 0)
Topic Replies: 2

Hi. I have just finished moving 1 cell of 4 sensors from one office to another. We are running the core_server and platform_control from the same linux server as in the previous office, so I was just planning to re-enter a new wall file and redefine the area for that location cell.

Before entering the new space layout information, I booted the system to test connectivity. All 4 sensors downloaded and ran. The logs indicate all are up and running in the correct master and slave roles.

Problem: One sensor, continuously blinks red/green/red/green (no pause) after downloading. The Loc Engine Config manual says this indicates, "Location engine synch. failure", whose definition is: "There may be an inconsistent boot file for the version of location engine services installed. Check your location engine services are up to date and consistent, then reboot the sensor." Occasionally one of the other slaves does this briefly, but then goes to solid green. We haven't changed or upgraded any software. (I can't swear by it, but I'm pretty sure it's not blinking orange/green/orange/green, which indicates memory test failure.)

Additional information:
- After being unable to clear this problem, I entered the new wall file and the new sensor positions and orientations. No difference.
- I compared logs amongst slaves during startup. The files referenced/downloaded in the logs are identical.
- I have not attempted recalibration because I'm not getting any data from this one sensor on the incident power plot, so I didn't want to use that data to set the thresholds.
- When I run the incident power plot, I see cumulative averages (or whatever's displayed below the Cumulative chart) of: 2152, 4705, 392, and 0 from the problem sensor.
- Under "Sensor Status", this one's status is "unknown". Others are "running".

Here's what I've tried:
- Reinstall the Platform using the ServiceInstaller
- Reinstall the Location Engine using the Service Installer
- After reinstalling the services: Undeploy services, stop and restart the ubisense_core_server and ubisense_platform_control linux services, redeploy services
- Reconnect the sensors on various Ethernet switch ports
- Reboot in different order
- Change the problem sensor to "available", then add it back to the cell.

I'm out of ideas except for the possibility that this sensor is broken. The only diagnostic I can think to perform is to try to capture packets and compare between the different sensors.

Thanks for your help. ---Tim

General :: RE: problems about the "protocol.c"

Author: Rupert Curwen
Posted: Thu May 22, 2008 6:43 am (GMT 0)
Topic Replies: 9

OK, the 1.2.8 libraries you are using are built for VS2003. I know there is a build for VS2005 - I'll try to find it. I'm at a customer this week.

If you didn't hear anything from support you might have some sort of spam filter blocking our emails. Or perhaps your email has been filtered out at our end in which case it would be picked up only every few days. It annoys me that one cannot run a public email address without any spam filtering any more, but that's the way things are.

Rupert.
_________________
Rupert Curwen
Founder and Software Director
Ubisense Limited

General :: RE: problems about the "protocol.c"

Author: kairen6645
Posted: Thu May 22, 2008 12:55 am (GMT 0)
Topic Replies: 9

Hello Rupert Curwen,

I have already asked the support for help,but I don't receive any message from them.

I use vs2005

General :: RE: problems about the "protocol.c"

Author: Rupert Curwen
Posted: Wed May 21, 2008 7:29 pm (GMT 0)
Topic Replies: 9

Probably a binary incompatibility between the version of the C++ compiler you are using and the version the libraries were compiled with. Again, which OS are you using, and which compiler version?
_________________
Rupert Curwen
Founder and Software Director
Ubisense Limited

General :: RE: Version 2 Software Compatibility Matrix Request

Author: Anthony
Posted: Tue May 20, 2008 1:19 pm (GMT 0)
Topic Replies: 10

Hello,

Have you the same thing in c# ?

Anthony.

General :: RE: problems about the "protocol.c"

Author: kairen6645
Posted: Tue May 20, 2008 8:55 am (GMT 0)
Topic Replies: 9

Well,I have write some applications using c++ API under v1.0,but your v2.0 don't provide C++ API .

I want to run my programme without changing to use c#,so I test to see wether the protocol work in v1.0. But the result is that it doedn't work.

By the way ,I have another program:the code below can't run ,will you pls tell me why? An exception occur in the red line, after run "Set<String> cells = client.get_all_cells(); ",the Set<String> is still empty.

#include "UClientAPI/location_client.h"
using namespace UClientAPI;

class MyLocationClient : public LocationClient
{
public:
MyLocationClient()
{
}
/// Called when an object enters the loaded cells.
virtual void on_insert(const Object& object, const Location&
location)
{
cout << "Insert " << object.to_string() << " at " << location <<
endl;
}

/// Called when an object moves within the loaded cells.
virtual void on_update(const Object& object,
const Location& location)
{
cout << "Update " << object.to_string() << " at " << location <<
endl;
}

/// Called when an object leaves the loaded cells.
virtual void on_remove(const Object& object,
const Location& location)
{
cout << "Remove " << object.to_string() << " at " << location <<
endl;
}

/// Called when a set of object inserts, moves or removes is commited.
virtual void on_commit()
{
cout << "Commit" << endl;
}
/// Called when events may have been missed. Objects is the set
/// of objects that may have changed.
virtual void on_establish(const Set<Object>& objects)
{
cout << "Establish with " << objects.size() << " objects" <<
endl;
for (Set<Object>::const_iterator i = objects.begin();
i != objects.end();
++i)
{
cout << " " << (*i).to_string() << endl;
}
}

};

bool test_location()
{
MyLocationClient client;
cout << "Available cells:" << endl;
String cell_name;
{
Set<String> cells = client.get_all_cells();
for (Set<String>::const_iterator i = cells.begin();
i != cells.end();
++i)
{
cout << " " << *i << endl;
}
if (cells.empty())
{
cout << "No available cells" << endl;
return true;
}
cell_name = *(cells.begin());
}
cout << "Loading cell " << cell_name << endl;

if (!client.load_cell(cell_name))
{
cout << "Failed" << endl;
return false;
}

cout << "Loading cells intersecting -10,-10,-10 to 10,10,10" <<endl;

Position pmin(-10.0,-10.0,-10.0);
Position pmax(10.0,10.0,10.0);
Set<String> loaded_cells =
client.load_cells_intersecting(pmin,pmax);
if (loaded_cells.empty())
{
cout << "No cells loaded" << endl;
return false;
}
cout << "Cells loaded:" << endl;
for (Set<String>::const_iterator i = loaded_cells.begin();
i != loaded_cells.end();
++i)
{
cout << " " << *i << endl;
}
cout << "Gettting all object locations in loaded cells" << endl;
Map<Object, Location> locations;
client.get_all_locations(locations);
if (locations.empty())
{
cout << "No located objects" << endl;
return false;
}
cout << "Unloading all cells" << endl;
client.unload_all_cells();
return true;

}

int main()
{
test_location();
}

Sensors :: RE: Eternal Sensor Reboot...

Author: Rupert Curwen
Posted: Tue May 20, 2008 8:24 am (GMT 0)
Topic Replies: 5

That just looks like you haven't got your timing cables plugged in correctly. Make sure the timing cable goes into the port on the slave marked with a clock. Make sure the cell master is set as "timing source".

Rupert.
_________________
Rupert Curwen
Founder and Software Director
Ubisense Limited

General :: RE: problems about the "protocol.c"

Author: Rupert Curwen
Posted: Tue May 20, 2008 8:20 am (GMT 0)
Topic Replies: 9

Sorry to be so slow responding.

Unfortunately the protocol.c example only applies to the 2.0 system, where Location Engine was separated out as a product.

What are you trying to achieve, and on which operating system and compiler?

Rupert
_________________
Rupert Curwen
Founder and Software Director
Ubisense Limited