Use MONOTONIC_RAW instead of MONOTONIC for steady clock

[saikishor]

I see that @clalancette recently switched to MONOTONIC from MONOTONIC_RAW in #357 in order to have it similar to std::chrono::steady_clock representation.

I've also seen the discussion in the issue: #43. However, I think that we should align more towards the MONOTONIC_RAW because if I want to use the steady_clock provided by rcutils for the ros2_control applications, I want it to be slew-free rather than being affected by any internal clock change. For instance, Industrial grade motor control boards with EtherCAT protocol might generate some discontinuities in the velocities causing strange noises on the robot.

It would be great to rethink again on this part to use MONOTONIC_RAW instead of MONOTONIC (or) if we can add new clock type something like RCL_STEADY_SLEWFREE_TIME or something like that to have both implementations?

Thank you

[fujitatomoya]

IMO #357 aligns with std::chrono to keep it similar with std::chrono::steady_clock::now() for RCL_STEADY_TIME.

Industrial grade motor control boards with EtherCAT protocol might generate some discontinuities in the velocities causing strange noises on the robot.

this also sounds reasonable. sometimes we need to have pure hardware timer values without any adjustments by kernel, for example precise measurements.

i think these are different use cases depending on the application requirements. maybe we need to have a new clock type RCL_STEADY_RAW_TIME.

[saikishor]

I understand that #357 aligns with the std::chrono. Indeed, it makes sense. It would be really great if we have a new clock type as you mentioned, this will be really useful for most robotics control applications.

Thank you

[alsora]

Based on the discussion when this change was introduced, we think that we shouldn't revert it.
Adding a new type should allow to handle this use-case without affecting the existing users.

[saikishor]

Based on the discussion when this change was introduced, we think that we shouldn't revert it.
Adding a new type should allow to handle this use-case without affecting the existing users.

Hello @alsora

Thank you for responding. When I find sometime, I'll try to make the changes with the new type and open a PR.