Replies to This Discussion

DeveloperPermalink Reply by Doug Weibel on May 18, 2012 at 12:20pm

Mavlink 0.9

• ▶ Reply

Permalink Reply by Søren Kuula on May 18, 2012 at 1:33pm

Hi,

Thank you very much.

I find no description of the frame format in Mavlink except that link I posted before with the image in it. The only other information I have found it to generate C code with the Python generator and then reverse engineer it. Did I miss something?

Is there somewhere a brief and accurate description of the Mavlink 0.9 frame format? Possibly including an explanation of how the seq field is used? Is the frame format significantly different from that of 1.0 or are only the messages different?

Kind regards

Soren

• ▶ Reply

Permalink Reply by Søren Kuula on May 18, 2012 at 2:07pm

Hi,

OK after a little more reverse engineering: v0.9 does not use this extra addition of field hash to CRC. Its frame start character is 0x55, not 0xfe as in 1.0. My program decodes and verifies correctly the 0.9 mesages generated by the C code generated by the QGroundControl code generator. However, the CRC is different as generated by the APM..? My program always gets a CRC mismatch with those.

Kind regards

Soren

• ▶ Reply

Permalink Reply by Vernon Barry on May 18, 2012 at 2:19pm

Why not use some code from one of the projects that already reads the mavlink from the current ardupilot firmwares like minimOSD? Again, If I was trying to read mavlink data, this is working code.

Why re-invent the wheel when it's done already?

http://code.google.com/p/arducam-osd/wiki/minimosd

Source code:http://code.google.com/p/arducam-osd/source/checkout

 

While it's for arduino, it's basically C++ langauage, so the libraries and other key info are all right there and work, rather than going the hard way.

 

Think of it like this, that code base reads in mavlink, assigns the data to variables which are then coded to be displayed via the encoder chip on the NTSC or PAL signal. You don't care about that last part, but how hard is it to add code to do something else with the data in the variables after it's decoded from mavlink? I look at that as a perfect front end for just about any project wanting to talk to an APM.

• ▶ Reply

Permalink Reply by Søren Kuula on May 18, 2012 at 3:21pm

Hi,

Thanks again for the answer -

I just prefer to have a code generator rather than a code instance for one particular Mavlink version - now that it should be possible. And after several frustrating flight experiences I want to make a really die-hard decoder that will not lose the "connection" (it will be truly stateless and as error tolerant as I can get it), so that is why I think I have to fiddle with all the details.

I will have a lootk at the OSD code, thanks!

Meanwhile - can it really be true what I see here in the data:

55 0301 0101 0302 0101 2204 2760 dc02

This is a Mavlink 0.9 boot message with seq, systemId and componentId all equal to one. It has a length field with the value 3! Hmmm but the boot message has a single field, of length 4. Does it mean that parts of messages or their fields may be truncated away?

Kind regards,

Soren

• ▶ Reply

Permalink Reply by Søren Kuula on May 18, 2012 at 11:19pm

Hi,

Thanks for spotting that! Yeah I have probably mistaken the message id with one of the other fields with the value 01. And yes 03 seems to be a ping in 0.9.

How do you get the single uint32_t in the boot message to have length 3? I believe 32 bits are 4...

Kind regards

Soren

• ▶ Reply

Permalink Reply by Søren Kuula on May 18, 2012 at 11:22pm

Hi,

I have that one directly from an APM1, saved from a file in a terminal emulator after carefully trying to set it up not to translate characters etc, and then opened in emacs, hexl mode.

I have not posted any examples of output from my own Mavlink stack.

Kind regards

Soren

• ▶ Reply

Permalink Reply by Cameron Lattz on May 19, 2012 at 3:07am

Soren, I apologize for the earlier post. You're right, it should have length 4. I don't know what to tell you about the 3. I have been doing the same thing as you (custom Java decoder), and have never seen the same problem.

Permalink Reply by Cameron Lattz on May 19, 2012 at 3:38am

Looking at the output file, it looks like many if not all of the messages a reading a payload that is 1 less than it should be.

55 02 3F 01 01 2A D3 D9. This is another error. It either has no checksum or no payload.

DeveloperPermalink Reply by Michael Oborne on May 19, 2012 at 4:27am

the "U" isnt counted, as technicaly its a sync byte.

Permalink Reply by Søren Kuula on May 19, 2012 at 4:40am

Hi all,

OK I think I have found the cause of my misery!

Apparently minicom (terminal emulator for linux) had the idea that NULs (bytes of value 00) should not be saved to the log file. There is not a single one...

After trying with Tera Term for Windows, and correcting a bug in my java program, it now works a lot better! I have good checksums everywhere and no data is spilled, so I think I have the packeting right now.

Now I just need to get the values to interpret correctly, floats in particular...

Thanks all for the help.

Kind regards

Soren

Permalink Reply by matthew c culver on May 22, 2012 at 6:04pm

I dont Make UAVS persay but im working on a holographic video game consol with a sensor relay
The CPU coding i could handle and the circutry i could probably handle but i cannot get may hands on a
better sensor to read from than a webcam. Im looking for something along the right path that i can build from. ? Any helo?

• ▶ Reply

• ‹ Previous
• 1
• 2
• Next ›
• Page