DOCSEARCHbyAlgolia
Submit Docs

ros2_control Documentation

repository·master·Indexed 21 days ago

https://github.com/ros-controls/ros2_control

A framework for real-time robot control within the ROS 2 ecosystem, providing standardized interfaces for hardware abstraction and control algorithms. It includes the controller_manager for managing controller lifecycles, support for asynchronous controllers, and a system for serial controller chaining via ChainableController. The framework utilizes distinct clock types (RCL_STEADY_TIME and RCL_ROS_TIME) to ensure stability between real-time execution and simulation.

Tokens
32.6K
Snippets
72
Records
112
Agent score
75%

What's inside ros2_control

  3. Use hardware_interface_testing for testing controllers and interfaces

    master
    The hardware_interface_testing package provides a collection of mock hardware interfaces and controllers. These components are designed to be used as test fixtures by developers building other ros2_control packages, allowing for the verification of controller functionality and interface compatibility without requiring physical hardware.

  4. Identify ros2_control framework packages

    master

    The ros2_control framework is composed of several specialized packages. Depending on whether you are implementing a new controller, a hardware interface, or managing existing controllers, you will need to interact with one or more of the following packages:

    • controller_interface: Provides the base classes and interfaces for implementing controllers.
    • controller_manager: The core component that manages the lifecycle of controllers and hardware interfaces.
    • controller_manager_msgs: Defines the ROS 2 messages used for communicating with the controller_manager.
    • hardware_interface: Provides the interfaces required to communicate with physical or simulated hardware.
    • joint_limits: Provides utilities for handling joint limits.
    • ros2_control_test_assets: Contains assets used for testing ros2_control implementations.
    • transmission_interface: Provides interfaces for handling transmissions (e.g., between motors and joints).

  5. Use GPIO tags for non-joint/sensor signals

    master

    The <gpio> tag describes input and output ports (digital or analog) that cannot be associated with a joint or a sensor.

    • The <gpio> tag can be a child of system, sensor, or actuator hardware components.
    • It must contain at least one <command> or <state> tag as a child.
    • Note: There is no generic GPIO publisher in ros2_control. Because GPIO implementations are highly application-specific, you must implement a custom GPIO controller for your specific use case.

  6. Understand the Controller Manager's ROS Interface

    master

    The controller_manager is the central component of ros2_control. It manages the lifecycle of controllers, provides access to hardware interfaces, and exposes services to the ROS ecosystem.

    Publishers

    • ~/activity (controller_manager_msgs::msg::ControllerManagerActivity): Publishes whenever the state of managed controllers or hardware components changes. It includes a list of components and their current lifecycle states.
      • Note: This topic uses a transient local Quality of Service (QoS). Subscribers must also use transient local to receive the latest state.

    Subscribers

    • robot_description (std_msgs::msg::String): Expects a string containing the URDF XML (typically provided by robot_state_publisher).
      • Requirement: All joints defined in the <ros2_control> tag within the URDF must be present in the URDF itself.
      • Limitation: Reloading the URDF is not currently supported.

  7. Understand ros2_control introspection topics

    master

    The controller_manager publishes registered variables and execution statistics over specific ROS 2 topics.

    Variable Introspection Topics

    These topics publish the state of variables registered via REGISTER_ROS2_CONTROL_INTROSPECTION. They are published at the end of every update cycle if there is at least one subscriber.

    • ~/introspection_data/full: Publishes the full data (names and values) in a single message. Best for command-line tracking or custom visualization tools.
    • ~/introspection_data/names: Publishes the names of registered variables. This is only published when variables are registered or unregistered.
    • ~/introspection_data/values: Publishes the values of the registered variables.

    Performance Tip: For high-frequency data, use the names and values topics separately to minimize data transfer and storage overhead.

    Execution Statistics Topics

    These topics are used to monitor real-time loop behavior, such as execution time and periodicity of hardware read/write cycles and controller update cycles. This is critical for ensuring hardware meets strict real-time deadlines.

    • ~/statistics/full: Full statistics data (names and values) in one message.
    • ~/statistics/names: Names of the statistics variables (published on registration/unregistration).
    • ~/statistics/values: Values of the statistics variables.

    Note: A summary of these statistics is also published to the standard /diagnostics topic.

  8. Configure Joint Command and State Interfaces

    master

    The <joint> tag is used to group interfaces for physical robot joints or actuators.

    • Command Interfaces: Used to set goal values for the hardware. You can specify a data_type and optional parameters like min, max, and initial_value.
    • State Interfaces: Used to read the current state of the hardware.

    All joints defined in the <ros2_control> tag must be present in the URDF received by the controller manager. State interfaces can be published to ROS topics using the joint_state_broadcaster.

  9. What are Semantic Components in ros2_control

    master

    Semantic Components are abstractions used to streamline the configuration of common hardware interfaces. They wrap the mechanisms required to claim or release specific hardware interfaces, allowing developers to work with high-level device concepts rather than raw interface names.

    There are two primary base classes for defining these components:

    • semantic_components::SemanticComponentInterface: Used to define semantic components for read-only devices (sensors).
    • semantic_components::SemanticComponentCommandInterface: Used to define semantic components for write-only devices (actuators/commandable devices).

  10. Use Mock Components for offline testing

    master

    Mock components are trivial simulations of hardware components (System, Sensor, and Actuator) used for offline testing of the ros2_control framework. They provide ideal behavior by mirroring commands to their states, allowing you to test controllers, broadcasters, launch files, and integrations (like MoveIt) without physical hardware access.

    Key benefits include:

    • Testing the entire ros2_control "piping" without hardware.
    • Reducing debugging time on physical hardware.
    • Simulating hardware failures (e.g., loss of feedback) or open-loop configurations.

  11. Run controllers asynchronously in ros2_control

    master

    You can run controllers asynchronously to prevent long-running or blocking update() calls from affecting the periodicity of the main controller manager control loop. This is useful when a controller's execution time exceeds the available time within the controller manager's update_rate period.

    Asynchronous support is transparent to the controller implementation; any existing controller can be run asynchronously by setting the is_async parameter to true in its configuration.

    example_async_controller:
  ros__parameters:
    type: example_controller/ExampleController
    is_async: true

  12. Understand the three types of hardware components in ros2_control

    master

    In the ros2_control framework, hardware components are abstractions of physical hardware. There are three primary types of hardware components you can implement:

    1. Actuator: Represents a single degree of freedom or a single controllable unit (e.g., a motor).
    2. Sensor: Represents a device that provides data about the environment or the state of the system (e.g., an encoder or IMU).
    3. System: Represents a collection of actuators and sensors that are physically or logically grouped together (e.g., a complete robot arm or a mobile base).

    When designing your hardware interface, choose the type that best matches the physical entity you are abstracting.