ROS Arduino message type restrictions?
I'm getting a 'mismatched protocol' error when publishing a message (UInt8) from an Arduino to ROS:
Mismatched protocol version in packet: lost sync or rosserial_python is from different ros release than the rosserial client
It should be noted that the message still works, I'm just a bit concerned about the error message and would like to learn more about it.
There's a lot of threads around ROS answers stating that people are getting the error from rosserial because their message of choice was too large (message types such as IMU, etc.)
I took a look at the rosserial limitations and saw that for my particular board (ATMEGA328) that the buffer size is 280 bytes. Shouldn't the Uint8 type in theory only be 8 bytes, or is there something I'm missing?
Here are all of the ROS components from my program:
#include <ros.h>
#include <std_msgs/UInt8.h>
ros::NodeHandle nh;
std_msgs::UInt8 ROS_int;
ros::Publisher state("Device_state", &ROS_int);
void setup(){
nh.initNode();
nh.advertise(state);
}
void loop(){
ROS_int.data = CurrentState;
state.publish( &ROS_int );
nh.spinOnce();
Is it perhaps that I'm using some outdated syntax on something?
Edit #1: @ahendrix I can see the messages on the ROS side, I haven't checked the frequency... but the error could be related to that. Here's an example screenshot from when I'm echoing the value vs. what rosserial is telling me. It does seem inconsistent. Does it have something to do with my setting perhaps? I may just try flashing it as Wolf suggests.
@Wolf I'm running Hydro on the laptop, and the ros_lib on the arduino is a few months old? perhaps. I remember in September or something I initially downloaded that, I'll give it a try and see if that fixes.
The UInt8 should be 8 bits or 1 byte. Can you see published messages on the ROS side? If they're at a constant frequency, do you miss a message every time you see an error?
Probably stupid question: did you recently update the code on your device? I just a couple of sconds ago happend to have the same issue due to a ROS update; regenerating arduino ros_lib and flashing the device with code compiled against new ros_lib fixed it for me :)