Closed yanjunyangmonash closed 3 years ago
and the correct order should be
As I was trying to explain in the ROS Answers Q&A you link, there is no correct order -- or more precisely: there is no incorrect order.
Consumers of JointState
messages are expected to treat a message like a Python dict
, with dict[str, float]
as the type. Keys would be elements in the name
field, values the elements in position
. Lookups for joints would then be based on name, not on index.
Pseudo-code:
states = dict(zip(msg.name, msg.position))
right_joint2_pos = states['yumi_robr_joint_2']
I'm almost certain what you report is not because of any incorrect order, as the RobotModel display in RViz does not care about JointState
messages. It uses TF, which is broadcast by the robot_state_publisher
. And the RSP does what I wrote above (not exactly, but basically the same).
We're going to need more information in order to help you, as
the robot in RVIZ didn't match the pose of the robot shown in the robotstudio.
is not enough.
@gavanderhoorn I probably didn't make it clear in my first post. It's not about the name order, but the mapping from the name to position in the message. In position
, the joint is given in the order joint 1,2,7,3,4,5,6 and doesn't match the above name
.
From the pedant, the value for the right arm is
and because of the mismatch problem (I doubt), the robot in RIVZ looked like this
Besides, what else info do you need? Do I need to upload my moveit_planning_execution.launch
, ex3_controllers.yaml
and moveit_planning_execution.launch
? These are all files that I modified
Could you please run abb_robot_bringup_examples/launch/ex3_rws_and_egm_yumi_robot.launch with debug:=true
(and perhaps even with --screen
appended to the roslaunch
args)?
And of course make sure to update whatever parameters needed for your specific setup.
Then post the complete output here in a code block.
Edit: also: what is the Global Status error?
Edit 2: ah, I think I may know what's going wrong. You/we're confusing the joint value at index 3 (which is how the ABB controller internally maps things) to what we see/use on the ROS side.
As soon as we're working with JointState
s or URDFs, we don't care any more about what the controller does. The abb_robot_driver
node does the right thing, and converts whatever internal representation is used to a "normal one" (ie: the 7th joint is in the 7th location, as you'd expect).
joint_7
is the seventh joint in the kinematic chain of each arm, not the third one.
I believe @robberthofmanfm changed the order of joints in this commit in his fork, but that is most likely not needed -- or it should not be needed.
It would still be good to report the output of the .launch
file though, just so we can make sure.
The output below is running with ex3_rws_and_egm_yumi_robot.launch using the default parameters. There are mismatch problems in standardized_joints
.
Edit 2: ah, I think I may know what's going wrong. You/we're confusing the joint value at index 3 (which is how the ABB controller internally maps things) to what we see/use on the ROS side.
As soon as we're working with
JointState
s or URDFs, we don't care any more about what the controller does. Theabb_robot_driver
node does the right thing, and converts whatever internal representation is used to a "normal one" (ie: the 7th joint is in the 7th location, as you'd expect).
joint_7
is the seventh joint in the kinematic chain of each arm, not the third one.I believe @robberthofmanfm changed the order of joints in this commit in his fork, but that is most likely not needed -- or it should not be needed.
Indeed, the configuration in that commit did not work correctly. In the meantime, we modified the urdf itself because xacro
was producing very weird results. https://github.com/robberthofmanfm/yumi/blob/egm_modifications/yumi_description/urdf/yumi.urdf works for us - at least for representing the current joint states of the robot.
There are mismatch problems in
standardized_joints
.
what makes you conclude this?
As I mentioned in https://github.com/ros-industrial/abb_robot_driver/issues/15#issuecomment-788079236: on the ROS side we don't care about what the ABB controller internally does. The 7th joint
is the joint
in the 7th position of the kinematic chain for us.
For the ABB controller, that would be joint_6
. But again, that's not important "outside" the driver.
And I believe the driver does what it's supposed to:
standardized_joints {
original_name: "rob_R_7"
standardized_name: "yumi_robr_joint_3"
[..]
}
[..]
standardized_joints {
original_name: "rob_L_6"
standardized_name: "yumi_robl_joint_7"
rotating_move: true
lower_joint_bound: -3.9967999
upper_joint_bound: 3.9967999
}
notice how it's re-named things such that rob_R_7
is now the 3rd joint, while rob_R_6
is now the 7th joint.
As I wrote in https://github.com/ros-industrial/abb_robot_driver/issues/15#issuecomment-788079236: I believe the urdf/xacro you are using has been edited incorrectly by @robberthofmanfm: yumi_robl_joint_7
should link yumi_link_6_r
and yumi_link_7_r
, but instead yumi_robr_joint_6
does that.
@robberthofmanfm wrote:
we modified the urdf itself because
xacro
was producing very weird results. https://github.com/robberthofmanfm/yumi/blob/egm_modifications/yumi_description/urdf/yumi.urdf works for us - at least for representing the current joint states of the robot.
as long as you're aware plain URDF cannot be combined with any other URDFs.
It would be better to use xacro
.
@yanjunyangmonash: I'm going to close this issue assuming your problem has been solved -- or at least: we've identified the root cause.
It would seem @robberthofmanfm has already fixed his fork, so the incorrect order of joint
s in his .urdf
should no longer be a problem.
As I don't believe abb_robot_driver
does anything wrong, there is nothing for us to fix here.
Please feel free to keep commenting on the issue of course.
Hello @gavanderhoorn. I followed your tutorial about the use of the abb_robot_driver library in order to simulate the movement of a 6-joint robot (IRB2400) with Robotstudio. I followed all the installation points as well as applied a previous simulation of the abb_driver library with Robotstudio and moveit, which worked. I installed the ABB Server as found in http://wiki.ros.org/abb_driver/Tutorials/InstallServer in order to control the FlexPendant from RobotStudio.
Now, when I try to run your second example I get this error:
[FATAL] [1622463556.209463331]: Runtime error: 'Failed to call ROS service 'rws/get_robot_controller_description''
The controller IP is set as default and I think that it is not a problem about the connection between my ROS and the RobotStudio. Do you know where could be the problem?
Thank you very much.
@pferfer: please post new problems in new issues.
This is not a forum, but an issue tracker.
Hi @gavanderhoorn, I followed your discussion here to set up the moveit package. The URDF file I use is from this repository which follows the non-standard joints order. When I ran the
moveit_planning_execution.launch
, The robot in RVIZ didn't match the pose of the robot shown in the robotstudio.I guess the problem is from the published joint states, the name order in the message mismatch the order defined in URDF file.
and the correct order should be
I saw your reply to this question and understand there is no way to sort the joint order in the message. I also tried this method but it didn't work.
I'm wondering if there is a good way to keep the joint name match the published data for RVIZ to use?