Robot modeling and simulation (three)-ros_control

Robot modeling and simulation (three)-ros_control

Overview

ROS provides a wealth of robot applications: SLAM, navigation, MoveIt... But you may always have a question about how these function packages should be used on our robots, that is to say, between the application and the actual robot or robot simulator In between, there is a lack of a connection between the two.
ros_control is the middleware between the application and the robot provided by ROS. It includes a series of controller interfaces, transmission device interfaces, hardware interfaces, controller toolboxes, etc., which can help robot applications quickly land and improve development efficiency.

One, ros_control framework

The picture above shows the overall framework of ros_control. It can be seen that for different types of robots (mobile robots, robotic arms, etc.), ros_control can provide multiple types of controllers, but the interfaces of these controllers are different. In order to improve the code reuse rate, ros_control also provides a hardware abstraction layer. The hardware abstraction layer is responsible for the management of the robot's hardware resources, and the controller only needs to request resources from the abstraction layer and does not directly touch the hardware.


The figure above is the data flow diagram of ros_control, and you can see the functions included in each level more clearly:
(1) Controller Manager (Controller Manager)
Each robot may have multiple controllers, so here is a controller manager The concept of providing a common interface to manage different controllers. The input of the controller manager is the output of the ROS upper application function package.
(2) Controller The
controller can complete the control of each joint, read the status in the hardware resource interface, and then issue control commands.
(3) Hardware Resource (Hardware Rescource)
provides the interface of hardware resources for the upper and lower layers.
(4) Robot Hardware Abstraction (RobotHW) The
robot hardware abstraction layer directly interacts with hardware resources and completes hardware operations through write and read methods. This layer also includes functions such as joint constraints, torque conversion, and state conversion.
(5) The real robot
also needs its own embedded controller on the real robot to reflect the received commands to the actuator. For example, after receiving the command to rotate 90 degrees, the actuator needs to be fast, Stably rotate 90 degrees.

Second, the controller

The function package ros_controllers provides the following controllers:


Of course, we can also create the controllers we need according to our own needs, and then manage the controllers created by ourselves through the controllers. For the specific method of creating controllers, please refer to https:// github.com/ros-controls/ros_control/wiki/controller_interface

Three, hardware interface

The hardware interface is the communication interface between the controller and RobotHw. It basically corresponds to the type of controller. You can also create the required interface yourself. For specific implementation methods, please refer to: https://github.com/ros-controls/ros_control/wiki/ hardware_interface

Fourth, the transmission system

Transmissions can convert robot joint commands into actuator control signals. Each joint of the robot needs to be configured with a corresponding transmission system, which can be completed by code https://github.com/ros-controls/ros_control/wiki/transmission_interface, but in most cases, it will be directly added to the URDF file (Http://ros.org/wiki/urdf/XML/Transmission):

<transmission name="simple_trans">
     <type>transmission_interface/SimpleTransmission</type>
     <joint name="foo_joint">
          <hardwareInterface>EffortJointInterface</hardwareInterface>
     </joint>
     <actuator name="foo_motor">
          <mechanicalReduction>50</mechanicalReduction>
          <hardwareInterface>EffortJointInterface</hardwareInterface>
     </actuator>
</transmission>

Five, joint constraints

Joint Limits are part of the hardware abstraction layer. It maintains a joint constraint data structure. These constraint data can be loaded from the robot's URDF file or on the ROS parameter server (you need to use the YAML configuration file first Import the ROS parameter server), which not only includes constraints on joint speed, position, acceleration, jerk, torque, etc., but also includes position soft limit, velocity boundary (k_v) and position boundary (k_p) that play a safety role.
You can set the Joint Limits parameter in URDF as follows:

<joint name="$foo_joint" type="revolute">
  <!-- other joint description elements -->
 
  <!-- Joint limits -->
  <limit lower="0.0"
         upper="1.0"
         effort="10.0"
         velocity="5.0" />
 
  <!-- Soft limits -->
  <safety_controller k_position="100"
                     k_velocity="10"
                     soft_lower_limit="0.1"
                     soft_upper_limit="0.9" /> 
</joint>

There are also some parameters that need to be loaded into the parameter server in advance through the YAML configuration file. The format of the YAML file is as follows:

joint_limits:
  foo_joint:
    has_position_limits: true
    min_position: 0.0
    max_position: 1.0
    has_velocity_limits: true
    max_velocity: 2.0
    has_acceleration_limits: true
    max_acceleration: 5.0
    has_jerk_limits: true
    max_jerk: 100.0
    has_effort_limits: true
    max_effort: 5.0
  bar_joint:
    has_position_limits: false # Continuous joint
    has_velocity_limits: true
    max_velocity: 4.0

Six, controller manager

The controller_manager provides a multi-controller control mechanism, which can implement various operations such as loading, starting, stopping, and unloading of the controller. As shown in the figure below, the controller_manager controls the state transition of the controller.

The controller_manager also provides a variety of tools to assist in these operations.
1.
The format of the command line tool controller_manager command is:

rosrun controller_manager controller_manager <command> <controller_name>

The supported ones are as follows:
load: load a controller (construct and initialize)
unload: unload a controller (destruct)
start: start a controller
stop: stop the controller ( stop a controller)
spawn: load and start a controller (load and start a controller)
kill: stop and unload a controller (stop and unload a controller)
If you want to check the status of a controller, you can use the following command:

rosrun controller_manager controller_manager <command>

Supported:
list: List all controllers according to the order of execution, and display the status of each controller. (List all the controllers in the order they are executed, and give the state of each controller)
list-types: Display all controller types. (List all the controller types the controller manager knows about. If your controller is not in this list, you won't be able to spawn it.)
reload-libraries: reload all controller libraries in the form of plug-ins, no Restart to facilitate the development and testing of the controller. (Reloads all the controller libraries that are available as plugins. This is convenient when you are developing a controller and you want to test your new controller code, without restarting the robot every time. This does not restart controllers which were running before.)
reload-libraries --restore: Reload the libraries of all controllers in the form of plug-ins and restore them to the initial state. (Reloads all the controller libraries that are available as plugins and restores all controllers to their original state.)
But many times we need to control a lot of controllers, such as six-axis robots with at least six controllers, then you can also use spawner Command to control multiple controllers at once:

rosrun controller_manager spawner [--stopped] name1 name2 name3

The above command can automatically load and start the controller. If you add the -stopped parameter, the controller will only be loaded, but it will not start running. If you want to stop a series of controllers, but do not need to uninstall, you can use the following command:

rosrun controller_manager unspawner name1 name2 name3

2.
Launch tool In the launch file, you can also load and start a series of controllers by running the controller_manager command:

 <launch>
   <node pkg="controller_manager"
         type="spawner"
         args="controller_name1 controller_name2" /> 
 </launch>

The above launch file will load and start the controller. If you only need to load it without starting, you can use the following configuration:

<launch>
  <node pkg="controller_manager"
    type="spawner"
    args="--stopped controller_name1 controller_name2" />
</launch>

3. The visualization tool rqt_controller_manager
controller_manager also provides the visualization tool rqt_controller_manager. After the installation is successful, directly use the following command to open the interface:

rosrun rqt_controller_manager rqt_controller_manager

Seven, Gazebo simulation

1. Add Gazebo attributes to the robot model
(1) Add a <gazebo> tag to the link
(2) Add a transmission device
(3) Add a Gazebo controller plug-in
2. Display the robot model
in Gazebo 3. Control the robot to move in Gazebo
4. Camera Simulation
(1) Add Gazebo plug-in to camera model
(2) Run simulation environment
5. Kinect simulation
(1) Add Gazebo plug-in to Kinect model
(2) Run simulation environment
6. Lidar simulation
(1) Add Gazebo plug-in to rplidar model
( 2) Run the simulation environment