Standard Nodes

Fast prototyping and development made simple

The standard node is designed for fast prototyping and small applications that do not require strong safety requirements. Perfect for getting started quickly with your force-torque sensor integration.

Learn more: ROS2 standard nodes documentation

Configuration Parameters

The standard node requires the following parameters:

Parameter	Description
`node_name`	Name assigned to the node, as well as the prefix for topics and services. It is also used to define the frame for the topics, for this reason, when working with URFDs, this parameter should match the prefix provided to the sensor XACRO.
`config_file`	Path to the JSON configuration file
`output_rate`	Controls reading mechanism (see details below)

Understanding output_rate behavior:

Important

The output_rate parameter controls if the reading mechanism is from the buffer or from the stream:

Positive value - Reading from the buffer timed by ROS2. Topic publishing rate matches the set output rate. The sensor update rate should be set higher than the desired output rate (sinc_length in Gen 0 and app_submode in Gen A).
Zero (0) - Reading from the stream. Topic publishing will be timed by the sensor update rate. Only supported in streaming interfaces.

Published Topics

Once running, the node publishes the following topics:

Topic	Message Type	Description
`<NODE_NAME>/bota_frame`	BotaFrame (see below)	Complete sensor data including status, wrench, IMU, temperature and timestamp
`<NODE_NAME>/bota_wrench`	WrenchStamped	Force and torque measurements from the sensor
`<NODE_NAME>/bota_imu`	Imu	Imu measurements from the sensor

Important

Topic Usage Recommendations:

For control applications: Use /bota_frame as it contains all sensor data from the same sampling time in a single message, ensuring temporal consistency.
For visualization and monitoring: The individual topics (/bota_wrench, /bota_imu) are provided for convenience with standard message types, making them easily compatible with tools like PlotJuggler and RViz.

Warning: Using data from multiple individual topics simultaneously may lead to temporal inconsistencies, as there’s no guarantee of synchronization between different topic subscriptions. The data points might come from different sampling times.

Note

Custom Message Type: BotaFrame (*) is a custom message type defined in the bota_driver package. This message type will be available in your workspace as long as the bota_driver package is properly installed and sourced.

BotaFrame Definition:

# Status information
bool throttled
bool overrange
bool invalid
bool raw

# Force and torque values in I.S. (same as /bota_wrench)
geometry_msgs/WrenchStamped wrench

# Imu values in I.S. (same as /bota_imu)
sensor_msgs/Imu imu

# Temperature in Celsius
float32 temperature

# Sensor timestamp in microseconds
uint32 timestamp

Note

Timestamp Information: All messages are stamped in the header with the ROS2 publishing time for precise temporal coordination. This is different from the sensor’s internal timestamp included in /bota_frame, which corresponds to the actual sampling time on the sensor.

Available Services

The node exposes the following service:

Service	Service Type	Description
`/<NODE_NAME>/tare`	`std_srvs/srv/Trigger`	Zeros out the wrench output of the sensor, setting current state as new reference

Getting Started

Launch the node from the console:

ros2 run bota_driver bota_driver_node \
  --ros-args \
  -p node_name:=<NODE_NAME>
  -p config_file:=<PATH_TO_JSON> \
  -p output_rate:=<VALUE> \

Call the tare service from console:

ros2 service call /<NODE_NAME>/tare std_srvs/srv/Trigger {}

Complete Example:

Bota Systems provides a ROS2 example package bota_driver_example to get yourself started with the Bota Driver Node.

Found the package implementation in our official GitLab repository.

bota_demo_ros2 on GitLab