Please ask about problems and questions regarding this tutorial on answers.ros.org. Don't forget to include in your question the link to this page, the versions of your OS & ROS, and also add appropriate tags.

Use Plugin State in the RSM

Include in Launch

To use the created plugin from above in the RSM, it has to be made known to the State Interface. This needs to be done by setting the respective parameters, either through the launch file or manually when starting the nodes from console. The State Interface expects the names for the Calculate Goal State, the Mapping State and the Navigation State plugins. The waypoint Routine State plugins need to be given to the Service Provider. A sample launch with set parameters can be seen in the snippet below, where the plugins defined in RSM additions are used. A detailed example can be seen in the RSM additions launch files.

<include file="$(find rsm_core)/launch/rsm.launch">
        <arg name="calculate_goal_plugin" value="rsm::CalculateGoalState" />
        <arg name="navigation_plugin" value="rsm::NavigationState" />
        <arg name="mapping_plugin" value="rsm::MappingState" />
        <arg name="waypoint_routines" value="['Reversing']" />
        ...
</include>

The provided plugins can have arbitrary names, though it is recommended to use the rsm namespace to avoid collisions with other packages since the plugin names need to be unique.

For waypoint routines up to ten routines can be provided as an array. Each routine plugin must be named like this

rsm::NAMERoutineState

NAME has to be replaced by a uniquely identifying name for the particular routine. For the routines parameter provided only the NAME needs to be set. So in the above example the plugin corresponding to the Reversing routine is called rsm::ReversingRoutineState. If additional plugins should be used, their names do not need to be made known to the RSM up front. How to include them will be explained below.

State Transitions

For a transition to another state, in your implementation of a state the transitionToVolatileState method from State Interface needs to be called. If a transition to one of the included states is desired, it needs to be included in the header file and and then initialized and handed over as a parameter to the previously mentioned method. This is the first of the below examples. The second is a transition to a plugin state, which is made by providing one of the predefined types from State Interface to the method. If it is a routine plugin that should be called, the routine plugin's name needs to be provided as well, see the third example. The last example shows a transition to an additional plugin, where a 0 for the plugin type needs to be given and the name of the plugin without a leading rsm:: prefix.

• Transition to already included state:

_stateinterface->transitionToVolatileState(boost::make_shared<IdleState>());

• Transition to plugin state for navigation:

_stateinterface->transitionToVolatileState(_stateinterface->getPluginState(NAVIGATION_STATE));

• Transition to routine plugin state:

_stateinterface->transitionToVolatileState(_stateinterface->getPluginState(ROUTINE_STATE, "Reversing"));

• Transition to additional plugin state:

_stateinterface->transitionToVolatileState(_stateinterface->getPluginState(0, "ClimbStairsState"));

For a reference implementation of the Calculate Goal State, the Navigation State, the Mapping State and a routine plugin called Reversing Routine State, see the rsm_additions package.

Data Transfer between States

If additional data has to be passed between plugin states, that is not already covered by the Service Provider, it is recommended to implement an additional data handler for this. See the Additions Service Provider in the package RSM additions for an example.

Reverse Driving for Navigation

If the robot should be able to move in reverse mode, a service needs to be implemented called setNavigationToReverse which changes the navigation's mode interface in the Navigation State plugin and switches between forward and reverse movement. A sample to include into the additional data handler can be seen below. If it is missing, activating reverse mode will only output a matching error.

   1 ...
   2 ros::NodeHandle nh("rsm");
   3 ros::ServiceServer set_navigation_to_reverse_service = nh.advertiseService("setNavigationToReverse", setNavigationToReverse);
   4 ...
   5 
   6 bool setNavigationToReverse(std_srvs::SetBool::Request &req, std_srvs::SetBool::Response &res) {
   7         if (//set mode to forward/reverse depending on req.data) {
   8                 res.success = 1;
   9                 res.message = "Mode set";
  10         } else {
  11                 res.success = 0;
  12                 res.message = "Mode not set";
  13         }
  14         return true;
  15 }