Repeating or one-shot timer registered with the executor.
Timers fire during spin_once() when their period has elapsed. The callback is a C function pointer with a user context.
Usage:
Definition client.hpp:129
| bool rclcpp::Timer::is_ready |
( |
| ) |
const |
|
inline |
Would this timer fire on the next spin_once() pass? — rclcpp's TimerBase::is_ready().
phase-417 G6. The answer is the EXECUTOR's, read from the arena entry the timer is registered in: a cancelled timer is never ready, a fired one-shot is never ready again, and otherwise elapsed >= period. That is arena::timer_try_process's own guard rather than a second opinion about it — a readiness answer that can disagree with the dispatcher is worse than no answer.
An uninitialized timer answers false: it is registered with no executor, so nobody will dispatch it.
| Duration rclcpp::Timer::time_until_trigger |
( |
| ) |
const |
|
inline |
Time until this timer next fires — NEGATIVE when it is overdue. rclcpp's TimerBase::time_until_trigger().
phase-417 G6. Two deliberate differences from rclcpp, both recorded on the ledger row:
- upstream returns
std::chrono::nanoseconds; this returns [rclcpp::Duration], because this header is freestanding and <chrono> is not reachable from every target it serves (issue 0112). The UNIT is the same — d.nanoseconds() is upstream's count.
- the arena's timer accounting is MICROSECOND-based (issue #505), so the nanosecond value is a microsecond quantity scaled by 1000. The unit is rclcpp's; the resolution is ours.
A wall timer answers on the platform steady clock; a timer created with create_timer(clock, …) answers on its own clock.
Duration() (zero) for an uninitialized timer or one the executor does not know. That collides with "fires exactly now", which is why [is_valid] is the question to ask first — the C surface spends a return code on the distinction (rcl_timer_get_time_until_next_call answers RCL_RET_NOT_INIT) and a Duration-returning accessor has no room for one.