RootRework: Better navigation?

[MoffKalast]

As discussed we'll try to implement two types of path planning:

• A* paths to do collision avoidance (Janez)
• a system that doesn't use occupancy grids (Jan)

We can open separate issues for each once we have more of an idea about what's the end goal for each.

[JanezCim]

OK with a* this is where i am now:

robot ran in Gazebo, slam with iris lama, in rviz you set a nav goal, ros navigation global planner calculates path to it using a*, outputs goal and magni follows it using move_basic
Next planned work: recaculate that path every x meters/ y seconds, recalculate goal if obstacle on path

[MoffKalast]

and magni follows it using move_basic

Wait, does move basic actually have path following capabilities?

[JanezCim]

Nope, goal manager is passing the specific points through actions

[MoffKalast]

Ah ok, so how does it determine which points to send? Something like the farthest one in direct view?

[JanezCim]

currently path is divided into 0.2m parts, and those points get sent to move basic to reach

[JanezCim]

Here is an addition of path tracing. Whenever there appears an obstacle on the path, simply resends the end goal and let the astar do the rest:

a couple of observations:

• move basic stops at every intermediate point on the path so that is why the robot is so slow and clunky
• astar takes shortest path in known space (drives on unknown space but wants to get off it asap) - which is good
• when obstacle goes away, the lidar rays need to hit something behind it to actually delete it from occupancy grid - that way you can easily get ghost obstacles.
• updaing of global occupancy grid can be quite slow (not good for fast driving)

[MoffKalast]

Hmm I wonder if we could instead do this with sort of local map that updates faster. Instead of relying on a slam node, we could instead take the laserscan and treat any detections as obstacles to avoid and the rest as open space. There has been a lot of demand for very fast driving so that should probably be considered here.

Likely not as reliable but should be much faster I would think?

[JanezCim]

Im not sure that raspberry would be up to the task but we can try. But when we add the local planner then that is basically 80% of move base added haha. Might as well implement the whole damn thing

[JanezCim]

Teb local planner in action:

Comments:

• works fine in gazebo with ok processing power
• teb has lots of parameters but generally works ok out of the box
• might be tough on RPI processors if this was actually running on the robot, so that remains to be seen.
• If this was imeplemented then move basic would actually not be usable, since teb local planner actually calculates the cmd_vel. In this case our vornoi planner would actually have to be written as a global planner plugin to the move-base

[JanezCim]

Plan: @JanezCim tries out a* on real robot