This page summarizes various serialization libraries and their pros and cons.

Status

Message formats

Wikipedia also has a page comparing various formats.

There's some comparison of ROS' serialization / deserialization performance against two other robot communication frameworks in this IROS paper.

There are a few notable exceptions in this list, feel free to add them!

• avro

rosmsg (ROS 1.x)

http://wiki/msg

License: BSD

Pros

• Everyone who uses ROS already knows it.
• Messages are basically structs so API for manipulating / accessing fields is simple.
• Message generation is fast and generated files for C++ are header only (no separate compile / linking step required to use messages).
• If we want a feature, we can add it.
• Small memory footprint; libroscpp_serializaiton.so is 12KB in Groovy.

Cons

• No support for message versioning, reflection, default values, and data structures besides arrays.
• Limited support for namespaces.
• Can't define multiple messages in the same file.
• One more thing ROS devs have to write and support themselves.

protobuf

http://code.google.com/p/protobuf/

License: BSD 3-clause.

Also see this thread.

Pros

• Mature library with good documentation.
• Efficient on disk representation.
• Supports several nice features like versioning, optional fields, and reflection.
• Google supports C++, Python, and Java. Unofficial support for many other languages.

Cons

• Designed for messages that are 1MB in size or smaller; by default will not deserialize a message larger than 64MB.
• Protobufs are not plain old data structures and manipulating / accessing fields can be clunky, particularly with nested message types.
• Doesn't support all types that ROS messages currently do (e.g., fixed width 16 byte signed/unsigned ints).
• Generated code is not header only; requires compilation and linking.
• Larger library memory footprint + messages require many heap objects. libprotobuf.so on Ubuntu 12.04 is 956KB and libprotobuf-lite.so is 164KB.

msgpack

http://msgpack.org/

License: Apache

Pros

• Supports associative arrays.
• Many different language bindings (albeit from several different sources).
• Small memory footprint; libmsgpack.so is 24KB in Ubuntu 12.04.

Cons

• Messages are dynamically typed so certain types of errors can't be caught at compile time. Some people may reasonably consider the dynamic typing a pro.

capnproto

http://kentonv.github.io/capnproto/

License: BSD 2-clause

Pros

• A lot of nice features like evolving message definitions, reflection, and incremental reads.
• Being developed by an ex-Googler who worked on protobufs; looks like it will address some of protobufs shortcomings while retaining its core benefits.

Cons

• Client libraries are relatively immature.
• Primary C++ implementation requires C++11.
• Specification isn't finished.

apache thrift

http://thrift.apache.org

License: Apache.

Pros

• Mature library.
• Efficient on disk representation.
• Supports several nice features like versioning, optional fields, and reflection.

• Officially supported languages include C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, JavaScript, Node.js, Smalltalk, OCaml and Delphi.

• Rich set of data types, including sets and maps (associative arrays).
• Built-in RPC mechanism for all the officially supported languages with a clear separation between the serialization protocols and the transports (TCP, HTTP, AMQP and ZeroMQ)
• Support for exceptions in the RPC definitions.
• Fast serialization/deserialization for dynamic languages thanks to native extensions.
• Supported by the Apache Software Foundation.

Cons

• Doesn't support all types that ROS messages currently do (e.g., fixed width 16 byte signed/unsigned ints, only doubles but not floats).
• Generated code is not header only; requires compilation and linking.
• Larger library memory footprint + messages require many heap objects. libthrift_c_glib.so on Ubuntu 12.04 is 66KB