Robot Drivers

Different characteristics of the simulation require different robot drivers that control the MARA in order to optimize the performance and accuracy of executed trajectories.

In this section we provide a brief explanation of the two robot drivers currently being used for MARA in Gazebo. The standard driver, the one used to execute already trained policies, executes trajectories in a realistic way. On the other hand, the training driver focuses on simulation speed, executing unreal continuous actions at unreal speed.

Source code is available in GitHub.

This gazebo plugin is in charge of updating joint poses in the simulator without any interpolation. Whenever a new goal pose is received (via ROS2 subscription) we update the pose of the joint almost instantly to gazebo. We say "almost" as the system is dependant on gazebo's update connection event, but we can treat as instantaneous for the sake of an easier understanding, as the update event is broadcasted every simulation iteration at a very high rate.

Goal poses are executed instantly, with no interpolation at all. Meaning there is no trajectory flow between trajectories executed one after the other. This allows the robot to get to the final pose the fastest way possible, allowing the driver to provide feedback of the executed trajectory really fast.

To sum up, we need to execute actions (trajectories) and receive feedback of the new state (join pose) as fast as possible. The faster we compute the state-action pair, the faster our agent (MARA) will learn.

Note: We use a cognition component as the middle layer to interact via ROS2 topics. This hros_mara_cognition_components ROS 2 package is in charge of interacting with the driver and the python script (e.g. gym-gazebo environment) on both ends.

You might be interested in understanding the interaction between every block of code involved in action execution and posterior observation in our ROS2Learn framework. Feel free to raise your questions at ROS2Learn/issues if the image below is not explanatory enough. drivers

Final policies need to be tested in a realistic simulated environments before transferring to the real robot. For this reason we use the same driver as we use in the real robot, with the obvious difference of moving MARA in Gazebo.

This driver is under continuous improvement so we won't deep into details in this section. The key concept is that this driver executes actions with precise interpolation between the current and the goal poses, at precise and realistic speeds.