mavlink - google protobufs

[anderluntermbiambam]

Hello,

at the moment I am looking for a generic approach for exchanging telemetry data (mainly loads of sensor data) between different platforms. Since MAVlink, as well as google protobufs seem to be good options for this purpose, I am considering both, before I decide to choose one of them. Due to that I have some questions about MAVlink. (just for understanding)

MAVlink seems to use google protobufs, as can be seen in this file:

https://github.com/mavlink/mavlink/blob/af2871c6f5d2e136354ccdba52df0d2921aa3505/pymavlink/mission.proto

1.) In how far is MAVlink compatible to google protobufs. Does it use the same (or a similar) serialization method for the data? 

2.) Or does MAVlink even use google protobufs for serialization? 
3.) Are google protobufs and MAVlink compatible or interchangeable in any way?

Since I am new to MAVlink, I would be glad if you could bring light into that ...

Thanks

Andi

[John Wiseman]

No protobufs are used in the mavlink protocol.

I added that protobuf code as an attempt to create a more readable & writeable mission file format, which is the only thing it's sued for.  Unfortunately it doesn't seem to have caught on at all. :(

As an example,

QGC WPL PB 110

defaults {

  # Default coordinate frame for this mission.

  frame: FRAME_GLOBAL_RELATIVE_ALT

}

waypoint {

  command: CMD_NAV_WAYPOINT

  x: -35.362881

  y: 149.165222

  z: 582.0

}

waypoint {

  command: CMD_NAV_TAKEOFF

  x: -35.362881

  y: 149.165222

  z: 20.0

}

# etc.

vs.

QGC WPL 110

0 1 0 16 0 0 0 0 51.968611 -0.394725 0.000000 1

1 0 3 22 0.000000 0.000000 0.000000 0.000000 51.968746 -0.394650 15.000000 1

2 0 3 16 0.000000 0.000000 0.000000 0.000000 51.968815 -0.395905 15.000000 1

3 0 3 112 30.000000 0.000000 0.000000 0.000000 51.968418 -0.395433 20.000000 1

4 0 3 16 0.000000 0.000000 0.000000 0.000000 51.968102 -0.396355 20.000000 1

5 0 3 16 0.000000 0.000000 0.000000 0.000000 51.967918 -0.395009 15.000000 1

6 0 3 16 0.000000 0.000000 0.000000 0.000000 51.968521 -0.394564 16.000000 1

7 0 3 21 0.000000 0.000000 0.000000 0.000000 51.968575 -0.394521 0.000000 1

--
Sie erhalten diese Nachricht, weil Sie in Google Groups E-Mails von der Gruppe "MAVLink" abonniert haben.
Wenn Sie sich von dieser Gruppe abmelden und keine E-Mails mehr von dieser Gruppe erhalten möchten, senden Sie eine E-Mail an mavlink+u...@googlegroups.com.
Weitere Optionen finden Sie unter https://groups.google.com/d/optout.

[anderluntermbiambam]

Ok, thank you for this info. That solves my confusion. Consequently probofs and mavlink are not compatible in any way neither, right? 

Just for convienience: If embedded systems are involved mavlink seems to be more attractive, since its libraries are more compact. It is optimized for that in the first place.
Although there also are approaches to support google protobuf on embedded systems (or at least in plain c):
- koti.kapsi.fi/jpa/nanopb

- https://code.google.com/p/protobuf-embedded-c

- https://github.com/acg/lwpb

- https://github.com/haberman/upb

- https://github.com/cloudwu/pbc

[John Wiseman]

Protobufs have more CPU and probably more transmission/space overhead than mavlink, but they seem to address several issues with mavlink:

1. Optional fields. E.g. you could send a SERVO_OUTPUT_RAW message that contained values only for the servos you wanted to change, which would probably save bandwidth.
   
2. Repeated fields. E.g., this would allow for variable length arrays.
   
3. Variable-length fields.  E.g., sending the status "OK" would take only 4 bytes over the wire vs. the fixed 50-byte length for mavlink.
4. Fully specified & productionized for several years. Compare e.g. to https://github.com/mavlink/mavlink/issues/45 and the underspecified mavlink field ordering spec.
5. Wire format separate from in-memory representation, E.g. mavlink conflates the wire protocol with the onboard memory layout, as seen in the requirement for re-ordering fields before calculating CRCs.

Mavlink is carefully tuned to work well for microcontroller-based flight controllers with low-bandwidth radio links.  It wouldn't surprise me to see it revised a few times for the new regime of system-on-a-chip controllers with more CPU and RAM, eventually becoming equivalent to something like protocol buffers, thrift, etc.  The biggest question might be whether a wire format optimized for TCP/IP can work well over radio.  It might be an interesting exercise to create a protobuf version of mavlink, keeping the same messages and semantics as they make sense and changing other messages to take advantage of protobuf features, and possibly experimenting with different wire formats.

John