Hello Tello Pilot!
Join our DJI Tello community & remove this banner.
Sign up

Accurate Tello position data

SMerrony

Well-known member
Joined
May 1, 2018
Messages
65
Reaction score
61
Location
France
I have noticed this as well, and it is quite a problem for my planned autopilot. Curious if anyone has found a reliable solution?
I don't think there is a good solution to this. I've been looking at the position data and the quality of it seems very dependent upon both the ambient light level and ground surface. It might be possible to filter out 'obviously wrong' data points - I have noticed that often just the X, or just the Y ordinate is near zero on dubious position reports.

I think there probably are "reset yaw" and "reset (home) position" Tello commands - but no-one seems to have discovered them yet. That leaves us compensating in software for the random jump at start-up etc. once things have stabilised.
 

marcolli

Active member
Joined
Aug 3, 2018
Messages
37
Reaction score
8
I have noticed this as well, and it is quite a problem for my planned autopilot. Curious if anyone has found a reliable solution?
To workaround the issue, I've programmed the takeoff command to capture the position data of the drone about 3 seconds after takeoff (this gives it a chance to stabilise), then I reset the position to zero.

Whenever new position data is acquired from the log messages, I subtract the original position matrix, so that the drone is always relative to the point where it stabilised after takeoff. Would that be sufficient for your application?
 

VR_Dev

Active member
Joined
Aug 19, 2018
Messages
35
Reaction score
33
To workaround the issue, I've programmed the takeoff command to capture the position data of the drone about 3 seconds after takeoff (this gives it a chance to stabilise), then I reset the position to zero.

Whenever new position data is acquired from the log messages, I subtract the original position matrix, so that the drone is always relative to the point where it stabilised after takeoff. Would that be sufficient for your application?
That's what I assumed unfortunately. My plans involve a known start point however, so I'm thinking I'll have to just manually fly it over a target position at the correct height, then set that as my origin.
 

marcolli

Active member
Joined
Aug 3, 2018
Messages
37
Reaction score
8
That's what I assumed unfortunately. My plans involve a known start point however, so I'm thinking I'll have to just manually fly it over a target position at the correct height, then set that as my origin.
I see. The manual position reset method is only for testing.

For my project I also need to set a starting point relative to a known position. My plan is to have a calibration target mounted on e.g. a wall which the drone can identify using the camera. Then by processing the image data it can figure out where it is relative to the target and calibrate like that. I think that may be a more accurate method than what you're suggesting
 

VR_Dev

Active member
Joined
Aug 19, 2018
Messages
35
Reaction score
33
Yeah manually will be quick and dirty. I also thought of some kind calibration via the camera, but maybe that's something someone is already working on. That appears to be how this swarm flight is possible.


On another thought, I'm curious about the height data. Seems to come in less frequently than position data via telloLib, and doesn't seem to be super accurate.
 

marcolli

Active member
Joined
Aug 3, 2018
Messages
37
Reaction score
8
Yeah manually will be quick and dirty. I also thought of some kind calibration via the camera, but maybe that's something someone is already working on. That appears to be how this swarm flight is possible.


On another thought, I'm curious about the height data. Seems to come in less frequently than position data via telloLib, and doesn't seem to be super accurate.
I saw this project the other day, looks super cool. I'm not sure how he's accessed the downward-facing camera data though. I'd love to access the actual data rather than just the derived data (i.e. position and velocity).

I may get round to doing the camera calibration but I have some more pressing matters to sort out first
 

VR_Dev

Active member
Joined
Aug 19, 2018
Messages
35
Reaction score
33
I saw this project the other day, looks super cool. I'm not sure how he's accessed the downward-facing camera data though. I'd love to access the actual data rather than just the derived data (i.e. position and velocity).

I may get round to doing the camera calibration but I have some more pressing matters to sort out first
I see you asked, but I assume they have just diverted the forward camera down somehow. I saw a guy do it with a mirror and printed mount. Also what raw data are you referring to? I'm pretty sure the posX/Y/Z and quatW/X/Y/Z in tellolib come straight from the MOV log. Is there something else more accurate than that?
 

VR_Dev

Active member
Joined
Aug 19, 2018
Messages
35
Reaction score
33
So I have 3D tracking working in Unity, and I'm pretty happy with the results. From what I can tell tracking remains accurate for the duration of the flight. Still really confused about height though. After takeoff I click the trigger which begins tracking from that position. At trigger click the green plane gets placed according to Tello's height value. Then the smaller white plane is placed at that value every update. As far as I can tell the height value is totally wrong, but the obv tello knows for sure where the ground is for bounce and land. So I assume the problem is decoding the value.

Next step is tracking tello with through a model of its environment. Also need to figure out rotation.


Edit: Forgot to mention this is ignoring outliers in the tracking data. Here you can see what happens when I include those. I assume it's just lost tracking, but then it picks up right where it should be.
 

Attachments

Last edited:

marcolli

Active member
Joined
Aug 3, 2018
Messages
37
Reaction score
8
I see you asked, but I assume they have just diverted the forward camera down somehow. I saw a guy do it with a mirror and printed mount. Also what raw data are you referring to? I'm pretty sure the posX/Y/Z and quatW/X/Y/Z in tellolib come straight from the MOV log. Is there something else more accurate than that?
Yeah someone did that to get downward video stream.

By 'raw data' I'm talking about the actual camera data. The pos and quat data is found using Optical Flow so the downward facing camera must be providing some sort of pixel/image data to the MVO chip to calculate these values. I'm not sure if it's possible to pull this data out.

That Unity sim looks fantastic. What data are you using for the height? I think in this case it may be better to use the height data from the flight event messages (not the MVO log) as I believe that uses the IR sensor on the bottom of the Tello for height calculations... similar to the other positional coordinates the height gets offset when it takes off so it may not be so reliable
 

marcolli

Active member
Joined
Aug 3, 2018
Messages
37
Reaction score
8
So I have 3D tracking working in Unity, and I'm pretty happy with the results. From what I can tell tracking remains accurate for the duration of the flight. Still really confused about height though. After takeoff I click the trigger which begins tracking from that position. At trigger click the green plane gets placed according to Tello's height value. Then the smaller white plane is placed at that value every update. As far as I can tell the height value is totally wrong, but the obv tello knows for sure where the ground is for bounce and land. So I assume the problem is decoding the value.

Next step is tracking tello with through a model of its environment. Also need to figure out rotation.


Edit: Forgot to mention this is ignoring outliers in the tracking data. Here you can see what happens when I include those. I assume it's just lost tracking, but then it picks up right where it should be.
Out of interest, are you also zeroing your quaternion data in the same way as the position data?
 

VR_Dev

Active member
Joined
Aug 19, 2018
Messages
35
Reaction score
33
That Unity sim looks fantastic. What data are you using for the height? I think in this case it may be better to use the height data from the flight event messages (not the MVO log) as I believe that uses the IR sensor on the bottom of the Tello for height calculations... similar to the other positional coordinates the height gets offset when it takes off so it may not be so reliable
Thanks. Right now the height (y Axis) works just like the x and z. It's just the offset from the original point designated when I click the trigger. If you were to set the tracking height via the actual ground clearance the tracking would be inaccurate. If you flew over a table the tracking would look like the drone just dropped 4 feet, when really the ground came up.

Right now however TelloLib's "height" value doesn't seem to be accurate. You can see that value represented in the white plane following below the red cube. From what I can tell this doesn't come from the log like the position data does. I'll have to ask @Krag for some clarification on that.

Out of interest, are you also zeroing your quaternion data in the same way as the position data?
In the video above I don't deal with rotation at all. You can see the rectangular cube is always pointing down global Z. This means that the tracking data is not in regards to rotation, but in regards to the orientation set when the tello is powered on. It would be great if this could be reset, but I'm pretty sure no one has figured that out.

I tried using telloLibs "quat" and ToEuler(), but had no luck so far.
 
Last edited:

FlandersNed

Active member
Joined
May 30, 2018
Messages
27
Reaction score
4
Just to add some of my own research; I've been using @SMerrony 's autopilot for this.

I got the drone to output its x, y and yaw in a custom version of autopilot_test.go once it reaches certain points, by doing this:

currentYaw := drone.fd.IMU.Yaw
currentX := drone.fd.MVO.PositionX
currentY := drone.fd.MVO.PositionY

log.Println(currentYaw, currentX, currentY)


I've attached my code in the 'unofficial tello library' thread.

A table is below of two attempts, showing its output. In both attempts, the drone takes off from the same place (a tiled floor), in the same orientation.

1537249928752.png

As it can be seen, the coordinates are inconsistent between attempts.
 

marcolli

Active member
Joined
Aug 3, 2018
Messages
37
Reaction score
8
Thanks. Right now the height (y Axis) works just like the x and z. It's just the offset from the original point designated when I click the trigger. If you were to set the tracking height via the actual ground clearance the tracking would be inaccurate. If you flew over a table the tracking would look like the drone just dropped 4 feet, when really the ground came up.

Right now however TelloLib's "height" value doesn't seem to be accurate. You can see that value represented in the white plane following below the red cube. From what I can tell this doesn't come from the log like the position data does. I'll have to ask @Krag for some clarification on that.



In the video above I don't deal with rotation at all. You can see the rectangular cube is always pointing down global Z. This means that the tracking data is not in regards to rotation, but in regards to the orientation set when the tello is powered on. It would be great if this could be reset, but I'm pretty sure no one has figured that out.

I tried using telloLibs "quat" and ToEuler(), but had no luck so far.
Right, I haven't really looked at the height values yet as I've been trying to get my control loop working in 2D before attempting 3D. If you're pulling height data off the MVO, it will be calculated using optical flow (basically, if it sees the same pixels getting closer together it interprets that as moving upwards, and viceversa for descent). I'm not sure how that would interpret a table suddenly coming into view... but it's something that's probably worth having a proper look at...

Re rotations, I'm able to get yaw data in line with what I'm expecting. I haven't bothered with the other axes as they don't really change in normal flight. I'm just calculating yaw as follows:

Python:
sinY = 2.0 * (qw*qz + qx*qy)
cosY = 1.0 - (2.0 * (qy**2 + qz**2))
yaw = m.atan(sinY/cosY)
I'm gonna try and zero the quaternion values in the same way as the position values (although I'm not certain if this will work). I'll likely be testing it this afternoon so I'll report back with my findings...
 

marcolli

Active member
Joined
Aug 3, 2018
Messages
37
Reaction score
8
Just to add some of my own research; I've been using @SMerrony 's autopilot for this.

I got the drone to output its x, y and yaw in a custom version of autopilot_test.go once it reaches certain points, by doing this:

currentYaw := drone.fd.IMU.Yaw
currentX := drone.fd.MVO.PositionX
currentY := drone.fd.MVO.PositionY

log.Println(currentYaw, currentX, currentY)


I've attached my code in the 'unofficial tello library' thread.

A table is below of two attempts, showing its output. In both attempts, the drone takes off from the same place (a tiled floor), in the same orientation.

View attachment 1588

As it can be seen, the coordinates are inconsistent between attempts.
I have no idea why the second attempt jumps to 92, although occasionally the MVO data does give some crazy numbers. But yes, there always seems to be a random jump after takeoff. I just zero the coordinates after it has settled and before continuing with flight.
 

SMerrony

Well-known member
Joined
May 1, 2018
Messages
65
Reaction score
61
Location
France
I have no idea why the second attempt jumps to 92, although occasionally the MVO data does give some crazy numbers. But yes, there always seems to be a random jump after takeoff. I just zero the coordinates after it has settled and before continuing with flight.
It doesn't, 92 is the yaw - so it's correct.
 
  • Like
Reactions: marcolli

marcolli

Active member
Joined
Aug 3, 2018
Messages
37
Reaction score
8
Ok I tested initialising the quaternions on takeoff, in the same way as the position (by offsetting them) and that seems to have worked fine for me in terms of calculating relative yaw angle. It's a bit of a hack but it does work.

x,y,z should all be initialised to zero and w should be initialised to 1
 

VR_Dev

Active member
Joined
Aug 19, 2018
Messages
35
Reaction score
33
One of my first tries flying through a known environment. I do my best to fly to a known position, which I use as the origin point of the tracking. Also this project has a thread now.

Unity Controller for Tello

 

New Threads

Members online

Forum statistics

Threads
3,554
Messages
27,280
Members
9,271
Latest member
giopg29