universal robot publishes joint_states in wrong order

Question

Hi

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?

---

Originally posted by dimitri on ROS Answers with karma: 54 on 2020-07-03

Post score: 0

---

Original comments

Comment by gvdhoorn on 2020-07-03:\

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.

Comment by gvdhoorn on 2020-07-03:
Please also note your question is a duplicate of #q282097, #q221560 and somewhat #q351105.

Comment by dimitri on 2020-07-03:\

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.

Comment by dimitri on 2020-07-03:\

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

Comment by amjack on 2020-07-30:
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

Answer 1

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.

---

Originally posted by gvdhoorn with karma: 86574 on 2020-07-03

This answer was ACCEPTED on the original site

Post score: 1

---

Original comments

Comment by dimitri on 2020-07-03:
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?

Comment by gvdhoorn on 2020-07-03:\

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.

Comment by dimitri on 2020-07-03:\

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.

Comment by gvdhoorn on 2020-07-03:\

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.