The Planner class

The planner class serves as the global planner for the robot. This is run only once when the robot receives a goal point, or once more after the robot executes a recovery behavior. The job of this class is to generate a path through the environment, given the original location of the robot and the goal point location.

The planner class, at the bare minimum, only has to have two functions:

• makePlan
• cancel

makePlan

This is the function that makes the plan and puts it in a vector of geometry_msgs:PoseStamped. It also has a integer return type, and you have return a code depending on how the planning worked. There are a bunch of error codes that you can return that are understood by move_base_flex, and move_base_flex would take care of handling that. There are a bunch of non-mbf codes as well that you can return, which will be communicated to the user. However, if you want to do something specific for those error codes, you need to write your own planner_execution class. To know more about the input parameters and the error codes that need to be returned, refer to abstract_planner.h file which has all inputs and output codes documented.

cancel

This is a function that can help you cancel the execution of the makePlan function. You can return false if do not want to implement a cancellation function, or if the cancellation fails for whatever reason. The way you would use this function (usually) is you would be setting some variables in your planner class, which you would be reading in a computationally expensive loop in your makePlan function. Keep checking the variables in each iteration of the loop, if a cancel is requested, you just exit the loop and call it a day. But feel free to do anything you want.

The Controller Class

The name “Controller” might be a misnomer, since here the “Controller” also serves the function of the local planner. Fundamentally, the job of the controller is to take the plan generated by the planner class and publish velocity commands that help the robot traverse that plan. It has to function as the local planner, keeping track of obstacles and collisions and also as the high level controller, generating velocity commands for the robot to follow.

The Controller Class, at the bare minimum, has to have the following four functions:

• setPlan
• computeVelocityCommands
• isGoalReached
• cancel

setPlan

This function gets the global plan from the global planner (in the form of a vector of geometry_msgs:PoseStamped mentioned earlier). You can use this plan however way you want to give information to your local planner on the global plan it has to follow. Ultimately, you return true if you have successfully set the plan for your controller and can follow it, and false if you couldn’t set the plan because the plan is infeasible or whatever the reason might be.

computeVelocityCommands

This is function is like a simple feedback loop that you can use to make your robot follow a trajectory. It gets the current position and velocity of the robot, and the job of the function is to generate a command velocity for the robot, which you then need to put in the geometry_msgs::TwistStamped variable. The return types are integer codes again, which you can return to specify how the execution of the controller loop went. To know more about the input parameters and the error codes that need to be returned, refer to abstract_controller.h file which has all inputs and output codes documented. However, there is one thing you need to note here, the code for SUCCESS just means that the function executed successfully, not the fact the robot reached the goal.

isGoalReached

Checking whether the robot has reached the goal or not is the job of this function. It gets an angle tolerance and distance tolerance as inputs, you can use that to determine if the robot has reached the goal or not.

cancel

This is similar to the cancel function of the planner, with one important difference: The controller loop does NOT stop if the cancel function is called. This is because it might not be safe to stop the controller loop midway during execution, and hence move_base_flex doesn’t stop the controller loop. Hence, even after cancel is called, the computeVelocityCommands function still keeps being called in the loop. However, it is just used to tell the Controller class to abandon the current plan, and come to a safe stop. After coming to a safe stop, the computeVelocityCommands function can then return the error code for CANCELLED to signify that the execution of the plan is cancelled successfully.

The Recovery Class

TO DO: I also have to understand the working of this class properly.