rqt_plot error from incomplete joint state data
I am trying to plot joint efforts from a Baxter robot in rqt_plot. I can subscribe to robot/joint_states and get the data just fine. The format for the effort portion of the data is like this (from a rostopic echo):
effort: [0.0, 0.0, -1.66, 0.0, -0.872, -4.472, -0.084, -0.168, -0.008, -0.2, -19.056, 0.216, -26.844, -0.288, 0.076, 0.056, -20.48]
However, when I try to plot individual components of this effort in rqt_plot, effort[0] is the only one that works. If I add effort[1] or higher, I get the following error:
PlotWidget.update_plot(): error in rosplot: [/robot/joint_states/effort[1]] index error for: header: , seq: 122200, stamp: , secs: 1517944540, nsecs: 889999872, frame_id: '', name: [r_gripper_l_finger_joint], position: [0.0], velocity: [0.0], effort: [0.0]
My best theory for the cause is that sometimes the effort field has just one component, which seems to be what the error message above is complaining about. I don't know why this occurs, but is it possible to make rqt_plot ignore the occasional missing data and just display what shows up? Alternatively, is there a built in way to prune out this missing data before I pass it along?
I am running the latest versions of rqt_plot, Ros Kinetic, Ubuntu 16,
On the real Baxter (not the simulator), messages published on the
/robot/joint_statestopic sometimes contain the arm data, and sometimes the gripper data. As a result there are definitely messages published with varying lengths for these arrays. One easy workaround is....... to use the
joint_state_publisherwith it'ssource_listprivate parameter. For examplerosrun joint_state_publisher joint_state_publisher _source_list:="['/robot/joint_states']"will publish a new topic "/joint_states" that always contains complete joint information. Hope that helps.I am having a similar issue with several servo motors publishing in array format. Did you end up resolving this?
I have not really resolved it in away that would be generally useful. I believe jervisschultz's reasoning about the cause of the issue was correct, but I did not get his fix to work correctly. I ended up using a workaround that was particular to my application.