https://github.com/DavidPL1/assembly_example/issues/3 had me perform some more in detail analysis of time discrepancies. I managed to fix the issue in 24a61540a7e9dec1f84d45169550316a80fbd614, but as mentioned in the commit message, I really don't like this solution.
In more detail, the error would manifest like this:
* step 0:
- internal time is 0
- ros time is 0
- no issues
- On end, time is incremented to 0.001 and is set by ros::Time::setNow
- additionally the clock publisher publishes the new time
- ros time is now at 0.001, but the clock message delivery is pending
* step 1:
- internal time is 0.001
- (intra-node) ros time is 0.001
- no issues
- On end, time is incremented to 0.002 and is set by ros::Time::setNow
- additionally the clock publisher publishes the new time (not sure what exactly happens within the publisher)
.
.
.
* step 10:
- internal time is 0.010
- (intra-node) ros time starts at 0.010, but along the way gets "updated" to 0.001
- mujoco_ros_control notices ros time is earlier than last time (was 0.009) and performs a reset
- Pending MoveIt goals get preempted
- time gets incremented to 0.011
This repeats occasionally
Interestingly, this only happened sometimes but every time with a notable offset of at least 3 steps, sometimes more than 10.
I don't like that intra-node step speed is limited by how slow ros updates its time based on message publication (even with the intra-node acceleration of using the shared pointer of a message).
Removing the publish and using the setNow call makes everything faster, but then external ros components will be stuck at time 0, expecting messages on /clock.
@rhaschke do you have any idea if and how we could work around this?
https://github.com/DavidPL1/assembly_example/issues/3 had me perform some more in detail analysis of time discrepancies. I managed to fix the issue in 24a61540a7e9dec1f84d45169550316a80fbd614, but as mentioned in the commit message, I really don't like this solution.
In more detail, the error would manifest like this:
Interestingly, this only happened sometimes but every time with a notable offset of at least 3 steps, sometimes more than 10.
I don't like that intra-node step speed is limited by how slow ros updates its time based on message publication (even with the intra-node acceleration of using the shared pointer of a message). Removing the publish and using the setNow call makes everything faster, but then external ros components will be stuck at time 0, expecting messages on /clock.
@rhaschke do you have any idea if and how we could work around this?