I have an APM1 and an APM2, with ArduPlane 2.33 on them. Communicate fine with Mission Planner. Well sometimes the "connection" breaks down and I can't reconnect but that is another story..
Now I want to play with my own mission tool, and have that communicate with the APMs.
I have logged a little data from the APM2 serial stream, excerpt shown here in hex dump (and more is attached):
00000300: 0302 7861 5524 0101 2204 2760 dc83 ee55 ..xaU$..".'`...U
00000310: 3325 0101 fe01 4465 6d6f 2053 6572 766f 3%....Demo Servo
00000320: 7321 93d5 5503 2601 0101 0302 db91 5527 s!..U.&.......U'
00000330: 0101 2204 2760 dcfd 3655 3328 0101 fe01 ..".'`..6U3(....
00000340: 0a0a 2052 6561 6479 2074 6f20 464c 592e .. Ready to FLY.
00000350: c564 5529 0101 2202 0404 2760 dcdc c455 .dU).."...'`...U
00000360: 042a 0101 9812 7820 ca19 5502 2b01 012a .*....x ..U.+..*
00000370: cf8b 5525 2c01 0120 f806 3001 4309 461c ..U%,.. ..0.C.F.
00000380: 3c63 5655 652d 0101 d855 122e 0101 4902 <cVUe-...U....I.
00000390: 1728 f47a 5510 2f01 0125 0384 04b0 04b0 .(.zU./..%......
000003a0: 04b0 bf55 1130 0101 2303 8404 b004 b004 ...U.0..#.......
000003b0: b004 b004 b004 b004 b001 5355 2031 0101 ..........SU 1..
000003c0: 1ef8 3c64 401c c82d ba1f e190 ba49 bd30 ..<d@..-.....I.0
000003d0: 396f 1cd3 4655 1432 0101 4a40 351e b801 9o..FU.2..J@5...
000003e0: 8e55 1c33 0101 a33a f7ca d1bb 17b9 46f0 .U.3...:......F.
000003f0: be3f bb56 f098 5e55 0334 0101 a565 8c55 .?.V..^U.4...e.U
00000400: 1035 0101 2503 8404 b004 b004 b069 e455 .5..%........i.U
00000410: 1136 0101 2303 8404 b004 b004 b004 b004 .6..#...........
00000420: b004 b004 b001 3bbc 5520 3701 011e f9d1 ......;.U 7.....
00000430: d83a 603a 14bc 9c80 b5bf aaa6 163c 19ce .:`:.........<..
00000440: 25be 39e4 b93a b756 57f2 f155 1438 0101 %.9..:.VW..U.8..
00000450: 4a40 28f6 018d 5510 3901 0125 0384 04b0 J@(...U.9..%....
00000460: 04b0 04b0 d44b 5511 3a01 0123 0384 04b0 .....KU.:..#....
00000470: 04b0 04b0 04b0 04b0 04b0 04b0 01fa d255 ...............U
Now I wonder what message format is really used after all?
It can't be Mavlink 1.0 on the format described here:
because I see wildly varying system and component IDs and invalid message IDs, and the CRC never matches. I have used a home made Java program to try decode this data and the program works fine with binary data generated by the Pixhawk Python code generator code, for MavLink1.0 with the extra-field-hash-CRC thing enabled. Field reordering is not an issue; I am not even that far yet.
It can't be the ArdupilotMega binary protocol either, because I never see 0x3444.
What format is this data...?
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?
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.
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?
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.
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?
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...
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.
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.
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.
the "U" isnt counted, as technicaly its a sync byte.
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.