Accurate Tello position data

[marcolli]

Has anyone managed to get accurate relative position data off the Tello? At the moment, I am using the North/East velocity data from the Tello and using that to calculate position based on:

x1 = x0 + v*(t1-t0)

However, the position data quickly becomes inaccurate, to the point where after 20-30 seconds of flight the (0, 0) position of the drone is at least a meter away from where it started.

I suspect that the velocity data being sent by the Tello is only based on the IMU (I may be wrong). Either way, has anyone managed to find a reliable and accurate way of tracking the position of the Tello? E.g. through optical flow data

 

[vzr]

This is as far as you will get with precizion w/o GPS data and 1m sounds too good. It could be used to implement some sort of basic flight tracker and RTH

 

[marcolli]

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.

 

[VR_Dev]

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.

Just bought my tello and I'm super interested in position tracking for use in autopilot programs. Currently flying with a thrustmaster flightstick via Unity

Curious where I might find the c# implementation of this.

Edit: So looking into krag I assume he wrote tellolib, which I'm already using. Curious if that's the positional tracking from the camera or some velocity based calculation?

 

[bluejune]

Refer to "Has anyone decoded the log headers/messages from the Tello?" threads.
And MVO data in this comment

 

[marcolli]

Refer to "Has anyone decoded the log headers/messages from the Tello?" threads.
And MVO data in this comment

Thanks, this thread has been a big help!

 

[marcolli]

Just bought my tello and I'm super interested in position tracking for use in autopilot programs. Currently flying with a thrustmaster flightstick via Unity

Curious where I might find the c# implementation of this.

Edit: So looking into krag I assume he wrote tellolib, which I'm already using. Curious if that's the positional tracking from the camera or some velocity based calculation?

Yes TelloLib is the c# version. If he's doing position tracking I would assume he does it from based on the bottom-facing camera data. This is far more accurate whereas the position data from the flight logs is so bad it's pretty much worthless in my opinion

 

[vzr]

Yeah, but bottom camera data become also useless when vision provisioning fail for the first time

 

[marcolli]

Yeah, but bottom camera data become also useless when vision provisioning fail for the first time

Hmm I haven't experienced this yet (but I haven't done very long flights yet). What happened in your experience?

 

[vzr]

Happens when you fly on high altitude with bad light conditions

 

[marcolli]

That makes sense, but as good a drone as the Tello is you will always have limitations at this price level. If you can keep to low altitudes and good light conditions then the camera position data is good enough for a lot of applications including RTH

 

[vzr]

Yes, but this doesn't mean that it can't be improved. For instance, lastest ATP app combine data from the phone and the drone to calculate more precize orientation for headless mode, and it's pretty amasing, works much better then previous version which used only flight data

 

[marcolli]

Yes, but this doesn't mean that it can't be improved. For instance, lastest ATP app combine data from the phone and the drone to calculate more precize orientation for headless mode, and it's pretty amasing, works much better then previous version which used only flight data

I wasn't aware of this - do you know what data it is using from the phone? Anyway, for my project I'll be running the drone from a laptop rather than a phone so I'm not sure of it's something I can utilise for my needs

 

[vzr]

It uses compass data from the phone to get pilot orientation, and it uses flight data to get drone orientation. With these two orientation you can calculate drone offset relative to the phone which is crucial for headless mode. In previous version, headless mode worked only if you align together phone and drone before taking off and only if you don't change phone orientation during the flight.

 

[marcolli]

It uses compass data from the phone to get pilot orientation, and it uses flight data to get drone orientation. With these two orientation you can calculate drone offset relative to the phone which is crucial for headless mode. In previous version, headless mode worked only if you align together phone and drone before taking off and only if you don't change phone orientation during the flight.

I'm a bit confused - with "drone offset" are you referring to rotational or translational offset? I don't really understand how the orientation difference of the drone and the compass can be used to calculate position.

 

[vzr]

Orientation of drone (compass), but relative to orientation of phone (difference between two orientations)

Example:
If drone points on North, and phone points on West, this value would be -270 deg because drone is oriented 270 degree CW (90 CCW) compared to phone. So, in headless mode, right stick axis are realigned respectively to keep orientation control consistent.

 

[marcolli]

Orientation of drone (compass), but relative to orientation of phone (difference between two orientations)

Example:
If drone points on North, and phone points on West, this value would be -270 deg because drone is oriented 270 degree CW (90 CCW) compared to phone. So, in headless mode, right stick axis are realigned respectively to keep orientation control consistent.

Ok, that makes sense. So this method doesn't actually improve the quality of the position data (i.e. x/y/z co-ords) just the orientations?

 

[vzr]

Yeah. The point is that phone sensors can be fused with drone flight data to get more accuracy.

 

[marcolli]

Yeah. The point is that phone sensors can be fused with drone flight data to get more accuracy.

I can see the appeal of this for drone-piloting applications. For my particular project, I simply want to tell the drone to fly a certain path and take pictures (through a Python script). As long as the drone recognises which way it is pointing it's good enough for my needs, but thanks for the suggestion.

 

[VR_Dev]

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.

I have noticed this as well, and it is quite a problem for my planned autopilot. Curious if anyone has found a reliable solution?