IFL-CAMP / iiwa_stack

ROS integration for the KUKA LBR IIWA R800/R820 (7/14 Kg).
Other
337 stars 249 forks source link

Using iiwa_moveit results in a jerky motion #284

Closed daniellehot closed 1 year ago

daniellehot commented 2 years ago

Hello. I configured the connection between the Sunrise workbench and the ROS machine according to the wiki and managed to connect with the robot without any issues. After connecting with the robot, I can echo the available topics just fine. However, if I try to move the robot using MoveIt, the robot moves in a jerky fashion. The MoveIt configuration files are unchanged, and MoveIt is launched using roslaunch iiwa_moveit moveit_planning_execution.launch.

Interestingly, the jerkiness gets worse with lower velocity and acceleration scaling values. Furthermore, the jerkiness is more obvious for short trajectories. I tried multiple OMPL planners, but the result was the same. Currently, I am using RViZ to set goals for the robot.

Has anyone else experienced this? If so, what can I do to fix this? I am using ROS Melodic, Ubuntu 18.04.

daeunSong commented 2 years ago

Hi,

I am having the same issue with ROS Melodic, Ubuntu 18.04, and Sunrise OS v1.11. The result is the same whether I set goals through Rviz or commands (code).

I could not figure out the solution, yet. For a temporal solution, instead of using Moveit!, I decided to use messages/services of iiwa_stack. And this works fine with clean motions.

After some inspection, I am expecting this might be related to the network issue. Could be also related to #282. I am expecting that the robot is having a jerky motion as it fails to reach the real-time update rate of the command PC. I'd love to hear the opinions of others.

Thanks!

Daeun

ambitious-octopus commented 1 year ago

I have the same problem. Just a friendly ping, Have you found a solution?

In my case the problem is present both in the JointPosition and JointPositionVelocity Hardware Interface. Just to give an idea of the problem, this is what i get by registering messsages from /iiwa/status/JointPositionVelocity and /iiwa/command/JointPositionVelocity. The robot seems to lag behind the command.

image

ChristoXIV commented 1 year ago

Hello,

I am working on ROS Noetic (Ubuntu 20.04 LTS) and a Sunrise OS 1.14. I am facing the same problem as described before.

When I publish directly the final JointPosition into the /iiwa/JointPosition topics the movement is smooth while when Moveit plan the path and publishes it into the same topic (or if I publish many waypoints), the movement of the robot is very jerky. I already tried to change the publish rate and tried to publish different positions to the /iiwa/JointPosition topics with a c++ program (with different publish rates), the problem is the same. If the rate is to low, the kuka moves to the next waypoint and waits for the next command, if its to high I have the jerky movement.

As @daniellehot, the jerkiness increase for short movements.

The problem doesn't seem to be from the time synchronization too.

I also tried to publish different positions to the /iiwa/JointPosition topics with a c++ program (with different publish rates), the problem is the same.

Can be from the iiwa_ros_java ? Everything works fine with the simulated robot in gazebo.

This iiwa_stack is using the Servoing Package from Kuka. Can this problem be avoided with the iiwa stack from EPFL which is using the FRI package ?

If someone has a robot which move smooth with Moveit, has updates or know how to solve this problem I would love to discuss with.

Thanks,

daniellehot commented 1 year ago

It has been some time since I worked on this, and I apologize for not responding to the previous comments, but if I remember correctly, we ultimately resorted to using iiwa_stack services and actions to generate and execute robot trajectory. We used move it to generate trajectory waypoints to prevent collisions with the environment. This method is not 100% reliable, as the trajectory between waypoints is not guaranteed to be collision-free (the robot's controller was not aware of the cell setup). However, such collisions were quite rare for our use and mostly the result of us enforcing a certain goal orientation of the end-effector.

Let me know if you have more questions, but I plan to close this issue soon.