I currently have working 4 DW1000s with each connected to an ESP32, 3 anchors and 1 tag. The all work well to discover the location of the tag using a main gateway anchor.
I have another 4 DW1000 that I would like to add to the system. So I was wondering if anyone has figured out a way to use the following configuration.
On my rectangular robot I would like to place 2 DW1000 tags (both with their own ID sent in message), one on each diametric corner - two in total.
I then would have 6 DW1000 configured as anchors all sending requests to ping the tags and find where both tags are. The reason for so many anchors is to make sure the robot has coverage in each room, the anchors dont seem capable of going through walls very well. So as the robot moves around, the anchors come into and out of range, meaning at any one time there may be none or more anchors within range. For when there are less than 3, just for now at least, I can just ignore the location acquisition and switch to image recognition etc. for location. Or is there a way to get the location of a tag with only 2 anchors ?
The idea is that all anchors ping the 2 tags on the robot, and that a central system (without any DW1000), receives the distances between the anchors to the 2 tags, and the distance of each tag is sent to the robot. A main location processor will probably be a MCU with an FPU (floating point), on the robot as well eventually.
Some questions
Do the DW1000s handle traffic collisions etc. Or will sending all these messages unsynchronized cause any corruption/errors ? If I do have to synchronize ie send one message at a time from each anchor, is there a good way to do this ?
If I get data from more than 3 anchors what’s the best (most accurate/least errors), way to process the location if I only need the data from 3 ? Do I pick the 3 nearest anchors and ignore the rest, or can I use data from more than 3 anchors to get a more accurate location ?
If anyone has created/used a system like this can they discuss it, and perhaps tell of any pitfalls I might encounter.
Yes you do need to worry about collisions. Some form of TDMA is generally your best solution.
A least squares optimisation works well, it will degrade gracefully from as many anchors as you can give it down to 3.
If you constrain the solution to 2D only then it may be possible to run down to 2 anchors. For least squares you use the previous solution as a starting point so as long as you 1) start with 3 or more anchors and 2) when using 2 don’t pass close to being in line with the two anchors you should be able to maintain a solution. The accuracy will be worse but it’ll be better than nothing.
Obviously my preferred solution would be that you buy our system (message me if that’s an option and I’ll send you details) but we do charge a fair amount for it. We give 100Hz position and velocity output with inertial integration. Up to 5 tags are supported at a time.
We handle the time sharing by having the tag run the ranging process not the anchors, that reduces the number of devices that need to worry about the time. The location is then calculated on the tag which eliminates the need for a separate computer and data link back to the mobile device. This method also gives us a low and more deterministic latency in the position output.
When using multiple tags they are each assigned a time window, they listen in on the other tags transmissions to work out where the system is in its cycle and synchronise themselves that way. This eliminates the need for a master time source.
We use up to 12 anchors at a time to give a more accurate position, which 12 out of up to 200 are used is based on the current tag location. Passing through a doorway you get a slight wobble in position as it switches anchors from one room to the other but it’s normally only a few cm which the inertial integration takes care of.
Basic tips:
Yes, time synchronise things.
Use as many anchors as you can but have a way of knowing which ones to use at any given time so you don’t try to use ones that are obscured.
Set up accuracy and geometry is critical to good operation. All the anchors on one side of the tag or having their locations wrong will ruin your accuracy.
If you are traveling at anything above a slow walking speed then watch out for how old your measurements are. If each range is measured at a different time and you’re moving then you position will be wrong. How wrong will depend on speed and your measurement speed.
You want to measure as fast as possible, a lot of the small errors average out, the occasional large error is obvious if you have enough data. If you can run an averaging system with outlier detection & rejection on each anchors range then your final position will be far lower noise. Of course simple averaging will cause other issues if you’re moving at any significant speed but that’s another issue which I can’t share our solution to.
Hi, AndyA ,
I would like to ask if you have successfully built a multi-anchor multi-tag positioning system. If yes, could you please share which board you used? I also want to build a UWB indoor positioning system that covers a large area, such as an entire floor. However, I’m not sure about the CPU computing power required for multi-tag multi-anchor scenarios. For example, how many MHz of CPU performance is needed to locate a single tag? How much CPU performance is required to locate 100 tags?
Thanks a lot!
Yes, I’ve built a system. We used DWM1000’s for initial prototyping but then moved to a fully custom solution.
The largest area we’ve covered is ~700m x 40m. In theory the system would scale to around 3x that.
It’s a completely distributed DS-TWR based system, there is no central server, each tag calculates its own location. Anchors require only power and no other connections.
Each tag will use up to 12 anchors at a time, the default is to pick the closest although there is some flexibility to change that in the setup if there are known obstructions in some areas.
Tag and Anchor both use the same basic radio hardware, on the radio side the two are basically interchangeable, the anchors can also measure ranges. The only difference is that tags automatically initiate ranges at a set rate while anchors only do it when commanded to. The radio processor is a 120MHz Arm M4 with single precision FPU although early prototypes used a 100MHz M3 without any FPU and managed just fine.
We max out at 2400 individual range measurements per second, that’s radio air time limited rather than CPU.
Position calculation is then done on a second processor in the tag. This is a 400MHz M7 with DP-FPU. UWB position calculation spends more time trying to clean up the UWB ranges and remove noise from them than it does actually calculating the location. If things were moving slowly a simple average would do this far simpler but we track high speed and rapidly accelerating objects so averaging wouldn’t work. In addition to our 12 anchor UWB solution we are also running an IMU and a kalman filter to combine the two. We calculate positions 100 Hz.
Both processors in the system are fairly heavily loaded but not enough to make me worry.
For debug/troubleshooting reasons we have re-implemented the position calculation on a PC, without worrying about optimisation we can easily run at 20x the speed on any available machine. Probably a lot faster than that, I’ve never really tested just how much faster it is, it’s fast enough that it’s not an issue.
The only speed issues I’ve ever had were during initial prototyping when I was using python to quickly try different positioning approaches. Even pre-compiling and running multi-threaded that is was painfully slow. The same algorithm in C++ ran 5x faster on an embedded processor than the python managed on a desktop PC.
hi
rhank you very much for your reply. Lately, I’ve been studying algorithms and I have a question. Why do you set it up the tag to calculate its own position instead of calculating the base station the distance to each tag, and then calculate the position on a computer? This way, the tags could be made more lightweight. Moreover, I’ve seen many examples online where the code is written this way.
My application was for something to replace GPS indoors and so a GPS like approach was more appropriate.
The system has some very hard real time requirements. It is used for automotive guidance at speeds of 60-100km/h. The moving object needs to know it’s location (and velocity) within a certain amount of time, failing to meet these timings would be unacceptable. Windows doesn’t do real time and deterministic timing. Add to that things like wifi latencies and dropouts and the results simply wouldn’t be acceptable. By doing things on the tag in an interrupt driven system with no OS getting in the way we can get far more consistent timing results.
Finally if the anchors are measuring ranges and passing them to some central computer then that is implying a data link to the anchors. So you may simplify the tag (of which we only have a few) but you’ve made the anchor (of which we have more) more complex and increased its infrastructure requirements. Our anchors require power (they can run off a phone sized battery for a day) and nothing else.
To give you an example, we had a demo in a multistory parking structure. Two semi-technical support / sales people with limited experience of the system got everything up and running in half a day. A competitor with a more conventional system was also demoing. They had a team of 6 people, it took them a full day to set up and they had to run a few km worth of cables.
I’m not saying our approach is the best one, for a lot of applications it isn’t and doesn’t make sense. But in some situations it has big advantages.
If anyone claims that their product is the best solution for all possible applications then they are lying. Or delusional. Or an idiot. The one thing you can be sure is that they aren’t correct.
It’s a commercial system so I can’t go into too much detail on how we solved all the issues but I can certainly help.
If you have more than 1 tag then you need some form of TDMA to make sure they each take turns.
The way we do it is that each tag and each anchor has a unique ID assigned to it. Part of the system setup is telling each tag how many other tags there are in the system and how long each tag gets before it’s someone else’s turn to measure ranges.
When starting a range measurement the tag includes both it’s ID and how long it has left.
So in effect the messages start with “I’m tag 2 of 4. This is the start of my range measurement 6 of 16.”
(We measure each anchor at least twice if not more on each tags turn and apply some averaging/smoothing before calculating a position, this gives a better result.)
For a short period after a tag first starts up or after it’s finished it’s fixed number of range measurements it goes into a listen mode. Since each range measurement takes a fixed amount of time as soon as a tag hears any other tags range start it is able to work out how long until it’s next turn to broadcast.
As long as all the tags follow the same rules time gets shared equally between them with no significant overhead and without the need for any central coordination server. The down side is a lack of flexibility, how many tags is fixed, you can run with less but unless you reconfigure the system you’ll end up with empty air time that no one is using.
I don’t think there are rules against direct linking to a 3rd party product here so here are some links.
The main version is targeted for automotive use but no reason why it wouldn’t work for other applications.
There is also a version targeted for camera tracking. That is fundamentally the same UWB but a different form factor for the tag (or rover as we call it) with a better (and far more expensive) inertial sensor, and some extra integration on the output side to sync it with the frame rate and include things like focus settings in the output message. Generally this version is rented out for the required time period rather than sold.
The contact us links on both of those pages end up in the same inbox but will then get passed on to difference people based on the product line and possibly geographic region.