Yaw_tolerance of intermediate nodes for edges with move_base type actions

[gpdas]

At the moment, for intermediate nodes (and edges with move_base actions), the yaw_tolerance is ignored.

However, if only move_base actions are used for all edges, it might still be ideal for the robot to satisfy the yaw_tolerance for some specific intermediate nodes. A possible solution would be to add another attribute to the node definition which determines whether yaw_tolerance should be satisfied for an intermediate node of a route.

[Jailander]

Yes I will work on this, it seems hard to fit within the current framewrok, but let me give it a think

[marc-hanheide]

I'm not sure I think this to be a good idea. It's in some violation to the concepts. If one wants to go to a specific pose, then one should tell topo nav to go to that point. The problem described in https://github.com/LCAS/RASberry/issues/157 should IMO not be solved on the topological navigation level. Using a node orientation to make navigation more robust is a bad hack. We must work towards a navigation system that can enter row, irrespective of the orientation it had before.

[Jailander]

I was thinking on having specific transition nodes (via rosparam) for which going to the fixed position is mandatory, this kind of rule exist when there is a transition between move_base type actions and non move_base type actions.
What do you think @marc-hanheide ?

[marc-hanheide]

I can be handy, but all I wanted to say is that we shouldn't use it to bad-fix any navigation problems.

[Jailander]

I understand that, what I was wondering is more "conceptual" and was looking for your opinion.
In topological navigation we have a rule to ensure that non_move_base type actions are started from a well tested position that tells the planner to go to the specific waypoint pose before triggering the non_move_base action.
The problem in RASberry arises because all the actions within the polytunnels are move_base type so the robot plans to the next waypoint as soon as it reaches the influence area of the goal, but in some nodes this is not good enough as space constraints make the planner struggle more than necessary.
While it is true that that is a planner problem, topological navigation already deals with the issue for non_move_base type actions so I think it can sort it out for move_base to move_base transitions as I proposed on my previous message.
An easy fix though could be to make the influence area of such nodes much smaller so the planner drives closer to the node before replanning.

[marc-hanheide]

So, conceptually, you want to indicate if the outgoing edge requires the specific orientation to be adhered to, right. So, it should be an optional flag on the outgoing edges?