I have several DWM1001-DEV modules I’m working with. According to the documentation these modules should have an accuracy of less than 10 cm (typical).
Does Decawave plan on a producing a module with even better accuracy?
Kent
Hi Kent,
We are currently working on new modules with different characteristics than the DWM1001C but the accuracy should remain similar.
What accuracy are you trying to reach ?
Thanks
Yves
1 Like
I would love to have the same accuracy as DGPS which is about 2 cm.
A simple method is to perform the ranging function multiple times and average/filter the result.
For a factor of 5 improvement, you need 25 measurements to be averaged. Position noise improves as 1/n^2.
This will improve PRECISION, reducing the measurement noise. It may not change ACCURACY all that much since there are systemic factors that affect accuracy such as antenna delay variation versus direction, signal strength sensitivity, and environmental factors.
In our experience using our code, the typical standard deviation in range measurements using TWR is about 2 cm for a properly built DW1000 based system. That means +/- 2 cm about 68% of the time (assuming a Gaussian noise distribution, which seems reasonable). Note that this is PRECISION. There are many ways to get worse performance, some of them not so obvious, so this does take care to achieve these results.
If you have a system with 2 cm PRECISION, but worse ACCURACY, you can develop an error correction function to map the precise measured location to the actual accurate location. This works as long as every measured position maps to one and only one actual position, which is generally true. Does require effort to calibrate such a system.
Averaging the result causes increased air time usage, lower capacity, and less battery life, so not every application can make it work.
Another way to improve accuracy is increased anchor count in a general location system. We have built systems with large numbers of anchors which achieve very high precision and retain high capacity. An example is an arena where we mounted 54 anchors in the ceiling, a high anchor density. This could support as many as 3000 locates per second while also yielding position standard deviations in the few millimeters per single tag beacon. This is using our proprietary location engine that operates in a TDoA kind of way.
It should be noted that RTK GPS achieving 2 cm is ideal, it usually doesn’t do that unless you also average a number of readings. It can also have systemic errors that create a difference from measured to actual. Typically location accuracy is quoted 50% CEP (50% of the points fall in a circle of a given radius) so half your data will be outside that radius. This is usually quoted with a minimum number of SVs visible, and with good DOP. Like with UWB, RTK GPS can be affected by the antenna quite a lot.
A well design UWB system can out perform RTK GPS, particularly with high dynamic tags and when you need > 10 Hz location rates, but does cost more to setup due to anchor count.
Mike Ciholas, President, Ciholas, Inc
3700 Bell Road, Newburgh, IN 47630 USA
mikec@ciholas.com
+1 812 962 9408
1 Like
I’m not sure if I’d agree that UWB can out perform RTK for high dynamics. It can certainly come close but for some applications I think RTK still has the edge.
RTK can give me 100 Hz data with a CEP of 2 cm. A TDoA system could potentially give me 1000 Hz data for a single tag which I could then average down and approach the same accuracy at 100 Hz. But you can’t run many of those at the same time.
The big issue is that if you are in a highly dynamic environment velocity probably matters to you. GNSS measures velocity independently of position with relatively low noise, UWB has to fall back to position deltas which is noisier and is going to give you a latency on the heading.
That said, here’s a plot from a recent test, blue is 100 Hz RTK position, orange is 100 Hz UWB position, both sets are 20 seconds of data. The scale is meters. The antennas are offset so the relative positions between the two data sets are not correct, I’ve simply translated both data sets so the first position is 0,0, this is purely to give an impression of position spread. The UWB positions have a couple of cm variation, the RTK is generally well under 1 cm.
Both systems also tracked fine through a 1 g deceleration from 70 km/h right before this but that data is a little hard to show in a simple plot.
1 Like
I can’t speak to other algorithms out there, but our internally developed location algorithm does quite well. For example, with 12 ceiling mounted anchors in a room that is about 10 x 20 meters, the standard deviation of location (in XY plane) is under 1 cm for a tag in the center of the room. That means 68% of the locations are within 1 cm of the average. In the basketball arena with 54 anchors, a high density, we had std dev in the 2 to 3 mm range. These are not averaged results, this is from single beacon hits. The system can support 3000+ locates per second, so if you have capacity to average, your results get even better.
I’ve not seen RTK GPS perform that well even under ideal circumstances, but we work with lower cost RTK modules (like uBlox NEO-M8P) and fairly simple antennas, and not the super high end stuff. Obviously, an indoor site like an arena can’t use RTK GPS at all, and even many outdoor sites have trouble with GPS due to sky occlusion, vegetation, and other factors, so UWB wins those easily.
GPS does have an advantage in lesser infrastructure to setup (well, it did cost $billions to put up the sats, but not directly to the site) and thus if you have the right conditions, it is a very good choice. GPS also allows unlimited number of receivers, but UWB can be configured that way, too, by using “nav mode” (anchors transmit time codes, tag receives only and locates) versus the more traditional “track mode” (tag beacons, anchors receive and locate). We’ve built systems that do either, and sometimes both at the same time (like the digital guide system at the Museum of the Bible).
Further, we are working on integrating inertial sensors into the solution, what we call inertial augmentation. With that, the location noise is microscopic. The combination of UWB and inertial yields an excellent system since the weaknesses of each system is countered by the strengths of the other. The inertial system smooths out all the short term location noise, and the UWB system corrects for the long term drift of the inertial system.
Maybe, but in our tracking of athletes, the velocity data has been pretty good.
Inertial augmentation works very well since it provides a very clean velocity and acceleration data set. Indeed, acceleration is the basic sensed parameter and RTK GPS can only provide that by differencing velocity.
Nice data, but it seems like there are way more blue dots than orange, is that true? Or do the orange dots get quantized on top of each other a lot so don’t appear individually?
Mike Ciholas, President, Ciholas, Inc
3700 Bell Road, Newburgh, IN 47630 USA
mikec@ciholas.com
+1 812 962 9408
it seems like there are way more blue dots than orange, is that true? Or do the orange dots get quantized on top of each other a lot so don’t appear individually?
There is some quantization going on. In theory every position is independent but in practice due to some of the filtering effects and also rounding (the system works in meters internally, outputs in lat/long and then it’s converted back to meters for this plot) we end up getting some duplicate points when static.
This was with 8 anchors with no wires connecting them, all they need is power. We need to cover up to 1 km long areas so high tag densities or wired clock distribution systems aren’t a practical solution.
The other requirement that’s probably a little different from your system is that the position needs to be known at the tag with a low and constant latency.
The uBlox F9 actually gives very good RTK for a good price. In terms of raw position accuracy it’s almost as good as a receivers costing $10k. It just suffers in terms of output latency and update rate.
I can’t speak to other algorithms out there, but our internally developed location algorithm does quite well. For example, with 12 ceiling mounted anchors in a room that is about 10 x 20 meters, the standard deviation of location (in XY plane) is under 1 cm for a tag in the center of the room. That means 68% of the locations are within 1 cm of the average. In the basketball arena with 54 anchors, a high density, we had std dev in the 2 to 3 mm range. These are not averaged results, this is from single beacon hits. The system can support 3000+ locates per second, so if you have capacity to average, your results get even better.
Which ranging protocol do you use in order to get the distance measurements before you apply your localization algorithm ?
I believe this is using a TDoA approach.
If you want a high throughput system with cheap low cost tags this is the most efficient way to do it.
I remember testing a UWB system around 15 years ago which could handle a couple of thousand locations per second from tags that were 1" cubes, cost only a few dollars to make and would run for years off a watch battery at a 1 Hz update rate. It wasn’t quire that accurate but it did a very good job.
We’ve developed our own set of software and location algorithms. They broadly fall into two categories multitime and multirange.
In multitime, the raw data is timestamps of arrival of tag beacons at multiple anchors. Tags beacon only once to be located. Anchors exchange packets on a regular basis to enable modeling of the anchors local clocks to the 10s of picoseconds level using a time sync mesh algorithm we developed. This basically provides universal accurate time, what we call “network time”, at every node. Each tag beacon arrives, gets time stamped in “decawave time” by the chip, then we mathematically convert that to network time. The collection of time of arrival data is then subjected to a location engine which finds the best fit for the tag location. Multitime operates somewhat like TDoA in that you only need one tag hit to locate, but it is really more of a time of arrival ToA algorithm.
Multitime is very high capacity, 3000+ locates per second in a fully scheduled network, and very low tag battery usage (only one transmit to locate, no requirement for tag to have precise clocks). One nice advantage to multitime is that antenna delay doesn’t affect the accuracy, so any variance or change in antenna delay doesn’t affect the outcome. Multitime does very well within the lateral bounds of the anchor array, but gets increasingly less accurate as you exceed that.
In multirange, the raw data is ranges computed from tag to anchors. The computation of range is done using the standard two way range, but we’ve tweaked it up a bit to reduce air time (overlap some packets) and improve its accuracy slightly. Each tag locate requires 2 tag transmits and N tag receptions for N anchors, so it take more air time and uses much more tag battery. The more air time reduces capacity to around 500 locates per second in a scheduled network, but we have methods that may increase that to around 1000 locate sper second with some complex scheduling. The range data is then fitted to the best tag location in our location engine.
The benefits of multirange are that you can get similar location accuracy from about half the anchors in view as multitime, and it works far better beyond the lateral bounds of the anchor array than multitime. Another benefit is that it does not require synchronized anchors which means anchors can be put in areas where they don’t hear other anchors and still function.
Which solution is the right one depends on the various parameters involved. Our business is providing professional and industrial grade RTLS systems customized to fit the client’s application, so we analyze what the client needs and fit the right algorithm to the application. Tracking athletes, say the basketball arena mentioned before, requires multitime for the higher speed and capacity. Tracking equipment in a hospital is better done by multirange to reduce anchor count and because beacon rate is very slow.
Mike Ciholas, President, Ciholas, Inc
3700 Bell Road, Newburgh, IN 47630 USA
mikec@ciholas.com
+1 812 962 9408