[Smac Planner Hybrid A*] Reeds-Shepp motion model not working: TF tree breaks, map->odom transform missing about navigation2 HOT 4 CLOSED

The error consists in the TF breaking, because the link transform map->odom is not published anymore, therefore the localization fails.

The choice of planning algorithm nor setting within a planning algorithm will make that requirement or the presence of that transform change. I believe you have some other problem that is simply coincidence that changing that parameter triggers your problem (if it does, deterministically?). Clearly something is wrong more than your information provides, the planner server nor its internal planning plugins should not be interacting in any way with localization.

from navigation2.

Any update?

from navigation2.

The choice of planning algorithm nor setting within a planning algorithm will make that requirement or the presence of that transform change. I believe you have some other problem that is simply coincidence that changing that parameter triggers your problem (if it does, deterministically?).
Clearly something is wrong more than your information provides, the planner server nor its internal planning plugins should not be interacting in any way with localization.

Working update:

After many failed attempts at finding the wrong parameter configuration causing the problem with the localization, I was finally able to successfully generate reverse motion trajectories with the Smac Hybrid A* planner.

As I mentioned in my first message, I couldn't make the Reeds-Shepp parameter work within the simulated environment. But then I had the idea to test everything on the real life robot in a real map, and everything magically worked. This is something that I didn't try before because I took for granted that if something doesn't work in simulation, it will never work on the real robot. Today is the day when this assumption demonstrated to be invalid, for the first time. It never happened to me that the "simulation-to-reality" gap was reversed, so my bad for not trying it beforehand.

The NAV2 configuration parameters used in both simulated and real environments, are practically identical, and the only differences are the names of the topics used for the sensors. So I was able to make the configuration work with the real robot without any changes.

Hypotheses

The TF tree breaks in the map->odom link, but the link breaking first seems to be actually odom->base_link. So it's still not clear to me whether the localization breaks, or the odometry breaks. During the tests I've conducted, the TF tree always breaks (so yes, it is deterministic), and since no clear errors arise, it's difficult to tell exactly what went wrong. My guess is that the problem is at odometry level. And the odometry is provided by Ignition Gazebo 6 via the differential drive odometry plugin.

My final guess:

When loading the motion model "REEDS_SHEPP", NAV2 takes longer to load, and that may be correlated to the problem cause. So when I use that parameter in the simulation, there is something obscure that causes a faulty interaction between NAV2 and the odometry plugin in gazebo (along with the bridge), which in turn breaks the TF tree. If it's not this I don't know what it is.

I've done a lot of research, and I know very well that these modules must not affect each other, and that they must be completely not correlated, but this is what I found, and I'm totally sure of my findings. So I'm perfectly aware that it is very strange that the odometry from Gazebo could cause directly or indirectly this problem, but this is my best guess, with the knowledge that I have.

Conclusions

Summing up:

• Ignition Gazebo Fortress simulated environment: NAV2 working fine as long as the motion model for Hybrid A* is "DUBIN". Using the "REEDS_SHEPP" motion model in the same simulated environments, with the same parameters, breaks some link in the TF.
• Real map, with real robot, with real sensors: NAV2 works fine regardless of the motion model parameter

I will not mark this issue as solved since I technically didn't solve it yet, and because I only found a different case scenario where the problem doesn't arise. It is also not really important for me to have this issue solved in the simulated environment, because I actually care more about the real robot.

from navigation2.

When loading the motion model "REEDS_SHEPP", NAV2 takes longer to load, and that may be correlated to the problem cause.

This is true, due to the lookup table calculation on initialization. It would be fragile if whatever your application is based on timing and not events like lifecycle transitions.

Closing since this isn't a bug in Nav2 and shown to work fine. Its potentially rooted in your application software or the simulator (either way to be taken up with the respective party). If it something in the simulator, feel free to tag me in that new ticket to track and help over there.

from navigation2.