Accurate Tello position data

[SMerrony]

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]

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]

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]

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]

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]

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]

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]

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.

 

[marcolli]

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]

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]

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.

 

[FlandersNed]

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.



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

 

[marcolli]

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:

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]

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]

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.

 

[marcolli]

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]

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

 

[lmm]

Forgot I made this thread! Anyway, I've managed to access the position data from the optical flow camera (the data the drone uses for stabilisation and hovering). The position data is included in log messages (different from the flight status messages) which are sent to the controlling device. You can decode and then pick out the positional coordinates from these messages (big thanks to Krag who implemented this in C#). These measurements are much more accurate.

One word of caution, the position coordinates seem to jump to random values on takeoff which causes the rest of the coordinates to be offset, so this needs to be accounted for.

How did you access the position data from the optical flow camera?