Lifecycle Node

Advanced state management for safety-critical applications

The lifecycle node is designed for applications that require strong safety requirements and controlled state management. Perfect for production environments where precise control over node initialization, activation, and shutdown is essential.

Learn more: Lifecycle design documentation | Lifecycle example


Configuration Parameters

The standard node requires the following parameters:

Parameter

Description

config_file

Path to the JSON configuration file

output_rate

Controls reading mechanism (see details below)

bota_ft_sensor_link_name

Prefix used to name the published topics. It must match the name provided to the XACRO.

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.


Lifecycle State Management

The lifecycle node follows the ROS2 lifecycle state machine. Use the following services to manage transitions:

Transition

ID

Service Call

configure()

1

ros2 service call /bota_driver_lcnode/change_state \
  lifecycle_msgs/srv/ChangeState "{transition: {id: 1}}"

cleanup()

2

ros2 service call /bota_driver_lcnode/change_state \
  lifecycle_msgs/srv/ChangeState "{transition: {id: 2}}"

activate()

3

ros2 service call /bota_driver_lcnode/change_state \
  lifecycle_msgs/srv/ChangeState "{transition: {id: 3}}"

deactivate()

4

ros2 service call /bota_driver_lcnode/change_state \
  lifecycle_msgs/srv/ChangeState "{transition: {id: 4}}"

shutdown()

6

ros2 service call /bota_driver_lcnode/change_state \
  lifecycle_msgs/srv/ChangeState "{transition: {id: 6}}"

Published Topics

Once running, the node publishes the following topics:

Topic

Message Type

Description

/bota_frame

BotaFrame (see below)

Complete sensor data including status, wrench, IMU, temperature and timestamp

/bota_wrench

WrenchStamped

Force and torque measurements from the sensor

/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

/bota_driver_lcnode/tare

std_srvs/srv/Trigger

Zeros out the wrench output of the sensor, setting current state as new reference

Important

The tare service can only be called when the node is in INACTIVE state.


Getting Started

Launch the node from the console:

ros2 run bota_driver bota_driver_lcnode \
  --ros-args \
  -p config_file:=<PATH_TO_JSON> \
  -p output_rate:=<VALUE> \
  -p bota_ft_sensor_link_name:=<BOTA_FT_SENSOR_LINK_NAME>

Manage lifecycle states:

# Configure the node
ros2 service call /bota_driver_lcnode/change_state lifecycle_msgs/srv/ChangeState "{transition: {id: 1}}"

# Activate the node (starts publishing topics)
ros2 service call /bota_driver_lcnode/change_state lifecycle_msgs/srv/ChangeState "{transition: {id: 3}}"

Call the tare service from console:

# Note: Only works when node is in INACTIVE state
ros2 service call /bota_driver_lcnode/tare std_srvs/srv/Trigger {}

Complete Example:

Ready to try it out?

A detailed example for the lifecycle node is coming soon. For now, you can follow the example for the standard node and adapt it for the lifecycle managed node youself.