ROS Net F/T Driver

netft_driver is a native ROS driver for ATI Ethernet Net F/T and Ethernet Axia force/torque sensors. It supports a standalone ROS 1 or ROS 2 node and a ROS 2 ros2_control sensor hardware plugin.

Features

• Publishes calibrated geometry_msgs/WrenchStamped data in N and Nm.
• Reports connection, sequence, receive-rate, and device-status diagnostics.
• Provides an explicit software-bias service.
• Integrates with the standard ROS 2 force-torque sensor broadcaster.
• Carries a reviewed private snapshot of the netft-cpp acquisition core.

Supported ROS distributions

* ROS 1 Noetic is end-of-life and supported from source only.

Installation

ROS 2

Replace lyrical with another supported ROS 2 distribution when required.

source /opt/ros/lyrical/setup.bash
mkdir -p ~/netft_ws/src
git clone https://github.com/netft/ros-netft.git ~/netft_ws/src/netft_driver
cd ~/netft_ws
rosdep install --from-paths src --ignore-src -r -y
colcon build --packages-select netft_driver
source install/setup.bash

ROS 1 Noetic

source /opt/ros/noetic/setup.bash
mkdir -p ~/netft_ws/src
git clone https://github.com/netft/ros-netft.git ~/netft_ws/src/netft_driver
cd ~/netft_ws
rosdep update --include-eol-distros
rosdep install --from-paths src --ignore-src -r -y
catkin_make
source devel/setup.bash

See the installation guide for prerequisites and package availability.

Quick start

ATI RDT permits one UDP client. Stop other RDT clients before starting the driver. The examples use 192.168.1.1, ATI’s factory-default static address; replace it with the address assigned to your sensor.

Standalone driver

ROS 2:

ros2 launch netft_driver netft.launch.py sensor_ip:=192.168.1.1
ros2 topic echo --once /netft/wrench

ROS 1:

roslaunch netft_driver netft.launch sensor_ip:=192.168.1.1
rostopic echo -n 1 /netft/wrench

The default bias service is /netft/bias. Bias changes the measurement zero; call it only when the sensor and connected mechanism are in a safe state.

ros2_control

The plugin class is netft_driver/NetFTHardwareInterface. Include the installed Xacro macro in the robot description managed by your controller manager:

```xml

<xacro:netft_ros2_control name=”wrist_netft_hardware”

File truncated at 100 lines see the full file

Contributing to ROS Net F/T Driver

Thank you for helping improve netft_driver. Bug reports, feature proposals, documentation fixes, tests, and code contributions are welcome.

Reporting issues

Search open and closed issues before filing a new report. Use the bug-report form for reproducible failures and the feature-request form for proposed behavior.

A useful bug report includes the driver revision, ROS distribution, operating system, installation method, sensor model, reproduction steps, expected and actual behavior, diagnostics, and relevant logs. Remove credentials and other sensitive information before posting.

Development environment

Pixi provides the repository-local test environments. Run the ROS-neutral C++ and policy suites with:

pixi run -e test core-configure
pixi run -e test core-build
pixi run -e test core-test
pixi run -e test unit

The native package and graph gates use only loopback fake sensors. Run every gate for each distribution affected by the change. For example:

pixi run ros1-harness
pixi run ros2-harness
pixi run -e noetic build
pixi run -e noetic smoke
pixi run -e jazzy build
pixi run -e jazzy smoke
pixi run -e jazzy ros2-control-smoke

The available Pixi environments are noetic, humble, jazzy, kilted, lyrical, and rolling. Native ROS installations may also be used; CI runs the complete supported source matrix.

Tests should verify executable behavior, protocol rules, ROS graph contracts, machine-readable output, or build metadata. Do not pin README, changelog, release-note, help, diagnostic, log, or error prose. Protocol bytes, serialized values, JSON keys, ROS interface names, and other machine-readable contracts remain valid test inputs and assertions.

Pull requests

Before opening a pull request:

1. Base the change on the latest main branch.
2. Keep the change focused and avoid unrelated formatting or refactoring.
3. Add or update tests for behavior changes.
4. Update user documentation when commands, parameters, interfaces, or safety behavior change. Repository content must be written in English.
5. Run the ROS-neutral C++ and policy suites plus the relevant ROS build, standalone smoke, and ros2_control smoke tests.
6. Complete the pull-request template and address CI results and review feedback.

Open an issue before starting a large feature or an interface-breaking change so the scope can be agreed upon first.

Core snapshot updates

1. Update and release netft-cpp first.
2. Copy only the library paths from an immutable upstream tag.
3. Preserve the netft namespace and the Apache-2.0 license.
4. Update src/core/UPSTREAM with the copied tag and commit.
5. Rerun the byte comparison and every snapshot and ROS test.
6. Keep ROS-specific changes out of src/core/; port reusable fixes upstream before copying them back.

Do not add an automated downloader or submodule for the core snapshot.

Physical sensor safety

The automated test suite does not require a physical sensor. Do not perform real-hardware testing for a contribution unless the sensor owner has explicitly authorized it.

ATI RDT permits only one UDP client, so stop other RDT clients before a hardware test. A software-bias operation changes the sensor zero and must only be performed when the sensor is stationary, unloaded, and safe. State in the pull request whether hardware was used, which checks were run, and whether bias was issued. Do not publish private network details or sensor identifiers.

License

Contributions are licensed under the repository’s Apache-2.0 License. The copied src/core/ snapshot retains the upstream license copy at src/core/LICENSE. Propose reusable core fixes upstream first, then copy them from a released immutable upstream revision.