Understanding behavior changes after parameter tuning in Nav2

[kehan-zhou]

While working with Nav2 on a real robot, I found that getting navigation running is usually straightforward — but systematically tuning it reliably is much harder.

Many issues I encounter (and often see online) look like:

• robot oscillates or zig-zags
• works in simulation but behaves differently on hardware
• changing one parameter unexpectedly breaks something else
• navigation succeeds sometimes and fails other times

The tuning workflow often ends up being:
edit YAML → relaunch → observe → interpret → adjust → repeat

After a while it becomes difficult to understand what exactly changed between two runs, or why one configuration behaved better than another.

Before exploring solutions, I wanted to ask whether this matches the experience of others in the community:

Do you find that the main difficulty of Nav2 is understanding behavioral differences between runs after parameter changes?

And from the maintainer perspective:
Is this kind of run-to-run analysis intentionally outside the scope of Nav2 itself (i.e., better handled by external tooling)?

I’d really appreciate hearing how others approach systematic tuning today.

[SteveMacenski]

You can also use dynamic parameters, you don't need to edit and relaunch -- you can dynamically adjust parameters on the fly to see behavior changes as they occur.

We have benchmarking for the planners and smoothers that help in some initial tuning and metrics collection in tools/. I'm not going to tell you its complete or all of what I would need for me to do tuning or a particular application, but its a start. Controllers in particular are more finnicky and alot of the behavior folks care about are difficult to capture in pure, easy metrics and typically can be somewhat subjective or require very particular situations for testing and evaluation.

[kehan-zhou]

I wanted to follow up on our previous discussion about understanding behavior changes after parameter tuning in Nav2.

I’ve developed a tool called Astryin, which addresses some of the challenges we discussed, particularly in tracking and visualizing the subtle behavioral changes in robot navigation across different runs. It helps in analyzing key metrics like velocity profiles, tracking errors, and trajectory analysis, which makes it easier to understand why a particular configuration behaves better than another.

You can check out the tool here: https://github.com/kehan-zhou/astryin

It’s still a work in progress, but I believe it could complement Nav2 and help developers systematically analyze and compare runs in a more structured way. I would greatly appreciate any feedback or suggestions you might have.

Thanks again for your insights earlier. Looking forward to hearing your thoughts!

[SteveMacenski]

More tooling is always helpful!

I agree that this looks like it could be helpful. I'd say keep it up and use it to solve your planning/control issues and then we can look at what you have done when you have the MVP. We can add a tutorial for how to use it in the nav2 docs and/or adopt it into the ros-navigation org (if interested) if it hits a level of utility and quality that other users are finding it useful!

[kehan-zhou]

Thanks for the encouragement!

I'll keep developing Astryin and start by using it to analyze real navigation issues on my robots. Once it reaches a more complete MVP stage, I'll share it again for feedback.

Really appreciate the support and suggestions.

[kehan-zhou]

Following up on our discussion—I've officially reached the MVP stage for Astryin.

I've spent the last few weeks refining the core logic, especially focusing on making the tool robust for real-world (and simulated) analysis.

What's new in this MVP:

• Dynamic TF Compensation: The tool now performs a time-accurate lookup of the map -> odom transform. This allows it to correctly align the robot's actual trajectory with the global plan.
• Quantitative Metrics: It doesn't just plot; it quantifies. It calculates mean/max tracking errors and provides "Motion Windowing" to filter out stationary data for accurate velocity profiling.
• Trajectory & Velocity Synergy: Developers can now visually correlate a controller's "thinking" (local plan clusters) with the resulting physical execution (odom velocity jitter).

I've found it incredibly helpful for spotting why certain DWB parameter tweaks lead to oscillations that are otherwise hard to quantify in RViz.

You can find the source and a detailed guide here: https://github.com/kehan-zhou/astryin

I'd love to hear your thoughts on whether this fits the criteria for Nav2 tutorial or if there are specific tests you would like to see it handle.

[SteveMacenski]

You may want to post on the Nav2 Slack / ROS Discourse / LinkedIn with your work and get feedback from the broader community!