rosserial overview: NodeHandles and Initialization | Messages | Publishers and Subscribers | Time | Logging | Limitations | Protocol | Parameters

Limitations

Maximum Size of a Message, Maximum Number of Publishers/Subscribers

The serialization and deserialization buffers are both limited in size.

New in 0.2.0 Previously, both buffers were limited to 512 bytes, however this is larger than the 1k of RAM available on some smaller AVRs such as the ATMEGA168. rosserial_arduino now varies the buffer size depending on the chip used:

You can change these buffer sizes, in ros.h, by changing the final two arguments inside the angle brackets for the typdef NodeHandle_ appropriate for your board type. The template arguments used in the typedef can be found in node_handle.h. You should, however, be careful not to consume too much of the limited SRAM found in the Arduino.

New in 0.3.0 Starting with the 0.3.0 release, messages larger than the buffer size is not transmitted. A ROS error message will be relayed telling whether the message was coming from, or going to, the device.

Float64

The Arduino does not support 64-bit float datatypes. The serialization/deserialization code generated by make_library will automatically convert 64-bit floats into 32-bit datatypes, however, it should be noted that a loss of precision may occur!

Strings

To conserve precious AVR memory, strings are not stored inside a message instance, instead an unsigned char * is stored. This has two impacts:

When publishing, you must assign store the string data elsewhere and set the pointer:

   1 std_msgs::String str_msg;
   2 unsigned char hello[13] = "hello world!";
   3 
   4 str_msg.data = hello;

When subscribing to a message containing a string datatype, the string itself will not be copied from the deserialization buffer. Therefore, while it will be valid during the callback function, it will disappear when any other message is deserialized. If you need to keep the value of the string outside the callback, you must manually copy the string elsewhere.

Arrays

Arrays have similar limitations to strings, however, since there is no easy way to find the termination of an array (analogous to the \0 found at the end of a string), we need to specify the size of the array. An extra variable is added to the class definition to accomplish this. For instance, the geometry_msgs/PoseArray is declared as:

Header header
geometry_msgs/Pose[] poses

On the Arduino, this will translate to a class:

   1 class PoseArray
   2 {
   3   Header header;
   4   int poses_length;
   5   Pose * poses;
   6 }

Therefore, to send an array message, we have to set the length and pointer. When deserializing, we cannot deserialize in-place like the string (since the bytes of the message are actually packed, unlike a string which is passed in plain form). Therefore, the deserialization function will automatically allocate enough storage using realloc(), attempting to reuse the memory location whenever possible and only expanding it when the new message received is larger than the largest previous message.

Some array types containing other array types will not deserialize correctly, as all elements of the child type will point to the same memory. This limitation may be addressed in the future.