Our team has been experimenting with TDoA. What I observed is consistent with this paper http://mikehamer.info/assets/papers/Led ... 202015.pdf. For the square trajectory, we have 0.18m RMSE (root mean square error). Z-direction is better than that in paper, 30cm offset at maximum. However, we think it is possible to improve further. Here are some directions we are currently looking into:
1. To improve the synchronization of all anchors, is it possible to connect all DWB 1000 to an external clock (a better one)? If so, do you have any suggestions on how we should start off? For example, what modifications of PCB and firmware we should expect?
2. Currently, we have to take off from a stand of 20cm since there is a large offset when crazyflie is on the ground. The offset is about 1.5m ~ 2.2m throughout x-y plane. Have you ever met this problem? I'm wondering if this is due to the configuration of the anchors such that the system is seeing multiple solutions at the same time?
3. The current anchors are sending signals every 1ms (100Hz for one estimation cycle). Could we increase this sampling rate to 500Hz? We think this might help clock synchronization and hence estimation accuracy.
4. Anchors are using channel 2 to send packets to crazyflie. We're assuming this is what makes the anchors sending packets sequentially. Could we use different channel for different anchors? Do you see any difficulties in this communication scheme? For example, what we have in mind right now is that crayflie can't decode signals with at channels easily.
Thank you in advance for your help,
Tracy
TDoA large Offset
Re: TDoA large Offset
Hi,
Sounds interesting! What firmware are you using, did you re-write your own TDoA firmware? I will assume you are using the loco nodes and firmware in the answers.
1. Unfortunately, as far as I have read, the external synchronization pin is not available on the DWM1000 module. It is only available on the DW1000 chip which means that you would need to design your own board or get some from Decawave to access this pin (I think some of the decawave boards have a synchronization input on the board). My understanding though is that external synchronization is a subject of a complete new class of problems (in handling delay and jitter in the coax for example), so it is not a silver bullet.
2. From my experience this could have at least two cause
- Strong reflection on the floor makes the timing measurement very inaccurate
- You are outside the convex hull of the anchor when starting from the ground
If it is the former, maybe fixing Z=0 when the motors are OFF could improve the situation (an earlier version of our EKF was doing exactly that).
3. Our TDoA firmware is sending a packet every 2ms. Going faster will require some optimisation on the stm32 side (like not calculating the received power for each packet). If I follow your calculation you would like to send one packet every 0.2ms? If so it will be challenging since the packets lenght are actually of a bit more than 128us, it does not let much margin. Maybe by enabling the double buffering mode of the DW1000 chip but even with that there might not be much time to process the packets in the stm32f0.
4. Anchors could send packet on different channels and preamble, this will give us a lot of virtual channel to play with and this can be very advantageous in the case of TWR with TDMA (with 6 anchors it would multiply by 6 the max number of Crazyflie flying at the same time in the system). Though for TDoA I have a hard time finding a use-case: to synchronize the anchors they need to communicate together, currently this is done by having them all on the same channel. There might be a way to make a clever synchronization scheme that would allow the anchors to communicate fast on multiple channel, but the Crazyflie still need to be able to listen to the signals and it can do so on 1 channel at a time anyway. The main use case I see for multiple frequency in TDoA is with making bigger system where there could be multiple overlapping TDoA system working together to cover a bigger space.
I hope this help, we are very interested to hear of your progress. We are planning to work more on TDoA during the summer as well.
/Arnaud
Sounds interesting! What firmware are you using, did you re-write your own TDoA firmware? I will assume you are using the loco nodes and firmware in the answers.
1. Unfortunately, as far as I have read, the external synchronization pin is not available on the DWM1000 module. It is only available on the DW1000 chip which means that you would need to design your own board or get some from Decawave to access this pin (I think some of the decawave boards have a synchronization input on the board). My understanding though is that external synchronization is a subject of a complete new class of problems (in handling delay and jitter in the coax for example), so it is not a silver bullet.
2. From my experience this could have at least two cause
- Strong reflection on the floor makes the timing measurement very inaccurate
- You are outside the convex hull of the anchor when starting from the ground
If it is the former, maybe fixing Z=0 when the motors are OFF could improve the situation (an earlier version of our EKF was doing exactly that).
3. Our TDoA firmware is sending a packet every 2ms. Going faster will require some optimisation on the stm32 side (like not calculating the received power for each packet). If I follow your calculation you would like to send one packet every 0.2ms? If so it will be challenging since the packets lenght are actually of a bit more than 128us, it does not let much margin. Maybe by enabling the double buffering mode of the DW1000 chip but even with that there might not be much time to process the packets in the stm32f0.
4. Anchors could send packet on different channels and preamble, this will give us a lot of virtual channel to play with and this can be very advantageous in the case of TWR with TDMA (with 6 anchors it would multiply by 6 the max number of Crazyflie flying at the same time in the system). Though for TDoA I have a hard time finding a use-case: to synchronize the anchors they need to communicate together, currently this is done by having them all on the same channel. There might be a way to make a clever synchronization scheme that would allow the anchors to communicate fast on multiple channel, but the Crazyflie still need to be able to listen to the signals and it can do so on 1 channel at a time anyway. The main use case I see for multiple frequency in TDoA is with making bigger system where there could be multiple overlapping TDoA system working together to cover a bigger space.
I hope this help, we are very interested to hear of your progress. We are planning to work more on TDoA during the summer as well.
/Arnaud
-
meyigo2018
- Beginner
- Posts: 10
- Joined: Wed Jun 14, 2017 1:43 pm
Re: TDoA large Offset
Hi,
Thanks for your reply. I will keep you updated if we got any results
I've been working with bitcraze's implementation of TDoA. There are two other things really concerned me.
1) Clock corrections have really large variance. It can range from 10^-34 to 10^36 for one pair of anchor. Why it could possibly be 10^36? It's even more than 40 bit. In addition, I observed negative values. It seems like the firmware didn't account for clock overflow. BTW, I don't quite understand why we need truncate the frame time to Time Stamp(40 bit)?
2) Distance between two anchors are estimated to be around 600m by measuring the ToF. However, in our set up they should be around 10m. I'm wondering if we could use Kalman Filter to fuse both measurements together to achieve a better result?
Thanks in advance!
Tracy
Thanks for your reply. I will keep you updated if we got any results
I've been working with bitcraze's implementation of TDoA. There are two other things really concerned me.
1) Clock corrections have really large variance. It can range from 10^-34 to 10^36 for one pair of anchor. Why it could possibly be 10^36? It's even more than 40 bit. In addition, I observed negative values. It seems like the firmware didn't account for clock overflow. BTW, I don't quite understand why we need truncate the frame time to Time Stamp(40 bit)?
2) Distance between two anchors are estimated to be around 600m by measuring the ToF. However, in our set up they should be around 10m. I'm wondering if we could use Kalman Filter to fuse both measurements together to achieve a better result?
Thanks in advance!
Tracy
Re: TDoA large Offset
Hi Tracy,
1) This looks like a bug. We are planning to work more on TDoA in the following week and I will have a look at it. The truncation to 40bit is there to avoid caring about clock overflow, without the truncation we would need to keep track of the DW1000 overflow in order to keep an internal 64bit counter. I have even been thinking of truncating the timestamps to 32bit to improve processing efficiency (32bit overflows every ~64ms which should be enough).
2) The distance is not compensated for antenna delay. Though this should add about 300m (the two way ranging code corrects for ~150m on each side) not 600m. TDoA uses the raw time of flight in second anyway, not corrected for antenna delay, in the calculation for time difference of arrival. Do you get reasonable values at the output of the TDoA calculation? (ie. the difference of distance of the tag with two anchors)
/Arnaud
1) This looks like a bug. We are planning to work more on TDoA in the following week and I will have a look at it. The truncation to 40bit is there to avoid caring about clock overflow, without the truncation we would need to keep track of the DW1000 overflow in order to keep an internal 64bit counter. I have even been thinking of truncating the timestamps to 32bit to improve processing efficiency (32bit overflows every ~64ms which should be enough).
2) The distance is not compensated for antenna delay. Though this should add about 300m (the two way ranging code corrects for ~150m on each side) not 600m. TDoA uses the raw time of flight in second anyway, not corrected for antenna delay, in the calculation for time difference of arrival. Do you get reasonable values at the output of the TDoA calculation? (ie. the difference of distance of the tag with two anchors)
/Arnaud
-
justinleeyang
- Expert
- Posts: 186
- Joined: Mon Dec 28, 2015 5:07 am
Re: TDoA large Offset
hi, arnaud:
about your doubel buffering suggestion:
about your doubel buffering suggestion:
according to the decawave FAE, the double buffer have some bugs, so don't care the feature.Maybe by enabling the double buffering mode of the DW1000 chip but even with that there might not be much time to process the packets in the stm32f0.