How to increase location update rate and reduce latency of RTLS?

Quick and dirty

0) Set Location update rate to 16+Hz in the Dashboard. The system will reach the update rate ceiling based on other limitations

 

1) Disable Realtime Player to reduce an additional latency due it to zero. Set Window of averaging = 0 and Distance filter = 0. It won’t increase the update rate, but will reduce latency

 

2) Reduce the number of mobile beacons in NIA, if feasible. The update rate will improve proportionally.

Reduce the number of mobile beacons in MF NIA to less than 5, less than 10, etc. Update rate will improve proportionally to int(N/5)

 

3) Define service zones. If you don’t, the system uses the default services zones of 30m and the update rate may be not optimal because of that. If you reduce from 30m to 10m, for example, your update rate may raise up to 3x, if it was limited by the size of the submap, which is often the case

 

4) Change from default 153kbps radio profile to 500kbps. If it was radio limited, you may see an increase. Usually, it less than that with service zones or zero at all, if the system wasn’t radio limited. But becomes very important in swarm robotics and IA

5) Choose between location update rate on the modem vs. location update on the mobile beacon. If you update the location of every mobile beacon on the modem every time, the location update per mobile beacon will be lower due higher radio traffic

Detailed explanations

There are several key parameters in any realtime locating system (RTLS) or indoor positioning system (IPS) or indoor navigation system (INS), which are just different names for the same thing. Among the key parameters:

 

– Cost (HW + SW + deployment + running, etc.)

– Accuracy/precision

– Location update rate and latency

– The number of mobile objects tracked

 

Obviously, there many more and you can learn about them in detail: https://www.youtube.com/watch?v=zg3oW_U_jdY&t=3949s. Let’s discuss deeper the two of them:

 

– Location update rate

– Latency

RTLS location update rate

Notice that though location update rate and latency are usually linked, they really not the same thing. You may have a high update rate and high latency at the same time, for example.

Location update rate

Location update rate – how many times per second the location has been measured.
 
For some customers “fast” means once per minute, for example, for static assets tracking – palettes, etc. For some other tasks even 100Hz update rate is barely fast enough – VR/AR and similar.
 
We support up to 30-40 Hz for very small submaps of 2-3m. Typical update rate with default settings with average-sized submap of 10-15m – 8Hz. For larger maps of 30m and default settings – 6Hz or so.
 
If you don’t specify the service zone, the submap assumes the largest submap and you get 6Hz or so.
Notice that for the Paired Beacons configurations we have both location and direction. While location is measured with a typical update rate of the ultrasound system – 8Hz or so – the direction is measured based on sensor fusion with IMU. The sensor fusion gives 100Hz update rate for direction and ~10ms latency for it.

Latency

Latency – a delay between the moment the location has been measured and the moment we know the measured coordinates.
 
Latency is usually a more complex task, then update rate. For example, the Realtime Player is a relatively simple method, but it increases the update rate x10..x100 times. Whereas to do the same with latency, an architecture or even the underlying positioning technology could have to be changed.
 
There is a clear trade-off between latency and accuracy of tracking. By applying more filtering or more averaging it is possible to achieve better quality of tracking, but latency will suffer. Thus, each case has to choose a balance between accuracy/quality and latency.

Further development

If the existing 8-16Hz of location update rate and 100Hz for direction for typical configurations is not enough, what are they options for further development?
 
– Send us a request to info@marvelmind.com. Maybe, you don’t really need the high update rate or low latency as you think you are. Maybe, there is another solution
 
For swarm drones, MF NIA is the best option now. But for more than 10 drones the update rate of <4Hz may be already not good enough. You may need to change to IA instead of MF NIA (see more: https://marvelmind.com/pics/architectures_comparison.pdf). Since mobile beacons in IA receive ultrasound, you could have to do the following:
a) reduce the size of the submap and increase signal/ration
b) install special shields/screens protecting microphones from the noise of drone’s own noise can help
c) limit the relative locations of the drones against each other. For example, they can fly side by side but not above each other – at least, not too close, in order to keep a sufficient signal/noise ratio
 
– Sooner or later we will complete Ultrasound+IMU sensor fusion. With ultrasound location update rate more than 2-4Hz, the sensor fusion with IMU will kick in and will provide 100Hz update rate and 10ms latency for location. It is similar to what we already have for direction, but for location. The key step in this development is 10ms, because with the help of the Realtime Player it is already possible to have 100Hz location update rate, but with 1-2sec latency – not with 10ms latency. So small latency requires sensor fusion with IMU, which is very complex for general case. Send us an email to info@marvelmind.com, because the task may be less complex for your case with special constrains.

If anything is unclear, contact us via info@marvelmind.com