CLOCK_REALTIME vs CLOCK_MONOTONIC

[carlosjoserg]

In #46 , @miguelprada raised a comment about what would be the best thing to do when updating the controllers.

In an email discussion with him, the suggestion kind of makes sense, which is how it is done currently in the ur_modern_driver and in the ros_control_boilerplate template. In both of them, they pass ros::Time::now() (computed with CLOCK_REALTIME) and the elapsed time computed with CLOCK_MONOTONIC, so the elapsed time is always positive, to the controller_manager instance. The reasoning is to keep the controllers in sync with the rest of the ROS system.

What makes me open the issue is because I remember not having any problems with the current setup, where now and elapsed time are computed using CLOCK_MONOTONIC, while using the joint_trajectory_controller mostly, but it might be that I never really took it to any extreme cases or so.

Does anybody have an example where this leads to a non-expected behavior?

[gavanderhoorn]

Does anybody have an example where this leads to a non-expected behavior?

not with the pkgs in this repository, but with another driver that did not take the CLOCK_REALTIME, CLOCK_MONOTONIC difference into account.

As CLOCK_MONOTONIC does not necessarily correspond to Wall time, it is perfectly valid for it to start counting at 0 at system start. Progress of time follows Wall time (ie: seconds are still seconds), except for when Wall time is adjusted in any way.

On one system where I used that driver -- before patching it so that it used CLOCK_REALTIME for all publications and CLOCK_MONOTONIC for the controller updates -- JointState publications would get timestamps that were way in the past (depending on when you started nodes, they would have something like 500 seconds fi). As fi robot_state_publisher takes these timestamps into account, things didn't work very well, to say the least.

TF broadcasts with timestamps in the 1970s result in the same problem.

[carlosjoserg]

In the 1970s haha.. thanks for your input @gavanderhoorn

Ok, I get that... so as far as I understand, the time is only used to stamp the state messages of controllers when publishing to ROS.

Tweaking my question: Why are we passing the point in time in the controller manager update call then? I mean, wouldn't it be better for each controller to stamp the messages they are publishing using their own time at the moment of computing/publishing the command/state, like for instance using ros::Time::now() in here, here or even here and so on for any ros-controller?

Is there any example where ros::Time::now() is used to compute something in any controller?