// the find
ICube-Robotics/ethercat_driver_ros2
Hardware Interface for EtherCAT module integration with ros2_control
A ros2_control hardware interface that puts EtherCAT slaves on a ROS 2 robot without writing C++ for each device. Modules are described in YAML parameter files and loaded as plugins on top of the IgH EtherCAT master. It is aimed at lab and industrial integrators who already run Linux with a real-time kernel and EtherCAT hardware.
- The generic slave and CIA402 drive plugins are a sensible split. Most of the time a new drive is a parameter file change, and C++ is only needed for devices that break the model.
- The PDO and SDO layers are separated (ethercat_interface vs ethercat_manager), and SDO access is exposed as GetSdo/SetSdo ROS services. That means you can poke a live device from the command line without restarting the controller.
- The e-stop safety example and its test (test_ethercat_safety_driver.cpp) show the authors thought about safety-rated stops, not just happy-path motion. The example configs for Beckhoff EK1914 and EL1918 are useful starting points.
- Apache 2.0, a Zenodo DOI, and a Sphinx site with developer guides for CIA402 and domain construction. For a research-grade driver, the documentation is above average.
- Everything depends on the IgH EtherCAT master, which means a kernel module built against your kernel, a GPL dependency, and real-time kernel tuning. There is no SOEM or other userspace master option in the tree, so the setup cost is high before any ROS code runs.
- Test coverage looks thin from the tree: one file per package and no visible tests that drive a real bus. Most of the behaviour you care about (cycle timing, fault recovery, reconnects) is probably only exercised on hardware.
- The README is a pointer to external docs and gives no minimal working example. You have to read the Sphinx pages and an example YAML before you can see whether the driver fits your device.
- The YAML and xacro configuration is validated at load time rather than with a schema, so a typo in a PDO index or a wrong SDO key shows up as a runtime fault on the bus. That is a painful debugging loop on a physical robot.