tdoa data of Crazyflie
tdoa data of Crazyflie
I want to fetch the distance of crazyflie to each loco anchor. Under the log configures, I saw there is an tdoa set and under tdoa there are some data like d0-1,d1-2, I was wondering what that data stands for.
- Attachments
-
- QQ截图20181102132521.png (6.21 KiB) Viewed 8930 times
-
- Bitcraze
- Posts: 630
- Joined: Tue Jun 30, 2015 7:47 am
Re: tdoa data of Crazyflie
The TDoA log data is a bit messy, sorry about that. It is unfortunately not possible to get a measurement of the distance from the CF to an anchor in TDoA, what you can get is the difference in distance to two anchors (see https://wiki.bitcraze.io/doc:lps:tdoa:principles).
You can calculate the estimated distance by using the estimated postiion (in log vars stateEstimate.x, y and z) and the known anchor position.
It is probably a good idea to describe the tdoa logging data anyway.
There are two sets of logging data, one for TDoA2 and one for TDoA3. I will try to outline the behaviour but the best source for details is the source code![:-) :-)](./images/smilies/icon_e_smile.gif)
TDoA2
Source code: https://github.com/bitcraze/crazyflie-f ... Tag.c#L502
The log data available:
For example: in our office system the TOF between A0 and A1 is around 33840 ticks, which translates to 158.77 meters.
TOF is the time from transmission to reception and it includes the time it takes to propagate through antennas and other delays. The sum of these delays is 154.6 meters why the actual distance between A0 and A1 is 158.77 - 154.6 = 4.17 m
Since TDoA2 is time slotted and anchors are transmitting in sequence, the data we get in the system is always (except when loosing packets) between A0 to A1, A1 to A2 and so on, hence the logging variables.
TDoA3
Source code: https://github.com/bitcraze/crazyflie-f ... Tag.c#L334
The same data is available for TDoA3 but since we do not know anything about the order we receive packets or which anchors that are available, the system has been generalized.
There are two parameters that are used to tell the CF which anchors to log data for.
You can calculate the estimated distance by using the estimated postiion (in log vars stateEstimate.x, y and z) and the known anchor position.
It is probably a good idea to describe the tdoa logging data anyway.
There are two sets of logging data, one for TDoA2 and one for TDoA3. I will try to outline the behaviour but the best source for details is the source code
![:-) :-)](./images/smilies/icon_e_smile.gif)
TDoA2
Source code: https://github.com/bitcraze/crazyflie-f ... Tag.c#L502
The log data available:
- tdoa.d0-1: The difference in distance to anchor 0 VS anchor 1, in meters. A positive value means that you are closer to A0 than A1
- tdoa.d1-2: For A1 VS A2 and so on
- tdoa.cc0: Clock correction of A0 VS clock in the CF
- tdoa.cc1: Clock correction for A1 and so on
- tdoa.dist0-1: The Time Of Flight between anchor 0 and 1, measured by A1.
- tdoa.dist1-2: The Time Of Flight between anchor 1 and 2, measured by A2 and so on
For example: in our office system the TOF between A0 and A1 is around 33840 ticks, which translates to 158.77 meters.
TOF is the time from transmission to reception and it includes the time it takes to propagate through antennas and other delays. The sum of these delays is 154.6 meters why the actual distance between A0 and A1 is 158.77 - 154.6 = 4.17 m
Since TDoA2 is time slotted and anchors are transmitting in sequence, the data we get in the system is always (except when loosing packets) between A0 to A1, A1 to A2 and so on, hence the logging variables.
TDoA3
Source code: https://github.com/bitcraze/crazyflie-f ... Tag.c#L334
The same data is available for TDoA3 but since we do not know anything about the order we receive packets or which anchors that are available, the system has been generalized.
There are two parameters that are used to tell the CF which anchors to log data for.
- tdoa3.logId: the id of the primary anchor
- tdoa3.logOthrId: the id of the secondary anchor
- tdoa3.tdoa: The difference in distance to the primary and secondary anchors
- tdoa3.cc: the clock correction for the primary anchor
- tdoa3.tof: the TOF between the primary and secondary anchors
Re: tdoa data of Crazyflie
Hi dyang,
I want to get the TDoA data in ROS,Similar to the form of a ros node that publishes tdoa data,do you have any ideas?
Thanks in advance!
dan.
I want to get the TDoA data in ROS,Similar to the form of a ros node that publishes tdoa data,do you have any ideas?
Thanks in advance!
dan.
Re: tdoa data of Crazyflie
Hi,
Using the ROS crazyflie driver you can setup custom log block that are published as ros topic. You can see an example of it in the crazyflie_demo package: https://github.com/whoenig/crazyflie_ro ... cks.launch.
To set parameters, all parameters are exposed as ROS parameters after connection, and the ROS Crazyflie driver exposes a service to send updated parameters to the Crazyflie.
These two capabilities will allow you to implement the methods Kristoffer described above.
Using the ROS crazyflie driver you can setup custom log block that are published as ros topic. You can see an example of it in the crazyflie_demo package: https://github.com/whoenig/crazyflie_ro ... cks.launch.
To set parameters, all parameters are exposed as ROS parameters after connection, and the ROS Crazyflie driver exposes a service to send updated parameters to the Crazyflie.
These two capabilities will allow you to implement the methods Kristoffer described above.
Re: tdoa data of Crazyflie
Hi arnaud,
Thank you for your help!
Our lab wants to write a fusion algorithm by using UWB's positioning data and The IMU data, and then the location information is sent to the crazyfile, which has obtained a more accurate positioning flight.now i have two plan:
1. Using the crazyfile_demo package to get the data of the LPS system, and then use the script in crazyfile_python_lib to control the flight.
2.Based on the modification of the crazyswarm project, I believe it should also have a flying system, which I have not studied it carefully.
I don't know which way is better,Do you have any advice?
THanks a lot!
dan
Thank you for your help!
Our lab wants to write a fusion algorithm by using UWB's positioning data and The IMU data, and then the location information is sent to the crazyfile, which has obtained a more accurate positioning flight.now i have two plan:
1. Using the crazyfile_demo package to get the data of the LPS system, and then use the script in crazyfile_python_lib to control the flight.
2.Based on the modification of the crazyswarm project, I believe it should also have a flying system, which I have not studied it carefully.
I don't know which way is better,Do you have any advice?
THanks a lot!
dan
Re: tdoa data of Crazyflie
Hi,
1. is not possible nor desirable: Either you should use ROS or the crazyflie-python-lib, you will not be able to connect the same Crazyflie with both at the same time. What to use depends a lot of what you are used to and what is your setup: if you are not already familiar with ROS and you do not want to fly a big amount of Crazyflies at once, sticking with the Crazyflie python lib (cflib) will be simpler.
2. Is interesting if you are already familiar with ROS and want to work in ROS or plan to fly a lot of drones. The Crazyflie ROS driver is written in C++ and it is currently much more efficient at handling bit swarms than the cflib, though it requires you to modify the C++ code if you want to implement any new messages.
1. is not possible nor desirable: Either you should use ROS or the crazyflie-python-lib, you will not be able to connect the same Crazyflie with both at the same time. What to use depends a lot of what you are used to and what is your setup: if you are not already familiar with ROS and you do not want to fly a big amount of Crazyflies at once, sticking with the Crazyflie python lib (cflib) will be simpler.
2. Is interesting if you are already familiar with ROS and want to work in ROS or plan to fly a lot of drones. The Crazyflie ROS driver is written in C++ and it is currently much more efficient at handling bit swarms than the cflib, though it requires you to modify the C++ code if you want to implement any new messages.
Re: tdoa data of Crazyflie
Hi arnaud,
Here is the thing, we We want to reproduce this videohttps://www.youtube.com/watch?v=_sUeGC-8dyk,but We found that the accuracy of the LPS was not enough. When we used the joystick to control an crazyfile, it could not accurately land on the extension of the key.
we guess that the LPS system does not tightly couple the IMU and UWB data. Is that correct?
So we want to design the tight coupling algorithm ourselves, which requires UWB data on ROS, so according to what you said, using cflib to fly does not use ROS?
Thank again again,
dan
Here is the thing, we We want to reproduce this videohttps://www.youtube.com/watch?v=_sUeGC-8dyk,but We found that the accuracy of the LPS was not enough. When we used the joystick to control an crazyfile, it could not accurately land on the extension of the key.
we guess that the LPS system does not tightly couple the IMU and UWB data. Is that correct?
So we want to design the tight coupling algorithm ourselves, which requires UWB data on ROS, so according to what you said, using cflib to fly does not use ROS?
Thank again again,
dan
Re: tdoa data of Crazyflie
Hi arnaud,arnaud wrote: ↑Thu Sep 12, 2019 9:20 am Hi,
1. is not possible nor desirable: Either you should use ROS or the crazyflie-python-lib, you will not be able to connect the same Crazyflie with both at the same time. What to use depends a lot of what you are used to and what is your setup: if you are not already familiar with ROS and you do not want to fly a big amount of Crazyflies at once, sticking with the Crazyflie python lib (cflib) will be simpler.
2. Is interesting if you are already familiar with ROS and want to work in ROS or plan to fly a lot of drones. The Crazyflie ROS driver is written in C++ and it is currently much more efficient at handling bit swarms than the cflib, though it requires you to modify the C++ code if you want to implement any new messages.
Here is the thing, we We want to reproduce this video https://www.youtube.com/watch?v=_sUeGC-8dyk,but We found that the accuracy of the LPS was not enough. When we used the joystick to control an crazyfile, it could not accurately land on the extension of the key.
we guess that the LPS system does not tightly couple the IMU and UWB data. Is that correct?
So we want to design the tight coupling algorithm ourselves, which requires UWB data on ROS, so according to what you said, using cflib to fly does not use ROS?
Thank again again,
dan
Re: tdoa data of Crazyflie
I believe the LPS is not accurate enough to archive what you want. You need a more high precision system such as the lighthouse or a MoCap system.
Re: tdoa data of Crazyflie
thank you for your reply!tobias wrote: ↑Mon Sep 16, 2019 11:47 am I believe the LPS is not accurate enough to archive what you want. You need a more high precision system such as the lighthouse or a MoCap system.
But unfortunately our lab mainly do wireless signal research. Do you think there is a way to improve the accuracy of UWB positioning?
such as the fusion of IMU and UWB signals?