Framework’s managers

The managers we propose in this framework allow to ease the communication between the different nodes that are required to create your task. You can for instance store a given message in node A and to retrieve it in node B without creating any topic since the managers are natively running when starting the framework and provide services for different operations. Another good thing is that using service is language independent, so whether you are creating your nodes in python or in C++ you can still make the most of the managers. Those managers can also be used in states, action servers, more complicated services and so on.

Anonymous messages

All the managers are at least able to store and return messages through services. We provide two ways to do so. The first one is by naming them and retrieving them using the name given when storing. This is pretty useful when dealing with messages that are likely to be used again or that we want to access later. But sometimes, and especially when running closed loop methods, we just want to use messages just once without having to name it and that’s all. That is why all the managers (except the ACM) can deal with anonymous messages.
Messages without any name specified in the service will be stored in a specific queue. Every time a request for getting the message will be received without name, then the oldest anonymous message will be returned. Unlike named messages, once returned the message is deleted from memory and cannot be retrieved any more. You can of course add as many as you want, just keep in mind that the vector’s behaviour is First-In-First-Out (FIFO).

Provided managers

We are going to briefly review the six different managers that are natively supported by the framework and can help you develop your methods.

Allowed Collision Matrix manager

The ACM manager contains the following three services:

  • set_init_acm: Allows to store a provided ACM and set it as reference. Useful when we want to reinitialise (set it to a previous state) it several times without keeping in memory all the modifications brought to it. More details about the service here.
  • update_acm_entry: Updates the entries of the current ACM. Useful when dynamically adding objects to the scene. With the same service you can add and delete new objects to the ACM or reinitialise the matrix. You can find the service here.
  • get_modified_acm: Updates the allowed collision according to the specified modification and returns it. You can allow/disallow manipulator self collisions, collisions between the manipulator and given objects or just using it as a simple getter. Especially useful when we want to allow or disallow collisions of the manipulator. You can find out more about it here.

Moveit plan manager

The Moveit plan manager contains two services:

  • add_plan: Stores a RobotTrajectory message (which is a Moveit Plan). It is especially useful if you are using your own motion planner. The service is defined here.
  • get_plan: Gives access to an already stored RobotTrajectory message. Especially useful when wanting to execute or to modify a previously computed plan. The service can be found here.

Please note that the manager does not compute any plan!

Standardised grasp manager

For grasping, our framework is relying on a specific message defining a grasp. This manager contains two services to deal with such messages:

  • add_grasp: Store a StandardisedGrasp. Useful for storing grasps generating by methods in other nodes (not necessarily part of the framework). You can find out more about it here.
  • get_grasp: Gets an already stored StandardisedGrasp message. Useful to access and potentially execute an already generated grasp. Details can be found here.

Joint state manager

The joint state manager contains two services:

  • add_joint_state: Stores a JointState message. Useful for storing joint states dynamically generated by methods. You can find the details of this service here.
  • get_joint_state: Gets a previously stored JointState message. Can be used to edit or move to an existing one. Details of this service are here.

In addition to these two services, this manager is also taking care of loading the content of the config file named_joint_states.yaml. It allows you to create, use and access pre-recorded joint states whenever and where you want while using the framework.

Pose stamped manager

The pose stamped manager contains two services:

  • add_pose_stamped: Stores a PoseStamped message. Useful for storing poses dynamically generated by methods. You can find the details of this service here.
  • get_pose_stamped: Gets a previously stored PoseStamped message. Can be used to edit or move to an existing one. Details of this service are here.

The manager does not create PoseStamped messages! If you want helpers to do so, you can have a look at here.

Joint trajectory manager

The joint trajectory manager contains two services:

  • add_trajectory: Stores a JointTrajectory message. Useful for storing joint trajectories dynamically generated by methods. You can find the details of this service here.
  • get_trajectory: Gets a previously stored JointTrajectory message. Can be used to edit or move according to an existing one. Details of this service are here.

In addition to these two services, this manager is also taking care of creating the trajectories defined in the config file named_trajectories.yaml. It allows you to easily define predefined trajectories in a very accurate way. You can then use these trajectories where you want as long as the framework is running.

Create your own manager

If you need more operations to be carried out by the managers, you can either modify them or to create new ones. You can for instance create a manager that handles point cloud messages and process them. Please note that you are free to choose the language that suits you the most, you are not bound to implement it in C++.
In order to integrate your manager to the framework, the only thing you need to do is to wrap it in a ROS node and to launch the node in the core launch file. Do not forget to add the services and potentially your node in the CMakeLists.txt. You should now be able to use it in states and so on.