While the PANS 2 firmware is excellent for quick deployment, I am a little bit unsatisfied with the maximum update rate of 10Hz - especially for low-latency RTLS applications. At the same time I do understand the compromises that the Decawave developers made so that users can have additional functionality, such as the bridge nodes for MQTT topics.
My problem is that I need at least 20Hz for mobile robot location tracking (in real-time). It seems to me that it would be quite easy to modify the superframe, in the PANS 2 firmware, to take out some of the slots that I don’t need. But of course, the firmware souce code is not available at this time (and maybe never will be? )
So my question is, what would be the simplest way to achieve this increased update rate to 20Hz, given that we don’t have access to the PANS 2 soruce code?
I woud have liked the same, but with Tags able to listen to messsages from anchor. I do understand the architechture of PANS but to my point of view, the tags could have some data received from the anchors as extra data with the normal return packet.
An example application requiring low latency would be a location system for a drone swarm, say to choreograph a drone performance. If flown indoors, they lack GPS, so you need a replacement system that can deliver good positions fast enough for the drone control system to react properly. Too slow and the drones become unstable in position.
We’ve built such a system for a client. The tag on the drone beacons, received by an anchor array, sent to a server, position computed, answers sent back to an anchor, then sent to the tag via UWB, then serially sent to the drone to emulate a GPS signal. The entire process is less than 50 ms from drone tag beacon to the drone having location.
The easiest is buying a system that can do it out of the box. Our CUWB system can support 3000+ locates per second on a single network. We have operated tags as fast as 240 Hz. 20 Hz is obviously no problem at all, we could support 150+ tags operating at 20 Hz each.
There are a LOT of advantages of going faster. If you need 20 Hz output data, but the tag runs at 100 Hz, you get to average 5 samples which reduces the position noise quite a lot. At 3000 locates per second, that’s 30 tags at 100 Hz each.
Our tags also provide 9 axis inertial and orientation data, something your robots may already have, but perhaps useful none the less.
We also do a lot of work in mobile robots, so I’d be interested in your work and what you are doing which might help me better advise on what you can do.
Mike Ciholas, President, Ciholas, Inc
3700 Bell Road, Newburgh, IN 47630 USA mikec@ciholas.com
+1 812 962 9408
It is possible to implement a positioning system in which the base stations transmit a positioning signal and the TAG calculates its own position, like GPS. Advanteges of this system; virtually no limit for number of TAGs, no positioning area limit, scalability by amount of BS, hard real time and accurate position information in TAGs. Total latency is only 15 - 20ms. This RTLS method enables; low cost base stations and TAGs, no need for centralized location engine system, full embedded stand-alone system is possible, enables truly wireless base station network and only one radio technology needed: UWB.
BR,
Jukka Kämäräinen
IIwari Tracking Solutions Oy
Finland
Yes, we call this “nav mode” where it operates like GPS, as opposed to “track mode” which is the more common server side RTLS system.
The anchors broadcast time coded messages which tags receive and they process into a location. Tags do not have to transmit, which means they don’t consume air time and you can have an unlimited number of them.
An example use case was a museum which has 600 anchors and 3000 tracked digital guides tracked over 43,000 m^2. The anchor network runs on a 10 Hz update rate providing nav mode timing signals to the guides which then compute their location locally. This provides ample capacity even in the case of a large group congregating in one area.
To enable certain other features (such as visitor analytics, related party tracking, etc), the system also operates in track mode at 1 Hz, so a hybrid of both modes which can be used at the same time.
I’d be curious to hear how you imagine such a system to work.
In order for nav mode to work, anchors have to coordinate and synchronize with each other very, very precisely, on the order of tens of picoseconds or better. This requires quite intense algorithms and clock modeling at each node relative to the others in the anchor array. If the time being broadcast by an anchor can’t be related to another anchor’s time, then location can’t be computed in nav mode.
While it is theoretically possible to build such a system without a central resource, that is significantly harder than having a central resource. Even GPS has a central resource, the ground infrastructure that manages the satellite constellation.
Our system has a central resource which provides the network management and central time modeling of the anchors. This functionality could be distributed to the anchors themselves but with significantly increased complexity, especially as the system grows in size beyond one UWB radio range diameter.
Mike Ciholas, President, Ciholas, Inc
3700 Bell Road, Newburgh, IN 47630 USA mikec@ciholas.com
+1 812 962 9408
Our solution has multiple cells which are coarsely synchronized to operate in single frequency. One cell consists of 9 anchors, 1 master base station (MBS) and 8 base station (BS). Precise synchronization (±100ps) between MBS and BS is executed wirelessly. Each positioned TAG calculates its own synchronization for all TDOA values. This publication “Robot Self-Localization in Ultra-Wideband Large Scale Multi-Node Setups” presents quite similar positioning method. (https://ieeexplore.ieee.org/document/8250062). In our system, the clock offset between MBS and BS does not cause any error in the TDOA calculation.The clock error between MBS and TAG is corrected during each TDOA calculation. This method implements clock error compensation more accurately than in the publication cited above.
Our TAG has Cortex M4 MCU, which implements the calculation. Total calculation time (synchronization, TDOA values and position (2D or 3D)) is about 10 - 15ms. Our TDOA method is not quite traditional, it has developed during many years of research.
The coarse cell synchronization (operation timeslot of cell) is done using Ethernet cable connected to each MBS and it is possible to implement this timeslot sharing also wirelessly.
100 Hz would be ideal with a averaging every 5 samples - would still be double the update rate we’re getting!
The university project we are working on is locating a single mobile robot in 3D space. At the moment the mobile robot that is being localised is using dead reckoning from its wheel encoders. In this situation a 2D position is enough for this task, but we want the option of localisation in both 2D and 3D space.
Our initial testing has shown that Z-accuracy is not very precise at all. From what I research I have read so far, this seems to be a result of GDOP (anchor positioning geometry).
We are also planning on using the BNO055 9 axis IMU to find our orientation.
Since we are only two people completing this project, the custom software for a faster update rate might have to be completed by the next students who pick up this project
)