Plotjuggler 'Missing ROSType in library' on ros1 node published messages

[lucasw]

Other nodes get the messages fine, but plotjuggler is trying to get type information in a way roslibrust nodes don't provide?

https://github.com/facontidavide/PlotJuggler/blob/main/plotjuggler_plugins/ParserROS/rosx_introspection/src/ros_message.cpp#L206

What I do is click `Streaming | ROS Topic Subscriber | Start' within plotjuggler, select the topic and press OK, and then get the error:

I can start up a roscpp/rospy node publishing to the same topic, get plotjuggler plotting it, then switch in the rust node and it'll still plot fine (presumably having already cached the type information it wanted).

This happened with an earlier version of roslibrust (883057f) and then I just now updated to the latest in master with same result.

[Carter12s]

Lucas thank you!!! Seriously, awesome to have an active user, and really appreciate these issues. I'm just using this crate in my own little world and its awesome to have someone catching these things.

I haven't used plot juggler before, but I'm aware of it, let me dig in and see if this will be an easy fix.

[Carter12s]

Okay after doing some digging (note, I can't actually run PlotJuggler at the moment so debugging from code only).

Plot Juggler ultimately parses the message_definition= field of the TCPROS connection header (which we should be providing) via RosIntrospection::ShapeShifter here.

So my first guess / assumption is that RosIntrospection::ShapeShifter isn't giving them the message definition from us.

Wait this is actually more complicated, and requires nested message types...

So PlotJuggler subscribes to topic "/a" with message type A that contains a field with type B. PlotJuggler now has to somehow access the text of the schema for B (not contained in A's message definition, good design ROS). So where the heck is it going to get that definition?

[Carter12s]

Well crap... turns out I was wrong... ROS does have the message_definition field in the connection header contain the fully expanded definition...

Apparently that field is supposed to contain the full output of gendeps --cat example here:
https://wiki.ros.org/roslib/gentools

Which is not what our current message generation is doing 💩 100% a bug. Will be somewhat annoying to fix.

[Carter12s]

For my own reference when I dig into implementation, gendeps concatenation is dead simple:

https://github.com/strawlab/ros/blob/c3a8785f9d9551cc05cd74000c6536e2244bb1b1/core/roslib/src/roslib/gentools.py#L245

[Carter12s]

@lucasw Okay I think I have a fix up on a branch here:
#174

It is certainly closer to the actually ROS specification, but I haven't been able to directly test with PlotJuggler yet.