new-hardware
Scaffold a ros2_control hardware component (System/Actuator/Sensor) + URDF <ros2_control> tag + bringup (controllers.yaml + launch), with pluginlib export and a test.
mkdir -p ~/.claude/commands && curl -fsSL https://raw.githubusercontent.com/harunkurtdev/ros2-claude-code-template/HEAD/.claude/commands/new-hardware.md -o ~/.claude/commands/new-hardware.mdnew-hardware.md
Scaffold a ros2_control hardware component and its bringup.
Argument handling (`$ARGUMENTS`):
1. `<package>` — existing package under `src/` (required).
2. `<ClassName>` — CamelCase hardware class (required).
3. `<kind>` — `system` (whole robot, `SystemInterface`),
`actuator` (`ActuatorInterface`), or `sensor` (read-only,
`SensorInterface`).
If anything is missing, ask before scaffolding.
Process:
1. Read the skill `ros2_control_hardware_interface` and the rules
`ros2_control_architecture.md` + `ros2_control_demos.md`; pick the
closest example in `~/nav2_ws/src/ros2_control_demos/` to mirror
(`example_1` system, `example_6` actuator, `example_5` sensor).
2. Create the plugin:
* `hardware/include/<package>/<snake_class>.hpp` — class deriving from
`hardware_interface::{System,Actuator,Sensor}Interface`, overriding
`on_init(HardwareComponentInterfaceParams)`, `on_configure`,
`on_activate`, `on_deactivate`, and `read()` / `write()`
(sensors: `read()` only, no command interfaces).
* `hardware/<snake_class>.cpp` — implementation + `PLUGINLIB_EXPORT_CLASS`
with the right `hardware_interface::*Interface` base.
* `<package>.xml` — pluginlib description, `base_class_type` matching.
3. Create the bringup + description:
* `description/ros2_control/<robot>.ros2_control.xacro` — the
`<ros2_control>` tag with `<hardware><plugin>` (== the alias) and the
joints' `<command_interface>` / `<state_interface>`.
* `bringup/config/<robot>_controllers.yaml` — `controller_manager`
with `update_rate` + `joint_state_broadcaster` + one command
controller.
* `bringup/launch/<robot>.launch.py` — robot_state_publisher +
`ros2_control_node` + spawners (broadcaster first).
* `test/test_<snake_class>.cpp` — load the URDF and check the
interfaces export.
4. Wire `CMakeLists.txt` / `package.xml`: deps `hardware_interface`,
`pluginlib`, `rclcpp_lifecycle`;
`pluginlib_export_plugin_description_file(hardware_interface <xml>)`;
install `description/` and `bringup/`.
5. Remind: `read()`/`write()` are the RT hot path — open device handles in
`on_activate`, not in the loop; no alloc/locks/blocking I/O there.
6. `pre-commit run --files <touched files>`.
7. Print: files created and
`ros2 launch <package> <robot>.launch.py` +
`ros2 control list_hardware_interfaces`.
The URDF `<plugin>` string must equal the pluginlib alias and
`PLUGINLIB_EXPORT_CLASS`; a `sensor` component must not export command
interfaces.Use proactively before opening a PR that adds or changes BehaviorTree.CPP nodes or BehaviorTree.ROS2 wrappers (RosActionNode/RosServiceNode/RosTopicPub/SubNode, TreeExecutionServer). Reviews a diff against BT.CPP v4 conventions — node base-class choice, non-blocking ticks, ports/blackboard typing, factory/plugin registration, XML v4, and the ROS 2 wrapper contract. Returns a punch list with file:line anchors, not a rewrite.
Use when a design decision touches Clean Architecture boundaries in a ROS 2 project — which layer a new behaviour belongs to, whether a port belongs in domain or application, whether a new node should be lifecycle-managed, whether to compose nodes or split packages. Returns an architectural recommendation with trade-offs, not implementation.
Use when a design decision touches the gz-sim ECS — where new state should live, which system phase should write it, how to avoid coupling, whether to add a component vs. a member variable, whether a new system should be split or merged with an existing one. Returns an architectural recommendation with trade-offs, not implementation.
Use proactively before opening any gz-sim PR. Reviews a diff against the project's C++17 style, ECS conventions, plugin registration patterns, CMake structure, test placement, Migration.md / Changelog.md expectations, and pre-commit configuration. Returns a punch list, not a rewrite.
Use proactively before opening a PR that adds or changes a ros2_control controller, broadcaster, or hardware component (incl. URDF <ros2_control> bringup). Reviews a diff against ros2_controllers / ros2_control_demos conventions — controller & hardware lifecycle, command/state interface configuration, real-time safety of update()/read()/write(), generate_parameter_library usage, pluginlib registration, chainable-controller correctness, URDF wiring, and tests. Returns a punch list with file:line anchors, not a rewrite.
Use proactively before opening any ROS 2 / Nav 2 PR. Reviews a diff against this template's Clean Architecture, ROS 2 communication, lifecycle, testing, and Nav 2 plugin conventions. Returns a punch list with file:line anchors, not a rewrite.
Use proactively before opening a PR that touches a VDA 5050 connector / fleet bridge. Reviews a diff against VDA 5050 v3.0.0 protocol compliance (topics, QoS, header rules, base/horizon, action state machine, schema validation) and the template's Clean Architecture for the MQTT↔Nav 2 bridge. Returns a punch list with file:line anchors, not a rewrite.
Build the colcon workspace (optionally a single package) and report the outcome.