Suppress ros2_control overrun warnings in simulation configs#713
Suppress ros2_control overrun warnings in simulation configs#713davetcoleman wants to merge 1 commit into
Conversation
|
Warning Review limit reached
More reviews will be available in 45 minutes and 32 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (9)
Comment |
Set controller_manager overruns.print_warnings: false in every simulation config so the non-realtime overrun WARN spam (new in the Jazzy controller_manager 4.44) no longer floods the console. Sim-only; real-hardware base/site configs are intentionally left untouched. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
352bd65 to
2cae6ba
Compare
|
|
fdavulcu
left a comment
There was a problem hiding this comment.
Fix
Set
overruns.print_warnings: falsein thecontroller_managerblock of every simulation config. This silences both warnings (they read the same flag). The siblingoverruns.manageparameter is left untouched, so overrun handling behavior is unchanged — only the logging is suppressed.
This is not correct, they do not read the same flag. This PR will only get rid of one of the warnings ("Overrun might occur, ...") which is in the controller_manager.cpp. The other warning ("Overrun detected! ... ") is based on the overruns.manage flag in the ros2_control_node.cpp file.
If you're fine with suppressing only the "Overrun might occur" warning, the changes LGTM. However, setting the overruns.manage as false would require more thinking and testing.
Problem
On non-realtime machines (Parallels/Docker VMs, dev boxes), running any simulation floods the console with ros2_control overrun warnings:
These are new in Jazzy — the
controller_managerversion Jazzy ships (4.44.0) added anoverrunsreporting feature that Humble's oldercontroller_managerdid not have. The overruns themselves are harmless in simulation (a control cycle running late in sim has no physical consequence, and MuJoCo's own sim-health reporter confirms physics keeps up), but the WARN spam drowns out useful log output.Fix
Set
overruns.print_warnings: falsein thecontroller_managerblock of every simulation config. This silences both warnings (they read the same flag). The siblingoverruns.manageparameter is left untouched, so overrun handling behavior is unchanged — only the logging is suppressed.Scope
Applied to the 9 first-party simulation configs:
lab_sim,hangar_sim,factory_sim,grinding_sim,dual_arm_sim,kitchen_sim,mock_sim,multi_arm_sim,kinova_sim.space_satellite_simis covered transitively (based_on_package: kinova_sim).phoebe_simis excluded: it lives in thephoebe_wsgit submodule (separate repo).CI
example_ws CI is Jazzy-only (
humble is disabledperci.yaml), andoverruns.print_warningsis a declared parameter in the Jazzycontroller_manager4.44.0, so the integration tests that launchlab_sim/hangar_simload it without error.Loading these configs under an older (Humble-era)
controller_managerthat predates theoverrunsparameter group is out of scope and unverified — this workspace targets Jazzy. A customer who copies a sim config into a Humble workspace should confirm load behavior there.