Failed to fetch current robot state - Webots - Moveit2
After reading all the relevant questions, decided to ask a new one, since none seems to solve my problem.
I have a UR3e robot in webots simulation. For it, I used the official UR ROS2 drivers and the webotsros2 package. I integrated moveit, based on this file: https://github.com/cyberbotics/webotsros2/blob/master/webotsros2universalrobot/launch/moveitdemo_launch.py and ofcourse after changing the corresponding files (srdf etc).
I created a moveit action server (C++)/client (Python) to move the robot on x, y, z coordinates. Action server seems to work fine. I tried it with the official urcontrol.launch.py and urmoveit.launch.py launch files (located here: https://github.com/UniversalRobots/Universal_Robots_ROS2_Driver ) and it works properly.
However, with the Webots simulation, when I send a goal to the action server, I get the error:
Listening to joint states on topic 'joint_states'
Didn't received robot state (joint angles) with recent timestamp within 1.000000 seconds.
Check clock synchronization if your are running ROS across multiple machines!
Failed to fetch current robot state
and the action server stops.
I checked the joint_states topic and they are published (without namespace) normally:
header:
stamp:
sec: 9
nanosec: 32000000
frame_id: ''
name:
- elbow_joint
- shoulder_lift_joint
- shoulder_pan_joint
- wrist_1_joint
- wrist_2_joint
- wrist_3_joint
position:
- 5.711517203712898e-05
- 0.00018049877555955765
- -1.3669061950766192e-11
- -6.65641146595404e-10
- 2.361802064734121e-10
- -2.855993233002314e-10
velocity:
- .nan
- .nan
- .nan
- .nan
- .nan
- .nan
effort:
- .nan
- .nan
- .nan
- .nan
- .nan
- .nan
One thought was that moveit cannot process the joint states when the msg includes nan. Could that be the problem? I tried to remove the nans by adding limits in the joints ("haseffortlimits: true" in the parameters of the robot description of UR), but I still get nan. How can I get rid of the nans?
If not due to the nans, could someone point out where shall I search for the error?
Asked by AlexandrosNic on 2022-09-15 07:01:18 UTC
Answers
It was a bit silly on my side that I did not notice this, but I may solved by just adding the use_sim_time: True parameter in the node
Asked by AlexandrosNic on 2022-09-16 05:36:33 UTC
Comments