diff --git a/design_drafts/example_ros2_control_URDF.md b/design_drafts/example_ros2_control_URDF.md new file mode 100644 index 0000000..3dce6a2 --- /dev/null +++ b/design_drafts/example_ros2_control_URDF.md @@ -0,0 +1,292 @@ +# ROS2 Control Components Architecture and URDFs + +## Architecture + +![ros2_control Components Achitecture][ros2_control_arch_ressource_manager] + +[ros2_control_arch_ressource_manager]: images/ResourceManager_ds.png "ROS2 Control - Components Architecture" + +## URDF Examples + +ros2_control implements following robot/robot-cell architectures: + +1. Industrial Robots with only one interface +2. Industrial Robots with multiple interfaces used at the same time +3. Industrial Robots with multiple interfaces (can not be used at the same time) +4. Industrial Robots with sensor integrated in the robot controller +5. Industrial Robots with sensor connected to ROS computer +6. Modular Robots with separate communication to each actor +7. Modular Robots with separate communication to each actor Multi joints (Transmissions +8. Example) +8. Sensor only + +#### 1. Industrial Robots with only one interface + * the communication is done using proprietary API + * Data for all joints is exchanged at once + * Examples: KUKA RSI + +```xml + + + ros2_control_demo_hardware/2DOF_System_Hardware_Position_Only + 2 + 2 + + + ros2_control_components/PositionJoint + True + -1 + 1 + + + ros2_control_components/PositionJoint + True + -1 + 1 + + +``` + +#### 2. Industrial Robots with multiple interfaces used at the same time + * the communication is done using proprietary API + * Data for all joints is exchanged at once + * Examples: KUKA FRI, ABB Yummy, etc. + +```xml + + + ros2_control_demo_hardware/2DOF_System_Hardware_MultiInterface + 2 + 2 + + + ros2_control_components/GenericJoint + position + velocity + effort + True + True + -1 + 1 + + + ros2_control_components/GenericJoint + position + effort + True + True + -1 + 1 + + +``` + +#### 3. Industrial Robots with multiple interfaces (can not be used at the same time) + * the communication is done using proprietary API + * Data for all joints is exchanged at once + * Examples: Schunk LWA4p + +```xml + + + ros2_control_demo_hardware/2DOF_System_Hardware_MultiInterface_Limited + 2 + 2 + + + ros2_control_components/GenericJoint + position + velocity + False + True + -1 + 1 + + + ros2_control_components/GenericJoint + position + velocity + False + True + -1 + 1 + + + +``` + +#### 4. Industrial Robots with sensor integrated in the robot controller + * the communication is done using proprietary API + * Data for all joints is exchanged at once + * Sensor data are exchanged together with joint data + * Examples: KUKA RSI with sensor connected to KRC + +```xml + + + ros2_control_demo_hardware/2DOF_System_Hardware_Sensor + 2 + 2 + + + ros2_control_components/PositionJoint + True + -1 + 1 + + + ros2_control_components/PositionJoint + True + -1 + 1 + + + ros2_control_components/ForceTorqueSensor + kuka_tcp + -5 + 1 + + +``` + +#### 5. Industrial Robots with sensor connected to ROS computer + * the communication is done using proprietary API + * Data for all joints is exchanged at once + * Sensor data are exchanged independently + * Examples: KUKA RSI and FTS connected to ROS-PC + +```xml + + + ros2_control_demo_hardware/2DOF_System_Hardware_Sensor + 2 + 2 + + + ros2_control_components/PositionJoint + True + -1 + 1 + + + ros2_control_components/PositionJoint + True + -1 + 1 + + + + + ros2_control_demo_hardware/2D_Sensor_Force_Torque + 2 + + + ros2_control_components/ForceTorqueSensor + kuka_tcp + -5 + 1 + + +``` + +#### 6. Modular Robots with separate communication to each actor + * the communication is done on actuator level using proprietary or standardized API (e.g. canopen_402) + * Data for all actuators is exchanged separately from each other + * Examples: Mara, Schunk LWA4p (it is possible by splitting ros_canopen) + +```xml + + + ros2_control_demo_hardware/Actuator_Hadware_1DOF + 1.23 + 3 + + + ros2_control_components/PositionJoint + True + -1 + 1 + + + + + ros2_control_demo_hardware/Actuator_Hadware_1DOF + 1.23 + 3 + + + ros2_control_components/PositionJoint + True + -1 + 1 + + +``` + +#### 7. Modular Robots with separate communication to each actor Multi joints (Transmission Example) + * the communication is done on actuator level using proprietary or standardized API (e.g. canopen_402) + * Data for all actuator is exchanged separately from each other + * Examples: Wrist of a humanoid robot + +```xml + + + ros2_control_demo_hardware/Actuator_Hadware_MultiDOF + 1.23 + 3 + + + ros2_control_components/PositionJoint + True + -1 + 1 + + + ros2_control_components/PositionJoint + True + -1 + 1 + + + transmission_interface/SomeComplex_2x2_Transmission + + positon + + + positon + + + 1 + + + 1 + + + +``` + +#### 8. Sensor only + * the communication is done on sensor level using proprietary or standardized API + * Examples: Camera, ForceTorqueSensor, Distance Sensors, IMU etc.. + +```xml + + + ros2_control_demo_hardware/Generic_Sensor_MultiDOF + 2 + + + ros2_control_components/GenericSensor + velocity + acceleration + -1 + 1 + + + ros2_control_components/GenericSensor + image + 0 + 255 + + +``` diff --git a/design_drafts/hardware_interface.md b/design_drafts/hardware_interface.md new file mode 100644 index 0000000..7875ae3 --- /dev/null +++ b/design_drafts/hardware_interface.md @@ -0,0 +1,294 @@ +# Structure of Hardware Interfaces + +The following shall discuss the design of data structures in the `hardware_interface` package for ROS2. +The document deals only with hardware description, but this also depends on [controllers execution management design](controller_execution_management.md). +As of today (ROS1), a `robot` is a fundamental and rigid structure that handles any hardware. +Therefore, it is impossible to extend it with additional hardware, like sensors, actuators, and tools, without coding. +This design tries to achieve the following: + +* Consistent naming of classes with the wording used in control theory (should simplify starting for new users); +* Logical implementation of relations between robots, sensors, actuators and finally controllers (should simplify starting for new users); +* Easy extension of a robot with additional hardware (no need for coding/compilation). + + +## Motivation + +The `RobotHW` class in ROS1 is the basic structure for representing any hardware, i.e. robots, sensors, and actuators. +From the control theory perspective, a robot is an assembly with one or more sensors and actuators. +Therefore we should strive such a design, primarily because it provides a few pleasing side effects: + +* Simple extension with additional hardware (e.g., extending an industrial robot with an additional sensor on the TCP ); +* Dynamic extension of a robot with other equipment (e.g., tool changers); +* Reuse of hardware definitions and interfaces without a need for coding and compiling of the hardware interfaces. + +## Nomenclature + +### Logical Components + +#### Robot + +A robot is logically represented with the `Robot` class. +This structure has at least two sub-components, i.e., sensors or actuators. +It generally represents any composition of `Robot`, `Sensor`, or `Actuator` structures. +Specific implementation in `*Hardware`-classes take care to read/write data to physical hardware/devices. + +#### Sensor + +A sensor in a robotic system is represented with the `Sensor` class. +Only data reading is possible from this type of hardware. +Therefore, no resource conflict is possible, and this is not checked. + +#### Actuator Hardware + +An actuator in a robotic system is represented with the `Actuator` class. +Data writing and reading are possible for this type of hardware. +A capability of an actuator to know its state has to be stated explicitly with a flag. +Resource conflict should be strictly checked, managed, and protected (e.g., by a key or hash provided by a specific controller). +The `Actuator` and `Robot` classes' main difference is that the `Actuator` class represents compact devices with, usually, only one degree of freedom. +An example of an actuator would be a robot joint or TCP tool which can rotate. + + +### Hardware components + +#### Robot Hardware + +`RobotHardware` class is per-hardware specific class. +This means that one can have a specific class for specific communication protocol on the logical level (e.g., KUKA RSI). +This class is to be used when data are received and sent to a robot's internal controller in one message. +This is usual for industrial robots. +If communication to robot's joints uses separate logical communication channels, `SensorHardware` or `ActuatorHardware` classes should be used. +`RobotHardware` class, as well as all other `*Hardware` classes, implement the logic for initialization, starting, stoping, and halting the specific hardware. + +#### Sensor Hardware + +Logical communication to a physical sensor is implemented in `SensorHardware` class. +Only data reading is possible for this type of hardware. + +#### Actuator Hardware + +`ActuatorHardware` class implements the logical communication protocol for specific hardware. +Using this class one can write, and if enabled, read the data from a hardware device. + + +## Package and Class Structure + +The following subsections describe the internal class structure of `ros2_control`. +The figure at the end of this section gives a complete overview with examples. + +This structure has the following intentions: + +1. `Robot` class should not be the basic class anymore since we also want to integrate simpler structures like sensors and 1 DoF actuators. +1. Internal data structures should be agnostic of specific interface types and data this interface manages. An important part for this is [Flexible Joint State Message](flexible_joint_states_msg.md) data type. +1. Users should be able to use Sensors and Actuators directly as well as bundle them to a robot. +1. The data structure should enable management of communication with a robot at once (e.g., KUKA RSI communication) and also separating it into multiple `Sensors` and `Actuators` (`Joints`) (e.g., Schunk LWA4p which uses ros_canopen) where each of them has a separate communication channel. + +The classes are separated in following logical packages: + +1. `ros2_control_core` provides a core components in `ros2_control` system. +Those components depend on each other and serve as a basic structure to provide easier integration for a user. +1. `ros2_control_components` provides a digital representation of components used in a robotic system. +1. `ros2_control_hardware` provides a logical protocol to talk with the hardware. +These classes can be seen as a "connection" between a digital model from `ros2_control_components` and a specific communication interface to real hardware. +1. `ros2_control_communication_interfaces` defines structures of specific communication interfaces to enable straightforward integration for the end-users. + + +### `ros2_control_core` + +The package `ros2_control_core` implements central components of ros2_control system. +Those components serve as an intelligent backend and connector between the digital model, communication protocol, and communication interface. +These components should enable the user to focus on implementing specific logic for its robot and, if needed, its digital representation. + +The `Component` class is on the base of any robot or device in `ros2_control`. It enables a connection between the ROS2 world and the hardware communication layer. +The `SimpleComponent` class provides an additional abstraction layer for `Actuator`, and `Sensor` classes since those share specific members who should not be part of the `Robot` class. +An end-user should never use or extend these two classes. +The classes `Sensor` and `Actuator` are first level classes that can be used by a user. +They define only a basic structure and should be extended for a specific type of a sensor (e.g., ForceTorqueSensor class) and actuator (e.g., PositionActuator). +The `Robot` class is the complex class that holds references for its `Sensor`, `Actuator`, and other `Robot` classes in a case of combined robot hardware (e.g., mobile manipulator). + +The `ComponentHardware` class is the counterpart of the `Component` class for `*Hardware` components, which implement specific logic for hardware. + +### `ros2_control_components` + +The package `ros2_control_components` models hardware components of which are used by the `ros2_control` framework. +An exmple for those classes are `ForceTorqueSensor`, `PositionActuator`, `VelocityActuator`, etc. +These classes are used for storing run-time data and for access from controllers. + +### `ros2_control_hardware` + +The package `ros2_control_hardware` implements specific abstractions for hardware types. +An example of such a class would be `ForceTorqueSensorHardware`, which knows how specific hardware is used (e.g., every sensor should access to ist calibration matrix). +Therefore, this package provides equivalent classes to those in `ros2_control_components`, but defines what functionalities internal model is expecting from specific hardware. + +### `ros2_control_communication_interfaces` + +The package `ros2_control_communication_interfaces` defines some standard communication interfaces used for control of the robots to cut the integration time for the end-users. + +### Class Diagram + +The following class diagram shows the internal structures of `ros2_control`. +In blue are marked exampole components which extendnd the basic components. + +![ROS2 Control Class Diagram][ros2_control_core_diagram] + +## Using `ros2_control` With a new Robot + +The process of making a new robot `ros2_control` compatible is depicted in the flow chart hereunder. +One needs to do the following steps: + +1. Check if needed `HardwareCommunicationInterface` is already integrated into `ros2_control`, and if not, it is recommended to do it. +For this, get in touch with people responsible for the `ros2_control_hardware_comunication` package. +2. Check if needed `HardwareInterface`, i.e., logical part of the communication with the robot, exists and if not implement it. +This class has to inherit the `ComponentHardwareInterface` interface. +3. Check if all types of `Sensor` and `Actuator` classes exist in `ros2_control_components` (or some third-party repository) and if not get in touch with people responsible for the repository and decide where to implement it. +4. Check `ros2_control_demo` repository, for example, files and templates to create YAMLs, URDF, and launch files for your robot. + +![ROS2 Control - Enabling a new Robot][ros2_control_new_robot] + + +## Example use-case + +The reasoning behind this structure is based on the abstraction of functionality and hardware access for multiple kinds of robots used with and without additional sensors. +To extend the robot with additional actuators follows the same logic. + +For better understanding, please consider the following use-case: +* In a ROS-based factory, there is a process which needs force-controlled robots. +* Following hardware is provided: + * Robot1 with "batch" interface for communication (e.g., KUKA robots with RSI); + * Robot2 with an interface where each joint can be addressed separately (e.g., Schunk LWA4p with canopen); + * Sensor1 with a proprietary protocol for communication (e.g., ATI Force-Torque Sensors with CAN interface); + * Sensor2 with a different proprietary protocol for communication (e.g., Schunk FTC50 sensor with CAN interface). + +* The Robot1 (KUKARobot) is then used as follows: + * A new class `KUKA_RSI_HardwareInterface` implementing RSI communication protocol for KUKA robots and extending `TCP/IP_HWCommunicaitonInterface` is written. + * To start the robot, a YAML configuration for `Robot` class needs to be written. + This file would look something like: + ``` + RobotKUKA: + name: "KUKA KR5 arc" + RobotHardware: + type: "kuka_driver/KUKA_RSI_HardwareInterface" + HardwareCommunicationInterface: + rsi_type: 4 #RSI-Fast with 4ms loop + interface: eth_kuka + interface_ip: 192.168.1.1 + + # Parameters for Robot class + joints: [joint1, joint2, joint3, joint4, joint5, joint6] + actuators: + joint1: + name: joint1 + type: "ros2_control_components/PositionActuator" + n_dof: 1 + max_values: [PI] + min_values: [-PI] + joint2: + ... + sensors: + joint1: + name: joint1 + type: "ros2_control_components/PositionSensor" + ... + ``` + +* The Robot2 (Schunk) is then used as follows: + * To use this robot, one can reuse `canopen_motor_HWCommunicationInterface` implemented for communication with canopen motors (Profile 402). + * Therefore, the YAML configuration of `Robot` class is a bit longer. + This file would look something like: + ``` + RobotSchunk: + name: "Schunk LWA4p" + + # Parameters for Robot class + joints: [joint1, joint2, joint3, joint4, joint5, joint6] + actuators: + joint1: + name: joint1 + type: "ros2_control_components/PositionActuator" + n_dof: 1 + max_values: [PI] + min_values: [-PI] + ActuatorHW: + type: "ros_canopen/canopen_motor_HWCommunicationInterface" + interface_path: can0 + socket: true + can_id: 3 + profile: 402 + eds_file: "schunk_lwa4p/config/Schunk_0_63.dcf" + joint2: + ... + sensors: + joint1: + name: joint1 + type: "ros2_control_components/PositionSensor" + ... + ``` + +* The Sensor1 (ATI FTS with CAN) is integrated as follows: + * A new class `ATI_ForceTorqueSensorHW_CAN` which extends `ForceTorqueSensorHW` is written. + This class implements ATI's communication protocol, e.g., fetching the calibration matrices, calculation of FT-data from strain gauge values, etc. + This class uses `Generic_CAN_HWCommunicationInterface` to be able to dynamically load specific CAN-device library depending on the manufacturer of used CAN adapter (e.g., PEAK, ESD, ...). + * To use this class by ROS, a YAML configuration for `ForceTorqueSensor` class, which provides high-level functions (e.g., noise filters, offset, and gravity compensation), needs to be written. + This file would look something like: + ``` + SensorATI: + name: "ATI Force Torque Sensor" + SensorHardware: + type: "ati_force_torque_sensors/ATI_ForceTorqueSensorHW_CAN" + data_pull_frequency: 1000 #Hz + HardwareCommunicationInterface: + type: "PEAK_CAN_HWCommunicatonInterface" + path: can0 + base_id: 0x20 + + # Parameters for ForceTorqueSensor class + data_publish_frequency: 200 #Hz + sensor_frame: "fts_reference_link" + robot_base_frame: "robot_base_link" + auto_init: true + offset: + is_static: false #Caculate always sensor offen on start + filters: + - MovingMean: + - device: 3 + - ThresholdFilter: + - linear: + - x: 2 + ... + ``` + +* The Sensor2 (Schunk FTC50 with CAN) is integrated as follows: + * A new class `Schunk FTC50_ForceTorqueSensorHW_CAN` which extends `ForceTorqueSensorHW` is written. + * Other steps are the same as for Sensor1. + This first part of the configuration would change to something like: + ``` + SensorSchunk: + name: "Schunk Force Torque Sensor" + SensorHardware: + type: "schunk_force_torque/FTC50_ForceTorqueSensorHW_CAN" + ... + ``` + +Now there is a possibility to combine the hardware as needed: + * The example file for Robot1 (KUKARobot) and Sensor2 (Schunk FTC50 with CAN): + ``` + RobotSensorKUKASchunk: + name: "KUKA KR5 arc with Schunk FTC50 on TCP" + robots: + RobotKUKA: + # Description from above + + sensors: + SensorSchunk: + # Description from above + ``` + +### Class Diagram of the Example + +![ROS2 Control Class Diagram][ros2_control_example_diagram] + + + +[ros2_control_core_diagram]: images/ros2_control_core_diagram.svg "ROS2 Control - Class Diagram" +[ros2_control_example_diagram]: images/ros2_control_example_diagram.svg "ROS2 Control - Example" +[ros2_control_new_robot]: images/ros2_control_new_robot.svg "ROS2 Control - Enabling a new Robot" +[controllers execution mangagemnt design]:https://github.com/Karsten1987/roadmap/blob/controller_execution_management/design_drafts/controller_execution_management.md diff --git a/design_drafts/images/ResourceManager_ds.png b/design_drafts/images/ResourceManager_ds.png new file mode 100644 index 0000000..e011af3 Binary files /dev/null and b/design_drafts/images/ResourceManager_ds.png differ diff --git a/design_drafts/images/ros2_control_core_diagram.svg b/design_drafts/images/ros2_control_core_diagram.svg new file mode 100644 index 0000000..85c7415 --- /dev/null +++ b/design_drafts/images/ros2_control_core_diagram.svg @@ -0,0 +1,3 @@ + + +
ros2_control_core
ros2_control_core
ros2_control_components
ros2_control_components
ros2_control_communication_interfaces
ros2_control_communication_interfaces
ros2_control_hardware
ros2_control_hardware
Use
Use
Use
Use

Robot

Robot

<<Template>>
Sensor

<<Template>>...

<<Template>>
SimpleComponent



<<Template>>...

<<Template>>
Actuator

<<Template>>...
Extends
Extends
Extends
Extends

<<Template>>
Component

<<Template>>...
Extends
Extends
Relation
Relation
1..n
1..n
1
1
Relation
Relation
1..n
1..n
1
1

ForceTorqueSensor


ForceTorqueSensor

<<Template>>
ComponentHardware

<<Template>>...

<<Template>>
ActuatorHardware

<<Template>>...

<<Template>>
SensorHardware

<<Template>>...
Extends
Extends
Extends
Extends

<<Template>>
RobotHardware

<<Template>>...
Use
Use
Use
Use

<<Template>>

ForceTorqueSensorHardware



<<Template>>...

<<Template>>
HardwareCommunicationInterface

<<Template>>...
Use
Use

<<Template>>
CAN_CommunicationInterface

<<Template>>...
Extends
Extends

<<Template>>
RS485_CommunicationInterface

<<Template>>...
Extends
Extends

<<Template>>
TCP/IP_CommunicationInterface

<<Template>>...
Extends
Extends
Extends
Extends

PositionActuator



PositionActuator

PositionSensor


PositionSensor
Extends
Extends
Extends
Extends
not complete list of components
not complete list of...
not complete list of hardware types
not complete list of hard...Viewer does not support full SVG 1.1 \ No newline at end of file diff --git a/design_drafts/images/ros2_control_example_diagram.svg b/design_drafts/images/ros2_control_example_diagram.svg new file mode 100644 index 0000000..a743bc0 --- /dev/null +++ b/design_drafts/images/ros2_control_example_diagram.svg @@ -0,0 +1,3 @@ + + +
Extends
Extends
some packgaes with protocol implementations
some packgaes with protocol implementations
Use
Use
schunk_fts_drivers
schunk_fts_drivers
Use
Use
kuka_drivers
kuka_drivers
Use
Use
ati_fts_drivers
ati_fts_drivers
ros2_control_core
ros2_control_core
Use
Use
ros2_control_components
ros2_control_components
ros2_control_communication_interfaces
ros2_control_communication_interfaces
Use
Use
ros2_control_hardware
ros2_control_hardware
Use
Use
Use
Use
Use
Use
Use
Use
Use
Use

Robot

Robot

<<Template>>
Sensor

<<Template>>...

<<Template>>
SimpleComponent



<<Template>>...

<<Template>>
Actuator

<<Template>>...
Extends
Extends
Extends
Extends

<<Template>>
Component

<<Template>>...
Extends
Extends
Relation
Relation
1..n
1..n
1
1
Relation
Relation
1..n
1..n
1
1

ForceTorqueSensor


ForceTorqueSensor

<<Template>>
ComponentHardware

<<Template>>...

<<Template>>
ActuatorHardware

<<Template>>...

<<Template>>
SensorHardware

<<Template>>...
Extends
Extends
Extends
Extends

<<Template>>
RobotHardware

<<Template>>...
Use
Use
Use
Use

<<Template>>

ForceTorqueSensorHardware



<<Template>>...

ATI_ForceTorqueSensorHW_Can

ATI_ForceTorqueSensorHW_Can

<<Template>>
HardwareCommunicationInterface

<<Template>>...
Use
Use

<<Template>>
CAN_CommunicationInterface

<<Template>>...
Extends
Extends

<<Template>>
RS485_CommunicationInterface

<<Template>>...
Extends
Extends

<<Template>>
TCP/IP_CommunicationInterface

<<Template>>...
Extends
Extends

<<Template>>
ProfiNet_CommunicationInterface

<<Template>>...

<<Template>>
Modbus_RS485_CommunicationInterface

<<Template>>...
Extends
Extends

<<Template>>
canopen_CommunicationInterface

<<Template>>...
Extends
Extends

<<Template>>
Generic_CAN_CommunicationInterface

<<Template>>...
Extends
Extends

PEAK_CAN_HWCommunicationInterface

PEAK_CAN_HWCommunicationInterface

canopen_motor_HWCommunicationInterface

canopen_motor_HWCommunicationInterface
Extends
Extends
Use
Use

ATI_ForceTorqueSensorHW_Modbus_RS485

ATI_ForceTorqueSensorHW_Modbus_RS485
Extends
Extends

KUKA_FRI_HardwareInterface

KUKA_FRI_HardwareInterface
Use
Use
Extends
Extends

Schunk FTC50_ForceTorqueSensorHW_CAN

Schunk FTC50_ForceTorqueSensorHW_CAN

PositionActuator



PositionActuator

PositionSensor


PositionSensor
Extends
Extends

KUKA_RSI_HardwareInterface

KUKA_RSI_HardwareInterface

EDS_CAN_HWCommunicationInterface

EDS_CAN_HWCommunicationInterface
Extends
Extends
not complete list of components
not complete list of...
not complete list of hardware types
not complete list of hard...
This packages probably do not exist. They are here just for example purpose!
This packages probably...Viewer does not support full SVG 1.1 \ No newline at end of file diff --git a/design_drafts/images/ros2_control_new_robot.svg b/design_drafts/images/ros2_control_new_robot.svg new file mode 100644 index 0000000..2c48f65 --- /dev/null +++ b/design_drafts/images/ros2_control_new_robot.svg @@ -0,0 +1,3 @@ + + +
Wish to make a new robot `ros2_control` compatible
Wish to make a new robot...
Check the class diagram of `ros2_control` and take a look at the design document for better understanding of follwowing steps
Check the class diagram of `...
Which hardware interface is you robot using?

Make sure you have documentation about it and you understand how you can communicate to the robot.
Which hardware interface is...
Does implementation of communication protocol you need exist in `ros2_control_communication` package?
Does implementation of communication pro...
Yes
Yes
Does communication protocol you need exist as a ROS2 package?
Does communication protocol you need exi...
No
No
Does communication protocol you need exist as a ROS1 package?
Does communication protocol you need exi...
No
No
No
No
Search the Internet for open-source library which implements the protocol you need or create a new one by yourself.
Search the Internet for open...
You have to port/integrate the protocol as ROS2 package.

Share your intention on ROS Discourse and issue tracker of the ROS1 package.

The ROS2 documentation is your best friend!
You have to port/integrate t...
Yes
Yes
You need to create a new library
"<Protocol>_HardwareCommunicatonInterface" whcih implements `HardwareCommunicaitonInterface` interface.

If applicable inherit existing CommunicaitonInterface in the `ros2_control_communication_interfaces` package.

Open a new issue in that package and tell other people about your intention.
You need to create a new library...
Yes
Yes
Congratulation!!


Now find details on logical part of communication with your robot.
Congratulation!!...
Does implementation of logical protocol (i.e. Hardware Interface) exist in the package `ros2_control_hardware_interface`?
Does implementation of logical protocol...
Does logical protocol you need exist as a ROS2 package?
Does logical protocol you need exist as...
No
No
Does logical protocol you need exist as a ROS1 package?
Does logical protocol you need exist as...
No
No
No
No
Search the Internet for open-source library which implements the protocol you need or create a new one by yourself.
Search the Internet for open...
You have to port/integrate the protocol as ROS2 package.

Share your intention on ROS Discourse and issue tracker of the ROS1 package.

The ROS2 documentation is your best friend!
You have to port/integrate t...
Yes
Yes
You need to create a new library
"<HW>_<Protocol>_HardwareInterface" whcih implements `ComponentHardwareInterface` interface.

If applicable Inherit existing category (e.g. ForceTorqueSensor) in the `ros2_control_hardware_interface` package.

Open a new issue in that package and tell other people about your intention.
You need to create a new library...
Yes
Yes
Does "HardwareInterface" hardware category (e.g. ForceTorqueSensor) exists in the package `ros2_control_hardware_interface?
Does "HardwareInterface" hardware catego...
Yes
Yes
Propose a new "category" in the package "ros2_control_hardware_interface".

If the category is very specific to your needs maybe you wish to create it in separate package.

Open a new issue in that package and tell other people about your intention.
Propose a new "category" in the package "ros2...
No
No
Yes
Yes
Congratulation!!
Does your robot uses "batch" communication?
(i.e., communicates with all joints in one message)
Congratulation!!...
Yes
Yes
Check package `ros2_control_demo_batch` files  and description in `ros2_control_demo_robot` package.

Check package `ros2_control_demo_batch` files...
Check package `ros2_control_demo_modular` files  and description in `ros2_control_demo_robot` package.

Check package `ros2_control_demo_modular` file...
No
No
Are there all types of Actuators and Sensors in `ros2_control_components` package you need to model your robot?
Are there all types of Actuators and Sen...
Yes
Yes
Write YAML, URDS and launch files for your robot and have a fun!

P.S. Examples in `ros2_control_demo` package could be helpfull.

Write YAML, URDS and launch files for your rob...
Open an issue in `ros2_control_components` repository and share your problem/intention with people there.

If you are creating some special robot/component type than you will need to create a new package for it.

Open an issue in `ros2_control_compo...
No
NoViewer does not support full SVG 1.1 \ No newline at end of file