Navigating (Tue Oct 29, lect 16) | previous | next | slides |

Deeper dive into Navigating

Review of Slam

  1. An algorithm that builds up a map while collecting sensor and analyzing it statistically
  2. The map as it is being built is published by the map_server
  3. You can save the map to a file so that it remembers it to the next run
  4. Map Consists of a grid of “costs” (costmap) and a coordinate system
  5. Map server “publishes” the map on the /map topic
  6. Costmaps are actually multi-layered
  1. AMCL: Given lidar sensor data and a map, estimates the true location of the robot
  2. Calculation is reset when amcl receives a new pose_estimate
  3. This estimate is different from /odom (why?)
  4. AMCL publishes a /tf transform between /map and /odom (note this is the “highest probability” location)

ROS Actions

  • Built on top of ROS Topics
  • Used for the key navigation service, move_base
  • Actions implement a protocol where a node (requestor) can request a long-running action from another node (actor)
  • Compare with topic publishing which are one-shot
  • Requestor:
    • Does not need to know anything about how to actor works
    • Can ask to initiate an action (e.g. navigate to x,y)
    • Can find out the progress or status of the action (which can take many seconds)
    • Is notified when the action is finished, either successfully or unsuccessfully
  • Actor:
    • Receives the request from the requestor
    • Proceeds to implement the action
    • REports status as requested
    • Reports completion, either successful or failure
  • Book: 5: Actions

ROS Services

  • Built on top of ROS topics
  • Used as a way to allow a node to receive requests (synchronously) and return a response
  • Also used as part of move_base.

move_base - The big enchilada of ROS Navigation

  • Main entry point of ROS navigation algorithms
  • Conceptually: move_base(x,y) - causes the robot to do it’s best to get to x,y
  • But there must be a lot more to it.
Discussion: what else must be involved?
  • A large diverse collection of packages and modules
  • A sophisticated, pluggable architecture
  • Allows for new algorithms to be designed and tested
  • Parameterized for configuration
  • Uses ROS “actions” to initiate, monitor, and report success
  • Initial goal is: /MoveBaseActionGoal

Components of move_base

  • Global Planner: Creates a plan from the current position (AMCL) to the goal position with respect to a map. May use any of a number of algorithms (including A*)
  • Local Planner: Given the local map (built in real time from sensors), considers location and velocity and computes the near part of the plan.
  • costmap-2d: General package to build, maintain, update and access a multi-layer 2d map. Used for both local and global maps and for other things
  • Recovery behaviors: either map clearing or rotation recovery heuristics used when robot appears to be stuck.

FLows

How move_base works - global planner

  1. Uses base_global planner to comnpute a path from current position to goal
  2. This plan is with respect to the global costmap (from /map topic and map_server)
  3. Look at ROS global planner for visuals
  4. Interesting parameters:

/use_dijkstra (bool, default: true) # If true, use dijkstra's algorithm. Otherwise, A*.
/use_quadratic (bool, default: true) # If true, use the quadratic approximation of the potential. Otherwise, use a simpler calculation.
/use_grid_path (bool, default: false) # If true, create a path that follows the grid boundaries. Otherwise, use a gradient descent method.

How move_base works - local planner

  1. Create a local map grid from the local costmap) with costs representing distances to the final goal
  2. Uses base_local_planner to determine the next motion in the immediate future

The two book chapters

Topics for further study

Thank you. Questions?  (random Image from picsum.photos)