Moveit examples become unstable/jerky after running for a bit

[cpr-fer]

I am not sure where exactly the issue lies, but after running through one tray in the vacuum example joint 3 on my ReBeL starts to jump before nearly each movement. To make sure that its not a hardware issue maybe test it on another ReBeL. Check if the same occurs in the non-vacuum pick and place example or manually using moveit.

[cpr-fer]

So I did some testing with moving the robot manually at different velocity and acceleration limits. While with less limitation the motions do become less smooth, I could not reproduce the strong jerkyness seen in the vacuum example. Also limiting the velocity and acceleration to 50% in the vacuum example improved the performance somewhat, but only lessened the jerks.

To narrow the bug down:

• [x] Test the vacuum example with a different ReBeL
• [x] Limit the acceleration in the vacuum example further to see if it can be completly avoided
• [x] Check CAN timings/jitter again, maybe it gets worse after running for a while
• [x] Make sure again that no random enable motors or reset errors calls are happening anywhere
• [x] Try delaying the planning call a bit, as maybe the robot is not at a stillstand and thus tries to start a motion from a wrong starting pose
• [x] Try a real time kernel

[cpr-fer]

It seems like the occurance of the problem is time dependent instead of position/trajectory dependent as repeating previously jerk-free motions will also cause issues after a while and reversing the pick and place pattern does not cause the issues to appear sooner. Still it might be a good idea to enable the jump threshold in the cartesian motion planning.

[cpr-fer]

Regarding the jitter, this is the result of measuring the time between sending the CAN commands. While it certainly can and should be improved, it should still be inside the tolerance of the motor controller boards. Also the jitter would have to be caused by the moveit trajectory planning, which might be resolved by using a RT Kernel, something that is on the TODO list anyways

Furthermore, no automatic error resets occured during the program, and since the rebel in this case was powered with a battery it should not be an insufficient power source.

[cpr-fer]

Testing showed that some delay (I tested with 500ms, I hope something around 10ms is sufficient) before starting the linear motion planing seems to resolve the issue. Meanwhile I am compiling the RT Preempt kernel and prepared a python script to compare the jitter behaviour with the standard kernel.

Afterwards I will look further into how much delaying is required or if I still can reproduce the issue.

[cpr-fer]

Comparing the jitter between 5.19 Preempt and 5.22 shows no big improvement, in the contrary the jitter seems to have worsened a bit. Still, as ros2_control recommends to use a RT-PREEMPT kernel I will continue testing with it and add a short install guide to the irc_ros_hardware package. (Edit: Addressed in #45)

candumps used: candump_no_rt.txt candump_rt.txt

Script used: compare_jitter_candumps.py.txt

[cpr-fer]

Turns out the issue was related to #8, solved in the following PR