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.

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

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

The value is in ticks of the clock in the anchor. To convert it to distance (meters), multiply by the speed of light and divide by the clock freq. dist = tof * 299792458 / (499.2e6 * 128)
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.

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

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.

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

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.

Hi arnaud,
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