Has anyone decoded the log headers/messages from the Tello?

[BudWalker]

All the columns that I have looked at in detail seem to be correct (unless it is blank or obviously wrong like NAN). Its hard to say what is missing. What I _want_ there to be is something like direction and distance of travel but I don't know if it exists in the log. The Tello does have a downfacing camera that is used for optical flow tracking. Anything to do with that?

How much of the data you are seeing is unknown?

The signals IMU_ATTI(0):velE and IMU_ATTI(0):velN might help. With the other DJI platforms these are velocities with respect to ground. But, that can't be the case with the Tello since it has neither GPS or a compass. I'm suspecting these may be velocity data WRT the tello. Could you do a test flight - maybe something like fly a square. Then we can take a look at these signals and see. To get position these signals will need to be integrated WRT time, but we can worry about that later.

There isn't a simple answer regarding which data is unknown.

You might want to try looking at the DatDefined signals. First look at DatCon3

This is how you get CsvView to show you the DatDefined signals.

 

[JoeBaldy]

... with the above mentioned setting a lot of data is coming out (I do not know if all interesting ...)
As soon as I have some time I will try to draw up a list ...

 

[Krag]

The signals IMU_ATTI(0):velE and IMU_ATTI(0):velN might help. With the other DJI platforms these are velocities with respect to ground. But, that can't be the case with the Tello since it has neither GPS or a compass. I'm suspecting these may be velocity data WRT the tello. Could you do a test flight - maybe something like fly a square. Then we can take a look at these signals and see. To get position these signals will need to be integrated WRT time, but we can worry about that later.

There isn't a simple answer regarding which data is unknown.

You might want to try looking at the DatDefined signals. First look at DatCon3

This is how you get CsvView to show you the DatDefined signals.

The velE and velN are computed using the downward facing camera and optical flow instead of GPS. And apparently yaw also. We have had access to the velocity values for a while but there was no heading information. So with yaw now we can at least do dead reckoning. I am hoping there is also a total distance traveled North/East some where so we wouldn't have to guess as much.

I changed the setting and now see a LOT more data in the csv! So much data... It will take some time to parse it. I am guessing this is everything the Tello is sending?

I can do a a square test flight and send you the dat this afternoon.

 

[Krag]

I _think_ new_mvo_feedbackos_X , Y, Z is what I am looking for. I'll have to test it to be sure.

How do you get the names for the columns? Is that included in the data itself?

 

[BudWalker]

I _think_ new_mvo_feedbackos_X , Y, Z is what I am looking for. I'll have to test it to be sure.

How do you get the names for the columns? Is that included in the data itself?

Yes, you can see the field names by using this DatCon option

then press Go! and then the ViewIt button.

 

[Krag]

Hmm. When I do that the recDefs doesnt seem to include the mvo_feedback items. Not that it matters.

I'm about 80% sure the mvo_feedback stuff is the optical flow data. I just need to get off work so I can go test it.

Assuming it is, how hard is it going to be to pull those values out of the log data in real time? Is it going to be possible to just get the items we need (yaw, posX,Y,Z) for realtime control or are we going to have to parse the whole log data stream?

 

[BudWalker]

Hmm. When I do that the recDefs doesnt seem to include the mvo_feedback items. Not that it matters.
.......?

Yeah, the mvo_feedback definitions actually come from the definitions that occurred in the .DAT for a different platform. This is what I mean by it's not simple.

 

[Krag]

Yeah, the mvo_feedback definitions actually come from the definitions that occurred in the .DAT for a different platform. This is what I mean by it's not simple.

I don't think I follow. Does that mean that the column may not have the right name? I need to learn more about this file format. It sounds really strange.

Attached are some log files. NoTurns is just flying straight forward/back ~+10m and side to side ~+/-5m (that was about the area I had). The Turns one is in the same area but I would turn 90 before flying forward and only flew forward for the most part. The one named Combo is both around the same area.

I haven't had a chance to look at them myself yet, so I don't know if they support the theory about them being relative position.

Edit: Yep! This is pretty much my ground track from my last flight. And far better quality than I expected. This just kicked down a new door.

 

[BudWalker]

I don't think I follow. Does that mean that the column may not have the right name? I need to learn more about this file format. It sounds really strange.
.....

Record definitions exist in several places.

1) In the .DAT file itself. This is what you see when you direct DatCon to produce the RecDefs.txt file. It's often the case that a record definition doesn't exist for a record type that exists in the .DAT. It also is sometimes the case that a record definition is inconsistent with the records that exist in the .DAT

2) In a .DAT file from a different platform,

3) In the decompilation of an older version of the DJI Viewer. That's where the new_mvo_feedback record definition was found.

4) a definition that I've constructed.

When the parsing mode requires obtaining the DAT file definition for a record type DatCon will search the above to find an appropriate record definition. If it can't find one it likes those corresponding records aren't parsed and don't appear in the output.

The field names in a record definition can and do change between platforms and FW versions for the same platform.

 

[Krag]

Record definitions exist in several places.

1) In the .DAT file itself. This is what you see when you direct DatCon to produce the RecDefs.txt file. It's often the case that a record definition doesn't exist for a record type that exists in the .DAT. It also is sometimes the case that a record definition is inconsistent with the records that exist in the .DAT

2) In a .DAT file from a different platform,

3) In the decompilation of an older version of the DJI Viewer. That's where the new_mvo_feedback record definition was found.

4) a definition that I've constructed.

When the parsing mode requires obtaining the DAT file definition for a record type DatCon will search the above to find an appropriate record definition. If it can't find one it likes those corresponding records aren't parsed and don't appear in the output.

The field names in a record definition can and do change between platforms and FW versions for the same platform.

Ok. I think i follow that.

So the practical question is how can I find the records for the pos in the log stream? Do I have to parse the whole thing or can I just find the records for the mvo_* in the dat stream?

 

[BudWalker]

Ok. I think i follow that.

So the practical question is how can I find the records for the pos in the log stream? Do I have to parse the whole thing or can I just find the records for the mvo_* in the dat stream?

By "log stream" do you mean the .DAT file? If so, then you could adapt DatCon to do that. The source can be found here.
DatCon Source

 

[Krag]

Ah perfect! I see the new_mvo_feedback_29 class and can probably puzzle it out,

So if I understand right definitions for the new_mvo items came out of DJI viewer. What was the platform that it was originally used in? Maybe it had the same processor. The reason my eye was drawn to those items was because the Tello processor is the Myriad 2 VPU or I figured the "mv" part.

In the RecDefs that come in the Tello logs are those items identified as something else?

 

[Krag]

I think I found the packet that contains the new_mvo data, and it makes sense up until the timestamp. But the data after that seems strange and repetitive. Is it encoded somehow?

Here is about what the data should at this time based on the output of DatConv.
new_mvo_feedback:visionObservationCount new_mvo_feedback:Vel_X new_mvo_feedback:Vel_Y new_mvo_feedback:Vel_Z new_mvo_feedbackos_X new_mvo_feedbackos_Y new_mvo_feedbackos_Z new_mvo_feedback:hoverPointUncertainty1 new_mvo_feedback:hoverPointUncertainty2 new_mvo_feedback:hoverPointUncertainty3 new_mvo_feedback:hoverPointUncertainty4 new_mvo_feedback:hoverPointUncertainty5 new_mvo_feedback:hoverPointUncertainty6 new_mvo_feedback:velocityUncertainty1 new_mvo_feedback:velocityUncertainty2 new_mvo_feedback:velocityUncertainty3 new_mvo_feedback:velocityUncertainty4 new_mvo_feedback:velocityUncertainty5 new_mvo_feedback:velocityUncertainty6 new_mvo_feedback:height new_mvo_feedback:heightUncertainty new_mvo_feedback:reserved1 new_mvo_feedback:reserved2 new_mvo_feedback:reserved3 new_mvo_feedback:reserved4
594 0 0 0 0.016654518 0.01142995 -0.004121071 1.00E-06 0 1 1.00E-06 0 1.00E-06 1.00E-06 0 -0.024649024 1.00E-06 -0.006546974 1.00E-06 -0.1 0.020000001 8 0 0 10

This is a hex dump of a packet that I think is the mvo items. Id = 29 or 0x1d.
55 5C 00 E1 1D 00 68 71 35 05 3E 6A 68 68 68 68 68 68 64 19 E0 54 E0 2C 53 54 A8 82 EE D3 D6 5F EE 5D 68 68 68 68 68 68 E8 57 D6 5F EE 5D 68 68 68 68 D6 5F EE 5D D6 5F EE 5D 68 68 68 68 38 3D F7 D5 D6 5F EE 5D 68 F3 85 55 D6 5F EE 5D A5 A4 A4 D5 63 BF CB 54 60 68 68 62 80 E9

Parsed based on what I see in the DatCon code.
55 (magic)
5C (len)
00 E1 1D 00 (id)
68 71 35 05 (tick)
3E 6A (observationCount)
68 68 (velX)
68 68 (velY)
68 68 (velZ)
64 19 E0 54 (posX)
E0 2C 53 54 (posY)
A8 82 EE D3 (posZ)
D6 5F EE 5D 68 68 68 68 68 68 E8 57 D6 5F EE 5D 68 68 68 68 D6 5F EE 5D D6 5F EE 5D 68 68 68 68 38 3D F7 D5 D6 5F EE 5D 68 F3 85 55 D6 5F EE 5D A5 A4 A4 D5 63 BF CB 54 60 68 68 62 80 E9

Am I doing something stupid? Its late and I am getting tired.

 

[BudWalker]

I think I found the packet that contains the new_mvo data, and it makes sense up until the timestamp. But the data after that seems strange and repetitive. Is it encoded somehow?

...........

Yes, you'll have to use the DatFileV3 and ConvertDatV3 classes to read the .DAT. I suspect that it will be easier to start with DatCon running and then remove the parts you don't need.

....

So if I understand right definitions for the new_mvo items came out of DJI viewer. What was the platform that it was originally used in? Maybe it had the same processor. The reason my eye was drawn to those items was because the Tello processor is the Myriad 2 VPU or I figured the "mv" part.
......

The Viewer is bundled with DJI Assistant 2. It runs on Windows, and, maybe a Mac. AFAIK, the new_mvo records aren't processed by the Viewer.

In the RecDefs that come in the Tello logs are those items identified as something else?

I don't understand the question.

 

[Krag]

Ok, now that I am awake I see the xor encoding in the payload. I assume that is some sort of security obfuscation on DJIs part. Lame.

The other questions where just curiosity about how the new_mvo definitions were created before Tello came along. Maybe some of the other DJI products use the same vision processor.

 

[Krag]

Yes, that worked like a charm. I have got both mvo pos and the quat from the IMU packet working. Good stuff!

For anyone reading along the body of the payload between the tick and the crc is xor'd with the lowest byte of the tick.

Thanks for the help @BudWalker! I would have never figured this out without your advice. And thanks again for making DatCon, as I said before it saved my *** a few times.

Is there anything else I can do to help you get it supporting Tello? I can exercise any part of it and send you the logs at least.

 

[BudWalker]

Yes, that worked like a charm. I have got both mvo pos and the quat from the IMU packet working. Good stuff!

For anyone reading along the body of the payload between the tick and the crc is xor'd with the lowest byte of the tick.

Thanks for the help @BudWalker! I would have never figured this out without your advice. And thanks again for making DatCon, as I said before it saved my *** a few times.

Is there anything else I can do to help you get it supporting Tello? I can exercise any part of it and send you the logs at least.

Very impressed with what you've done here. This is one of the very few times the DatCon stuff was used as a launching point for new capabilities.

I don't have a lot of time but I'm going to promote the mvo signals to Engineered status. See Engineered/DatDefined Signals to see what this means. Currently, the available mvo fields look like this

Do you have any idea what the 6 uncertainty values are? The heightUncertainty seems obvious. I know what to do with the reserved signals - they will be made into 1 bit flags.

For Yaw you might want to consider using IMU_ATTI(0):totalGyro:Z. But, it's just rotation about the body Z axis. What you actually need is rotation about the gravitational field Z axis. That involves correcting with pitch and roll. I think the way to do this is to add this to the InertialOnlyCalcs

The InertialOnlyCalcs is still kind of a science fair project. It was created for situations where GPS wasn't available or suspect. I'm thinking a more robust strategy will include the mvo signals.

 

[Krag]

Do you have any idea what the 6 uncertainty values are? The heightUncertainty seems obvious. I know what to do with the reserved signals - they will be made into 1 bit flags.

I could only guess. It seems odd they need 6 of them. I did a google search and there are several scholarly articles on optical flow uncertainty. Seems like some next level stuff.

For Yaw you might want to consider using IMU_ATTI(0):totalGyro:Z. But, it's just rotation about the body Z axis. What you actually need is rotation about the gravitational field Z axis. That involves correcting with pitch and roll. I think the way to do this is to add this to the InertialOnlyCalcs

The InertialOnlyCalcs is still kind of a science fair project. It was created for situations where GPS wasn't available or suspect. I'm thinking a more robust strategy will include the mvo signals.

I'll have to look into that, and at least compare it to the yaw value from the imu. Looking at some of my position plots it seems like it is able to regain the position again really well even when optical flow is lost. I wonder if they arn't also factoring inertial measurements into the position data.

I was curious about those reserved fields. They do look like flags. Maybe it will be more obvious when they are separated.

 

[Krag]

The changes to TelloLib to add position and orientation are up below. It should be easy to adapt this code to Go and Python for the other libraries.

Basically you need to Ack cmd id 4176 to start getting 4177. Then send the payload of 4177 to parseLog(). No need to Ack 4177. 4178 and sendAckLogConfig()) are NOT required.

Tello interface now includes Position and Orentation! · Kragrathea/TelloLib@cf1a9b0

 

[SMerrony]

Excellent work guys. I'm going to try out adding a position feed from the Go package now...