-
Notifications
You must be signed in to change notification settings - Fork 8
Hardware Configuration
mep3 heavily relies on ros2_control as a hardware abstraction framework.
Therefore, most hardware configurations are placed in .urdf and .yaml files.
You can also check this post to better understand how ros2_control works.
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/resourceand have the same naming convention.
Important: It is necessary to have the same hardware primitives described for both, physical and simulated robots. Otherwise, they will likely not be compatible.
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.
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.
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.