universal robot publishes joint_states in wrong order

asked 2020-07-03 10:05:56 -0500

dimitri
54 ●11 ●15 ●18

updated 2020-07-03 12:29:49 -0500

I am simulating a UR3e with universal_robot in gazebo. I changed in the file universal_robot/ur_gazebo/arm_controller_ur3.yaml the arm_controller to effort_controllers/JointTrajectoryController and the joint_group_position_controller to effort_controllers/JointGroupPositionController so that the joint torques are published in the rostopic /joint_states (see here). When I rostopic echo /joint_states then I get messages like this:

header: 
  seq: 1417
  stamp: 
    secs: 28
    nsecs: 436000000
  frame_id: ''
name: [elbow_joint, shoulder_lift_joint, shoulder_pan_joint, wrist_1_joint, wrist_2_joint,
  wrist_3_joint]
position: [-1.0557658919163337, 1.0575053468152493, -0.02113558608100874, -1.822583166115745, -0.10412660222769787, 1.801825136192468]
velocity: [0.06788605457138291, -0.03376755104159887, -0.0035151515981181034, 0.0949115070348448, 1.8808924155717315, -0.01988477359094043]
effort: [9.819053646461384, 21.306304838637402, 6.095654368698433, 0.3193635097687775, -54.0, 2.8906661096243624]

But when you look at the order of the joint names, you can see that they are in the wrong order (elbow_joint an dshoulder_pan_joint should be switched). I am not sure if just the names are switched or the data as well. Can somebody tell me where the publisher for this is defined so I can check?

edit retag flag offensive close merge delete

Comments

I am simulating a UR3e in gazebo. I changed the arm_controller to effort_controllers/JointTrajectoryController and the joint_group_position_controller to effort_controllers/JointGroupPositionController so that the joint torques are published in the rostopic /joint_states.

it's probably completely clear to you, but we have no idea which packages you are using, or what you are referring to with arm_controller and joint_group_position_controller.

Please include links to any packages you are using, and links to specific files you are referring to in your future questions, as without such information, it is very difficult to help you.

gvdhoorn ( 2020-07-03 11:47:05 -0500 )edit

Please also note your question is a duplicate of #q282097, #q221560 and somewhat #q351105.

gvdhoorn ( 2020-07-03 11:49:15 -0500 )edit

Please include links to any packages you are using, and links to specific files you are referring to

Sorry, was a bit in a rush. Edited it.

dimitri ( 2020-07-03 12:31:14 -0500 )edit

Please also note your question is a duplicate of #q282097, #q221560 and somewhat #q351105.

Weird these didn't show up in my search. Thanks for the hint

dimitri ( 2020-07-03 12:37:39 -0500 )edit

Hi ! I have the exact same issue. It took me some time to find the issue. Im using, UR5 + gazebo 9 + ROS Melodic. I'm using effort_controllers/JointEffortController for every joint. Then I use KDL::ChainIdSolver_RNE::CartToJnt to calculate the joint torque and then publishe these torques on my effort_controllers/JointEffortController topics.

But I see the /joint_states name are in not the same order as it should be for me.

`Joint_State order -> elbow_joint, shoulder_lift_joint, shoulder_pan_joint, wrist_1_joint, wrist_2_joint, wrist_3_joint.` 

Desired join order -> shoulder_pan_joint, shoulder_lift_joint, elbow_joint, wrist_1_joint, wrist_2_joint, wrist_3_joint

I used following remap to read the /joint_states in my subscriber callback,

int map_joint_states[] = {2, 1, 0, 3, 4, 5}

void my_callback(const sensor_msgs::JointState::ConstPtr& msg)
{ 
for (int i = 0; i < N_JOINTS; i++){
 jointPosCurrent(i) = msg->position[map_joint_state

amjack ( 2020-07-30 03:49:25 -0500 )edit

add a comment

answered 2020-07-03 11:45:55 -0500

gvdhoorn
86574 ●283 ●1432 ●1054 http://cor.tudelft.nl/

updated 2020-07-03 11:47:37 -0500

There is no "wrong order" here.

The ros_controllers/JointStateController retrieves joint names and handles from a C++ hash map, which sorts alpabetically.

I am not sure if just the names are switched or the data as well.

Everything is correct.

This code has been in use for the past 6 years at least. I'm going to make an assumption here (which is not always the best idea), but if there would be such a problem as you hint at (ie: names not matching with indices in the other vectors), we would probably have seen countless of bug reports about it.

Can somebody tell me where the publisher for this is defined so I can check?

You may find the code for the JointStateController here: ros-controls/ros_controllers/joint_state_controller/src/joint_state_controller.cpp.

Comments

Ok. I just assumed that ordering it as they appear in the robot would make more sense and thought maybe it was something that recently changed. But in that case it works. So when I use it with for example the kdl library where the joints are used in order as they appear in the robot I would just need to rearrange the data when i get it with a subscriber, I guess?

dimitri ( 2020-07-03 12:08:33 -0500 )edit

I just assumed that ordering it as they appear in the robot would make more sense

If you think about it: why exactly would that make more sense?

I would just need to rearrange the data when i get it with a subscriber, I guess?

that would not be "a guess", but what would be required of you, as a subscriber.

As there is no order which would work for everyone, processing your incoming data in such a way you can work with it is always required.

All consumers must check incoming data and re-arrange/pre-process it such that you can work with it.

That's not unique to this particular case, but always a requirement with ROS messages.

gvdhoorn ( 2020-07-03 12:12:46 -0500 )edit

If you think about it: why exactly would that make more sense?

Because it has a logic behind it. So I could imagine it being ordered from the top to bottom or bottom to top (for chains, for trees there are obviously more logical possibilities like all leaves first and so on). But ordering it alphabetically has nothing to do with how the robot looks like or how it works (unless the names have like numbers in the beginning). But maybe that's to philosophical.

All consumers must check incoming data and re-arrange/pre-process it such that you can work with it.

Yes of course. That's why I asked the question. Maybe my formulation was weird.

dimitri ( 2020-07-03 12:36:17 -0500 )edit

for chains, for trees there are obviously more logical possibilities like all leaves first and so on

So here you already describe a first corner-case yourself.

There are many more.

The easiest way around all of that is to choose an order which always works, which is alphabetical and then require consumers to re-order as they need it.

gvdhoorn ( 2020-07-03 14:25:49 -0500 )edit

add a comment

universal robot publishes joint_states in wrong order

Comments

1 Answer

Comments

Question Tools

Stats

Related questions

universal robot publishes joint_states in wrong order edit

Comments

1 Answer

Comments

Question Tools

Stats

Related questions

universal robot publishes joint_states in wrong order