Native support for sensor_msgs/JointState joint names in message path input

[v4hn]

A major hurdle for using this with articulated robots is the difficulty to add multiple joint state plots together.
This has to be done one after the other and is tedious for 6+ dof arms, especially when you want to have separate plots for position, velocity and acceleration.

Ideally you would select multiple joints by name (not by index) and drag them into the plot together.
PlotJuggler managed to simplify this use a lot and it's worth going for a similar approach in my opinion.

[amacneil]

Thanks for the feedback!

What exactly do you mean by selecting joints by index? Are you basically looking for something like this (selecting multiple topics from a picker and dragging them onto the plot)?

[v4hn]

Are you basically looking for something like [this](https://plotjuggler.io/assets/videos/video01.mp4) (selecting multiple topics from a picker and dragging them onto the plot)?

Multi-selection from multiple *topics* (as in the video) would be a bonus, but dragging multiple *fields* from *one* message/topic would go the better part of the way already.

What exactly do you mean by selecting joints by index?

[The `sensor_msgs/JointState` message](http://docs.ros.org/en/melodic/api/sensor_msgs/html/msg/JointState.html) has its fields split up by type, so in order to access the position for `"elbow_joint"` you have to look up the index of the corresponding string in the `name` field and access the same index in the `position` field. Technically, this is a special case of message layout. But it's such an important, omnipresent special case (*everything* in mobile manipulation uses the topic) that it still simplifies workflows a lot to handle it. So ideally the viewer collects name entries in `JointState` messages on the topic and enables the user to add the position/velocity/effort values for these *named joints*, instead of accessing `position[3]` (hoping that it's the correct index and the joint is present in *all* messages on the topic). I just wanted to provide some feedback after looking at it for 20 minutes together with a colleague today and rejecting it for now.

[jtbandes]

There's a trick with the Raw Messages panel that lets you click to open/add plots for fields of a single topic. I think it will help out with the first issue you described:

Screen.Recording.2021-06-15.at.8.17.29.AM.mov

[v4hn]

There's a trick with the Raw Messages panel that lets you click to open/add plots for fields of a single topic. I think it will help out with the first issue you described:

Yes, that helps with individual fields in one message. From the video I'm not sure whether this works with entries in dynamic sized lists as well? Also, of course it doesn't help with the more problematic part of this issue though. :-)

[jtbandes]

It will work for entries in dynamically-sized lists, by including the index in the message path that it adds to the plot. But I do see how special handling for JointState could help here. Any additional examples you can share of how PlotJuggler (or other tools) handles this well would be useful to us!

[defunctzombie]

@v4hn Here is an example using variables for the joint indexes. These global variables are then used in the plot panel to so your plot legend is clear which joint is shown.

Screen.Recording.2021-06-16.at.7.46.14.AM.mov

[v4hn]

Thank you. That helps with the legend but does not solve some major issues (you might argue about major, but after all data introspection is about usability): - you still have to know the correct value to define the variable in the first place - you have to type the full variable name when adding the plot line (autocompleting all variable names does not solve this, because not all variables would make sense or would be feasible) - not every message you receive on the `joint_states` topic must contain each joint (or even joints in the same order). Specifically, this is a common way of setting up systems with more than one driver To fully address these, you would have to cache the `name` fields of `JointState` messages and should make them valid (autocompleting) indices in the position/velocity/effort vectors where they would represent their own index in the name field of the respective message.

[amacneil]

It sounds like there are a couple of different requests here. Would it be accurate to rename this one to "Native support for sensor_msgs/JointState joint names in plot panel"? I think that is a nice discreet feature request.

Perhaps it is worth opening a separate discussion for how we can make it easier to drag fields into the plot panel. If you are able to share your own video outlining the specific UX you like in plotjuggler, that would be appreciated!

[jtbandes]

Rather than "in plot panel", I think we would want it to be supported by the message path syntax so it can be used in other panels as well.

[v4hn]

Indeed, as this interface basically solves the problem to add multiple plots at the same time, the remaining issues are specific to JointState.

[jtbandes]

For reference, the relevant PlotJuggler code is in a plugin here: https://github.com/PlotJuggler/plotjuggler-ros-plugins/tree/c6ca65667c573c55a93e302850c9c7d94848db2e/plugins/ros1_parsers

[github-actions]

This issue is being marked as stale because there has been no activity for 180 days. Please add a comment to keep it open.

[amacneil]

From the thread above I'm a little unclear whether there is an outstanding feature request, or whether the "create plot from raw message" functionality is sufficient.

[v4hn]

I believe I already replied with a number of clarifications here.
My main feature request is still that there is no way to click somewhere and directly plot "acceleration of shoulder_pan_joint" without having to refer to the number in the array. This is especially important because, by message design, the joint is allowed to change its position in the lists and it's a relatively common case to see messages on the topic that do not include the joint at all. When two independent drivers publish joint values each one will only publish messages for its own joints.

[amacneil]

I see, thanks for the clarification.

[amacneil]

@v4hn do you happen to have a video/screen recording of how this works with JointState in PlotJuggler?

[v4hn]

I'm not interested in this project at this time and don't have time for overhead at the moment, sorry. plotjuggler is packaged in ROS distributions, so you can easily check yourself. as you try to implement a better alternative to existing solutions, I would expect you check existing solutions (for me mostly rviz, plotjuggler, rqt_joint_trajectory_plot) yourself anyway to figure out how things work there and what you can do better...

[github-actions]

This issue has been marked as stale because there has been no activity in the past 6 months. Please add a comment to keep it open.