Project

General

Profile

Actions

Task #194

closed

Task Group #197: [Dev] xela_models ros2 Apps Development

[Dev] Create xela_taxel_joint_state_publisher as a ros2_control controller

Added by Sanghoon Lee 3 months ago. Updated 2 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Start date:
01/13/2026
Due date:
% Done:

100%

Estimated time:
Product Code:
uAi SW:
Issue closed :
01/23/2026

Description

Create a ros2_control controller, xela_taxel_joint_state_publisher, that publishes a JointState stream specifically for the XELA Taxel sensor.
This controller filters incoming JointState messages or initializes joint positions from a configured list, then publishes a unified JointState topic.
This controller is designed to run within ros2_control and be managed by the controller_manager.

As a first step, this publisher supports the Allegrohand v4 (ros2_control type) and 2F-85 (uSPr2F) models.
It is spawned by the controller manager when the robot is started, and upon startup, it publishes the JointState of the Taxel sensor of the specified model.


Create xela_taxel_joint_state_publisher

xela_taxel_joint_state_publisher/
├── CMakeLists.txt
├── config
│   ├── list_2f_gripper_joint.yaml
│   ├── list_allegrohand_joint.yaml
│   └── xela_taxel_jsp_config.yaml
├── controller_plugins.xml
├── include
│   └── xela_taxel_joint_state_publisher
│       └── xela_taxel_joint_state_publisher.hpp
├── package.xml
└── src
    └── xela_taxel_joint_state_publisher.cpp

1. Overview

xela_taxel_joint_state_publisher is a ros2_control controller that publishes a filtered JointState stream for XELA taxel sensors. The controller filters incoming JointState messages or initializes joint positions from configured lists, then publishes a consolidated JointState topic for downstream applications. It is designed to run inside ros2_control and be managed by controller_manager.

2. Goals

- Provide a ros2_control controller that publishes taxel JointState for a selected device profile.
- Support multiple device profiles (e.g., allegrohand, 2f_gripper) from a single YAML config.
- Allow configuration of output topic, publish rate, input sources, and joint ordering.
- Operate without impacting the primary MoveIt control JointState stream.
- Be robust to missing inputs by using initial positions where available.

3. Non-Goals

- Parsing URDFs or XACROs directly (handled by upstream nodes or config files).
- Dynamically reloading device profiles at runtime (restart/reload expected).
- Publishing non-joint sensor data (force, tactile values, etc.).

4. Users and Use Cases

4.1 Users

- Robotics developers integrating XELA taxel sensors into MoveIt Pro configurations.
- Operators running robots that require a separate full-model joint state stream.

4.2 Use Cases

- Publish taxel joint states for a full robot model on /joint_states_full while keeping /joint_states lightweight for MoveIt.
- Publish taxel joint states for a 2-finger gripper package on /joint_states.
- Combine multiple taxel device profiles into one output stream.

5. Functional Requirements

5.1 Configuration

- Controller must read a YAML config file specified by config_yaml.
- Config supports device_profiles with keep_joints_files lists per profile.
- Config supports optional global parameters: output_topic, publish_rate, preserve_input_order, source_list.
- Controller accepts parameter device_profiles to select one or more profiles.

5.2 Input JointState Handling

- Controller subscribes to topics listed in source_list.
- If source_list is empty, the controller publishes using initial positions only.
- If a source topic equals output_topic, it is ignored to prevent loops.

5.3 Output JointState

- Output topic is output_topic (default /joint_states).
- Output includes name and position arrays. velocity and effort are only included if present in inputs.
- Output ordering:
- If ordered_keep_joints exists in config, it defines output order.
- Else if preserve_input_order is true and input received, use input order filtered to keep joints.
- Else output order follows merged keep_joints list.

5.4 Initial Positions

- Controller supports initial_positions per profile in config (optional).
- If no position has been received for a joint, initial position is used.

5.5 Package Path Resolution

- config_yaml supports package://<pkg>/path resolution using ament index.

6. Non-Functional Requirements

- ROS 2 Humble compatible.
- Real-time safe behavior: no blocking operations in update().
- Robust to missing inputs and config errors (log and fail gracefully on configure).
- Maintain deterministic output order per configuration.

7. Configuration Schema

7.1 Example

output_topic: /joint_states
publish_rate: 30.0
preserve_input_order: true
source_list:
  - /joint_states_full

device_profiles:
  allegrohand:
    keep_joints_files:
      - list_allegrohand_joint.yaml
  2f_gripper:
    keep_joints_files:
      - list_2f_gripper_joint.yaml

7.2 keep_joints_files

- Each file is YAML containing keep_joints: followed by a list of joint names.

8. Interface (Parameters)

Parameter Type Default Description
config_yaml string "" Path to config YAML (supports package://)
device_profiles string[] [] Profiles to load from config
output_topic string /joint_states Output JointState topic
source_list string[] [] Input JointState topics to merge
publish_rate double 30.0 Output publish frequency in Hz
preserve_input_order bool true Preserve input order when possible

9. Integration Requirements

- Controller must be listed under controller_manager in the target ros2_control YAML.
- Controller parameters must be defined under a top-level node matching controller name.
- Add controller to controllers_active_at_startup in MoveIt Pro config if required.

10. Failure Modes and Logging

- If config_yaml is missing or invalid, controller configuration fails.
- If device_profiles is empty or missing in config, configuration fails.
- If keep_joints resolves to empty, configuration fails.
- All failures must log clear error messages.

11. Testing Plan

- Unit-style validation via:
- Launch controller with valid config and verify output topic publishes expected joints.
- Launch controller without source_list and validate initial positions publish.
- Launch controller with invalid config and ensure configure fails gracefully.
- Integration validation with MoveIt Pro configuration:
- Confirm controller is listed by ros2 control list_controllers.
- Confirm output topic is populated with expected taxel joints.

12. Open Questions

- Should source_list allow wildcard or namespace expansion?
- Should publish be suppressed until at least one input message is received?
- Do we need runtime profile switching without controller restart?


config/control/ur5e_x2f_85.ros2_control.yaml Show

config/config.yaml Show


invokelee@🐙MoveIt Pro🐙:~/user_ws$ ros2 control list_controllers
force_torque_sensor_broadcaster        force_torque_sensor_broadcaster/ForceTorqueSensorBroadcaster                active
velocity_force_controller              velocity_force_controller/VelocityForceController                           inactive
robotiq_activation_controller          robotiq_controllers/RobotiqActivationController                             active
xela_taxel_joint_state_publisher       xela_taxel_joint_state_publisher/XelaTaxelJointStatePublisher               active
joint_state_broadcaster                joint_state_broadcaster/JointStateBroadcaster                               active
robotiq_gripper_controller             position_controllers/GripperActionController                                active
joint_trajectory_admittance_controller joint_trajectory_admittance_controller/JointTrajectoryAdmittanceController  inactive
servo_controller                       joint_trajectory_controller/JointTrajectoryController                       inactive
joint_trajectory_controller            joint_trajectory_controller/JointTrajectoryController                       active
invokelee@🐙MoveIt Pro🐙:~/user_ws$ ros2 topic info /joint_states -v
Type: sensor_msgs/msg/JointState

Publisher count: 2

Node name: xela_taxel_joint_state_publisher
Node namespace: /
Topic type: sensor_msgs/msg/JointState
Endpoint type: PUBLISHER
GID: 01.10.e6.cb.8e.80.fa.90.a8.dc.e6.8f.00.00.ef.03.00.00.00.00.00.00.00.00
QoS profile:
  Reliability: RELIABLE
  History (Depth): KEEP_LAST (1)
  Durability: VOLATILE
  Lifespan: Infinite
  Deadline: Infinite
  Liveliness: AUTOMATIC
  Liveliness lease duration: Infinite
Actions

Also available in: Atom PDF