Hardware Configuration

mep3 heavily relies on ros2_control as a hardware abstraction framework. Therefore, the most hardware configuration is placed in .urdf and .yaml files.

Hardware Interface

Hardware interfaces define primitives on how to interact with the hardware like joint position or GPIO output:

• The physical hardware interfaces are placed in mep3_hardware/resource. The files are named as [robot]_description.urdf.
• The simulated hardware interfaces are placed in mep3_simulation/resource and have the same naming convention.

Important: It is necessary to have the same hardware primitives described for both, physical and simulated robots. Otherwise, there is a high risk they will not be compatible.

Controllers

Controllers utilize primitives from hardware interfaces to implement a control behavior like differential drive or joint position control. Physical and simulated robots load the same controllers, from the same configuration files. The controller configurations are placed in mep3_hardware/resource and files are named as [robot]_controllers.yaml.

Non ros2_control Hardware Components

Not all hardware components can be interfaced through ros2_control. Other hardware components such as LCD, LiDAR, and cinch should be configured in the hardware_launch.py file.

Supporting New Hardware

Hardware components that we use almost every year are deeply integrated into mep3:

• wheel control (differential drive)
• Dynamixel motors,
• vacuum pumps,
• LCD,
• a cinch, and
• LiDAR.

In the case of new hardware components (used only one year), it is recommended to use the socketcan_bridge node. The ROS node creates topics for receiving and sending CAN messages. There is also a corresponding BT action <CanbusSend message="0x32;0x34" can_id="0x12345" /> that you can use from strategies.

If necessary, one can implement a ROS 2 node in Python or C++ to interact with the hardware.