webots_ros/Float64Stamped from webots causes 'Bad field when parsing field: \n' about plotjuggler HOT 2 CLOSED

Examining the bag with the messages that cause the errors (bad_field_2024-03-14-22-34-14.bag.zip), I found this:

$ xxd bad_field_2024-03-14-22-34-14.bag | grep '\\n' -C 3
000010d0: 3532 3463 6331 3634 6536 3531 0000 006d  524cc164e651...m
000010e0: 6573 7361 6765 5f64 6566 696e 6974 696f  essage_definitio
000010f0: 6e3d 4865 6164 6572 2068 6561 6465 720a  n=Header header.
00001100: 666c 6f61 7436 3420 6461 7461 0a5c 6e0a  float64 data.\n.
00001110: 2700 0000 746f 7069 633d 2f77 6562 6f74  '...topic=/webot
00001120: 732f 6175 746f 6d6f 6269 6c65 2f73 7465  s/automobile/ste
00001130: 6572 696e 675f 616e 676c 651e 0000 0074  ering_angle....t

Note the literal \n characters (not an ASCII newline, but literally the characters \ [5c] and n [6e]) in the message definition.

I created a bag with a webots_ros/Float64Stamped message that works fine in PlotJuggler
(good.bag.zip) using rostopic:

$ rostopic pub /test webots_ros/Float64Stamped "header:
  seq: 0
  stamp:
    secs: 0
    nsecs: 0
  frame_id: ''
data: 0.0" 

When I examined that bag, the message definition did not include the \n characters:

$ xxd good.bag | grep 'float64' -C 3
000014d0: 6530 3731 6435 3234 6363 3136 3465 3635  e071d524cc164e65
000014e0: bc02 0000 6d65 7373 6167 655f 6465 6669  ....message_defi
000014f0: 6e69 7469 6f6e 3d48 6561 6465 7220 6865  nition=Header he
00001500: 6164 6572 0a66 6c6f 6174 3634 2064 6174  ader.float64 dat
00001510: 610a 0a3d 3d3d 3d3d 3d3d 3d3d 3d3d 3d3d  a..=============
00001520: 3d3d 3d3d 3d3d 3d3d 3d3d 3d3d 3d3d 3d3d  ================
00001530: 3d3d 3d3d 3d3d 3d3d 3d3d 3d3d 3d3d 3d3d  ================

from plotjuggler.

This is the fault of the webots custom msg-to-header generator, it's a bad message definition. Foxglove also fails to load it. So closing this here.

https://github.com/cyberbotics/webots/blob/master/projects/default/controllers/ros/headersGenerator.py

This is what the webots source builds and what the snap installed webots has (this definition gets stored in the bag and parsed and fails by plotjuggler and foxglove):

template<class ContainerAllocator>
struct Definition< ::webots_ros::Float64Stamped_<ContainerAllocator> >
{
  static const char* value()
  {
    return "Header header\n\
float64 data\n\\n\
\n\
";
  }

The same header built properly by ros (which is what rostopic echo is using):

template<class ContainerAllocator>
struct Definition< ::webots_ros::Float64Stamped_<ContainerAllocator> >
{
  static const char* value()
  {
    return "Header header\n"
"float64 data\n"
"\n"
"================================================================================\n"
"MSG: std_msgs/Header\n"
"# Standard metadata for higher-level stamped data types.\n"
"# This is generally used to communicate timestamped data \n"
"# in a particular coordinate frame.\n"
"# \n"
"# sequence ID: consecutively increasing ID \n"
"uint32 seq\n"
"#Two-integer timestamp that is expressed as:\n"
"# * stamp.sec: seconds (stamp_secs) since epoch (in Python the variable is called 'secs')\n"
"# * stamp.nsec: nanoseconds since stamp_secs (in Python the variable is called 'nsecs')\n"
"# time-handling sugar is provided by the client library\n"
"time stamp\n"
"#Frame this data is associated with\n"
"string frame_id\n"
;
  }

https://github.com/cyberbotics/webots/blob/master/projects/default/controllers/ros/headersGenerator.py#L222 is responsible for the \\n but even with that fixed there's still a bunch of message definition missing, and it still doesn't load in plotjuggler- it needs to have std_msgs/Header embedded there?

Probably the easiest thing to do is to modify webots to not generate the header itself and use the the ros built one instead (it uses geometry_msgs/PointStamped and maybe a few others fine).

from plotjuggler.