RCL_ROS_TIME: how to get sim-time-aware monotonic timing?
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 35/100
Direzione di ricerca
Esamina il comportamento di fallback di RCL_ROS_TIME e gli entry point rclcpp::Rate, rclcpp::WallRate, create_timer e create_wall_timer. Determina se un meccanismo esistente supporta un fallback al tempo monotono, oppure definisci il comportamento dell’API necessario per usare /clock nella simulazione e il tempo monotono sull’hardware, incluse le modifiche di use_sim_time durante l’esecuzione.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Description
When use_sim_time=true, an RCL_ROS_TIME clock sources time from the /clock topic. When use_sim_time=false, it falls back to RCL_SYSTEM_TIME unconditionally. This fallback is hardcoded in rcl.
There is currently no native way to create a clock that uses /clock in simulation and RCL_STEADY_TIME (monotonic wall time) on real hardware. The only two options available are:
RCL_STEADY_TIME— monotonic but ignores sim time entirelyRCL_ROS_TIME— sim-time-aware, but falls back toRCL_SYSTEM_TIME(notRCL_STEADY_TIME) on real hardware
This is a problem for any node that needs different clock behaviors for different purposes within the same node. For example, a controller node typically needs:
| Use case | Real hardware | Simulation |
|---|---|---|
| Control loop timer | RCL_STEADY_TIME (monotonic, NTP-immune) |
/clock |
| Message timestamps | RCL_SYSTEM_TIME (wall clock) |
/clock |
Today, both of these are impossible to satisfy with a single RCL_ROS_TIME clock because the fallback is always RCL_SYSTEM_TIME. Using the node's clock for a control loop timer silently introduces NTP sensitivity on real hardware.
Motivation
This came up in ros-navigation/navigation2#6063, which makes various Nav2 components sim-time-aware by switching from rclcpp::WallRate to rclcpp::Rate(freq, node->get_clock()). This is the right thing to do for simulation, but it silently changes the real-hardware behavior from RCL_STEADY_TIME (monotonic) to RCL_SYSTEM_TIME (NTP-adjustable), because that's the only fallback RCL_ROS_TIME supports.
Current workaround
The only workaround is to check use_sim_time at construction and branch between create_timer and create_wall_timer:
class Controller : public rclcpp::Node
{
public:
Controller() : Node("controller")
{
if (get_parameter("use_sim_time").as_bool()) {
timer_ = create_timer(100ms, std::bind(&Controller::control_loop, this));
} else {
timer_ = create_wall_timer(100ms, std::bind(&Controller::control_loop, this));
}
}
void control_loop()
{
auto cmd = compute_velocity();
cmd.header.stamp = now();
pub_->publish(cmd);
}
};
This is fragile — use_sim_time is checked once at construction, so runtime parameter changes are ignored. Every node or library that needs monotonic + sim-aware timing must duplicate this pattern. The same issue applies to rclcpp::Rate and rclcpp::WallRate, where there is no equivalent workaround at all.
Question
What is the intended way to get sim-time-aware monotonic timing in rclcpp? Is there an existing mechanism we are missing, or does rclcpp need a way to configure the fallback clock type for RCL_ROS_TIME?
- Lingua principale
- C++
- Stelle
- 814
- Fork
- 572
- Merge medio
- 4g 8h
- PR unite (30g)
- 18
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di ros2/rclcpp
-
enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 10/100
I maintainer di solito rispondono entro 1 giorno
-
:farmer: Flaky EventsCBGExecutor test: reentrant callback group fails to run callbacks concurrentlyApertabug
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
I maintainer di solito rispondono entro 1 giorno
-
Copy constructor exception leaks intra-process message allocationForse già presa @TinyGeek l’ha presa 3 giorni fa. Aperta
Difficoltà 3/5 1-2 giorni Idoneità per principianti 35/100
I maintainer di solito rispondono entro 1 giorno
-
[Jazzy] action server registers clock jump callbacks without the clock mutex (heap corruption)Forse già presa Una pull request collegata a questa issue è aperta o già unita. Apertabug
Difficoltà 4/5 3-5 giorni Idoneità per principianti 44/100
I maintainer di solito rispondono entro 1 giorno
Issue simili
-
llvm.memcpy with destination align but no source align asserts "Missed Source alignment!"Forse già presa @pvelesko l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
KhronosGroup/SPIRV-LLVM-Translator#4093 ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 66/100
I maintainer di solito rispondono entro 1 giorno
-
SIMQ silently truncates multi-query batch search to the first queryForse già presa @LHT129 l’ha presa oggi. Apertakind/bug module/index needs-triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
antgroup/vsag#3080 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 Mezza giornata Idoneità per principianti 68/100
I maintainer di solito rispondono entro 1 giorno
-
[Bug] Title-bar audio controls shift horizontally when the TX timer appears and disappearsForse già presa @w5jwp l’ha presa oggi. Apertabug GUI maintainer-review
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
aethersdr/AetherSDR#6455 · 3 commenti ·
I maintainer di solito rispondono entro 1 giorno