Nav2 Controller Frequency and Timing

Source: ros2-copilot-skills controller frequency skill

Why This Matters

Local control frequency sits at the intersection of compute budget, sensor freshness, and robot responsiveness. If the controller runs too slowly, motion feels stale. If it runs too fast for the hardware and sensing pipeline, it burns CPU while acting on outdated information.

Distilled Takeaways

• Controller frequency should match how quickly the robot, sensors, and cmd_vel consumers can benefit from new commands.
• Higher frequency is not automatically better if the pipeline behind it is lagging.
• Timing problems often show up as oscillation, stale motion, or a robot that feels hesitant despite apparently correct plans.
• Controller tuning has to be considered alongside velocity smoothing, sensor rates, and compute load.

Practical Guidance

• Measure actual loop rates and latency instead of assuming configured values are being achieved.
• Use a controller rate that the full system can sustain under realistic load.
• Revisit timing after enabling expensive critics, richer costmaps, or additional sensors.
• Treat CPU saturation as a navigation-quality problem, not just a systems problem.

Corroborating References

• Nav2 tuning guide
• ROS 2 executor concepts

When to Read the Original Source

Go to the original skill when you want concrete guidance on controller frequency tradeoffs, stale-velocity symptoms, and how to match loop rate to platform compute and motion dynamics.