This page uses terminology from the Force/Torque Sensors User Manual Gen A
The driver is implemented as a class, designed for use in Object-Oriented Programming (OOP) frameworks. Implementations are available for C++, Python and ROS2, each with corresponding SDKs.
The driver abstracts multiple communication interfaces into a single, consistent API.
Driver configuration is handled through a JSON file passed to the class constructor.
product_name
string
Technical product name (e.g., BFT-SENS-SER-M8)
serial_number
string
Sensor serial number (e.g., SN000853)
communication_interface_name
string
Interface type (see supported interfaces below)
communication_interface_params
object
Interface-specific parameters (click to view details)
sensor_operation_params
object
Generation-specific sensor parameters (click to view details)
driver_operation_params
object
Driver behavior settings (click to view details)
The communication_interface_params object requires the following fields based on the selected interface type under communication_interface_name:
communication_interface_name
string
Bota_Binary_gen0
or
Bota_Binary
Required fields in communication_interface_params object:
com_port
string
Serial communication port (e.g., "/dev/ttyUSB0")
baudrate
string
Communication speed (e.g., 460800)
communication_interface_name
string
CANopen_over_EtherCAT_gen0
or
CANopen_over_EtherCAT
Required fields in communication_interface_params object:
network_interface
string
Ethernet interface name (e.g., "eth0")
communication_interface_name
string
Bota_Socket
Required fields in communication_interface_params object:
sensor_ip_address
string
IP address of the sensor (e.g., "192.168.1.100")
Hint: Interface names with _gen0 suffix are for Gen 0 sensors, while names without suffix correspond to Gen A sensors.
Depending on the sensor generation, the sensor_operation_params object requires the following fields:
sinc_length
int
Filter length (sets update rate)
wrench_offset
float[6]
[fx, fy, fz, tx, ty, tz] offset values
app_mode
int
Application mode (wrench/IMU data)
app_submode
int
Filter/update rate settings
wrench_offset
float[6]
[fx, fy, fz, tx, ty, tz] offset values
The driver_operation_params object requires the following fields:
runtime_verbosity
bool
default: true - Prints to the console metrics about duplicates, sensor update rate, etc.
JSON configuration files can be generated using these methods:
Generate JSON files with your sensor's current settings through our web-based configuration interface
Launch ToolTemplates for JSON configuration files are included in the examples provided with our SDKs.
The driver has been designed following the guidelines for lifecycle management proposed by ROS2 in this Design Article.
The driver implements, as shown in the figure below, a state machine with 3 primary states: UNCONFIGURED, INACTIVE and ACTIVE. The figure also shows how these driver states are mapped to the sensor states CONFIG and RUN.
Sensor in CONFIG state, but no sensor operation parameters are applied.
Sensor in CONFIG state, sensor operation parameters are applied.
Sensor in RUN state.
The state machine logic is implemented using intermediate transition states, each responsible for executing specific actions. Progression to the next state is dependent upon the successful completion of these actions. The full state machine implementation is shown in the figure below.
At instantiation time three actions take place:
If all of this is successful, the driver will be in UNCONFIGURED state. Otherwise, it will raise an error and proceed with destruction of the object.
Triggered with: configure()
The driver transitions to CONFIGURING and executes onConfigure() to apply sensor operation parameters.
if onConfigure() result is:
Success: driver state โ INACTIVE
Failure: driver state โ UNCONFIGURED
Triggered with: activate()
The driver transitions to ACTIVATING and executes onActivate(), which brings the sensor to RUN state.
if onActivate() result is:
Success: driver state โ ACTIVE
Failure: driver state โ INACTIVE
Triggered with: deactivate()
The driver transitions to DEACTIVATING and executes onDeactivate(), which brings the sensor to CONFIG state.
if onDeactivate() result is:
Success: driver state โ INACTIVE
Failure: driver state โ ACTIVE
Triggered with: cleanup()
The driver transitions to CLEANING_UP and executes onCleanup(). No specific action is performed in this state.
onCleanup() always succeeds:
Always: driver state โ UNCONFIGURED
From the ACTIVE state the user can call the
readFrame() or
readFrameBlocking() methods, which return the
measurements from the sensor. More information about these methods in the data reading mechanisms section below.
The return object from these methods is of the type BotaFrame:
.. raw:: html
From the INACTIVE state, the user can trigger the tare() method to zero the wrench output.
This method overwrites the wrench_offset values in the sensor configuration with the current sensor readings, effectively setting the current state as the zero reference point for force and torque measurements.
The driver provides two main methods for reading sensor data when in the ACTIVE state:
readFrame() and
readFrameBlocking().
Both methods return a BotaFrame object containing sensor measurements. The choice between the reading mechanisms depends on your application's requirements for timing and control flow.
The communication interfaces available in Bota Systems FT sensors can be classified into two categories:
The sensor continuously sends data, timing this by itself.
The sensor does not send data by itself, and the application must request it.
When calling
readFrame()
the function will return the most recent frame available in the buffer.
Reading data from the buffer is the preferred method for real-time applications, as it allows the application to control the rate of data processing and avoid blocking the execution flow.
When calling
readFrameBlocking()
the execution will be blocked until a new frame has been received from the sensor, returning then that received frame.
In this way the reading is performed directly from the sensor stream, and frame arrival will time the return of the function.
Reading data from the stream is the preferred method for measuring applications, as it ensures data consistency and avoids returning duplicates or dropping packages.