ROS driver package for SBG Systems IMU, AHRS and INS.
This driver package uses the sbgECom binary protocol to read data and configure SBG Systems devices.
Initial work has been done by ENSTA Bretagne.
Author: SBG Systems
Maintainer: SBG Systems
Contact: support@sbg-systems.com
The driver supports the following features:
[!NOTE] Only ELLIPSE devices can be configured from the ROS driver. For High Performance INS such as EKINOX, APOGEE and QUANTA, please use the sbgInsRestApi
User can install the sbg_ros_driver through the standard ROS installation system.
sudo apt-get install ros-noetic-sbg-driver
Clone the repository (use a Release version)
cd catkin_ws/src
git clone -b master https://github.com/SBG-Systems/sbg_ros_driver.git
Install dependencies
cd ..
rosdep install --from-paths src --ignore-src -r -y
Build using the normal ROS catkin build system
source /opt/ros/${ROS_DISTRO}/setup.bash
catkin_make
Source the generated setup environment
source devel/setup.bash
To run the default Ros node with the default configuration
roslaunch sbg_driver sbg_device.launch
To run the magnetic calibration node
roslaunch sbg_driver sbg_device_mag_calibration.launch
Every configuration file is defined according to the same structure.
sbg_device_uart_default.yaml
This config file is the default one for UART connection with the device.
It does not configure the device through the ROS node, so it has to be previously configured (manually or with the ROS node).
It defines a few outputs for the device:
/sbg/imu_data
, /sbg/ekf_quat
at 25Hz/imu/data
, /imu/velocity
, /imu/temp
at 25Hz/sbg/status
, /sbg/utc_time
and /imu/utc_ref
at 1Hz.sbg_device_udp_default.yaml
This config file is the default one for an Udp connection with the device.
It does not configure the device through the ROS node, so it has to be previously configured (manually or with the ROS node).
It defines a few outputs for the device:
/sbg/imu_data
, /sbg/ekf_quat
at 25Hz/imu/data
, /imu/velocity
, /imu/temp
at 25Hz/sbg/status
, /sbg/utc_time
and /imu/utc_ref
at 1Hz.ellipse_A_default.yaml Default config file for an Ellipse-A.
ellipse_E_default.yaml Default config file for an Ellipse-E with an external NMEA GNSS.
ellipse_N_default.yaml Default config file for an Ellipse-N using internal GNSS.
ellipse_D_default.yaml Default config file for an Ellipse-D using internal GNSS.
sbg_device_launch.py
Launch the sbg_device node to handle the received data, and load the sbg_device_uart_default.yaml
configuration.
sbg_device_mag_calibration_launch.py
Launch the sbg_device_mag node to calibrate the magnetometers, and load the ellipse_E_default.yaml
configuration.
The sbg_device
node handles the communication with the connected device, publishes the SBG output to the ROS environment and subscribes to useful topics such as RTCM data streams.
SBG Systems has defined proprietary ROS messages to report more detailed information from the AHRS/INS.
These messages try to match as much as possible the sbgECom logs as they are output by the device.
/sbg/status
sbg_driver/SbgStatus
Provides information about the general status (Communication, Aiding, etc..).
/sbg/utc_time
sbg_driver/SbgUtcTime
Provides UTC time reference.
/sbg/imu_data
sbg_driver/SbgImuData
IMU status, and sensors values.
/sbg/ekf_euler
sbg_driver/SbgEkfEuler
Computed orientation using Euler angles.
/sbg/ekf_quat
sbg_driver/SbgEkfQuat
Computed orientation using Quaternion.
/sbg/ekf_nav
sbg_driver/SbgEkfNav
Computed navigation data.
/sbg/mag
sbg_driver/SbgMag
Calibrated magnetic field measurement.
/sbg/mag_calib
sbg_driver/SbgMagCalib
Magnetometer calibration data.
/sbg/ship_motion
sbg_driver/SbgShipMotion
Heave, surge and sway data.
/sbg/gps_vel
sbg_driver/SbgGpsVel
GPS velocities from GPS receiver.
/sbg/gps_pos
sbg_driver/SbgGpsPos
GPS positions from GPS receiver.
/sbg/gps_hdt
sbg_driver/SbgGpsHdt
GPS true heading from dual antenna system.
/sbg/gps_raw
sbg_driver/SbgGpsRaw
GPS raw data for post processing.
/sbg/odo_vel
sbg_driver/SbgOdoVel
Odometer velocity.
/sbg/event[ABCDE]
sbg_driver/SbgEvent
Event on sync in the corresponding pin.
/sbg/air_data
sbg_driver/SbgAirData
Air data.
[!NOTE] Please update the driver configuration to enable standard ROS messages publication
output.ros_standard
. Also, the driver only publish standard ROS messages if the driver is setup to use ENU frame conventionoutput.use_enu
.
In order to define ROS standard topics, it requires sometimes several SBG messages, to be merged. For each ROS standard, you have to activate the needed SBG outputs.
/imu/data
sensor_msgs/Imu
IMU data.
Requires /sbg/imu_data
and /sbg/ekf_quat
.
/imu/temp
sensor_msgs/Temperature
IMU temperature data.
Requires /sbg/imu_data
.
/imu/velocity
geometry_msgs/TwistStamped
IMU velocity data.
Requires /sbg/imu_data
.
/imu/mag
sensor_msgs/MagneticField
IMU magnetic field.
Requires /sbg/mag
.
/imu/pres
sensor_msgs/FluidPressure
IMU pressure data.
Requires /sbg/air_data
.
/imu/pos_ecef
geometry_msgs/PointStamped
Earth-Centered Earth-Fixed position.
Requires /sbg/ekf_nav
.
/imu/utc_ref
sensor_msgs/TimeReference
UTC time reference.
Requires /sbg/utc_time
.
/imu/nav_sat_fix
sensor_msgs/NavSatFix
Navigation satellite fix for any Global Navigation Satellite System.
Requires /sbg/gps_pos
.
/imu/odometry
nav_msgs/Odometry
UTM projected position relative to the first valid INS position.
Requires /sbg/imu_data
and /sbg/ekv_nav
and either /sbg/ekf_euler
or /sbg/ekf_quat
.
Disabled by default, set odometry.enable
in configuration file.
The driver can publish NMEA GGA messages from the internal GNSS receiver. It can be used with third party NTRIP client modules to support VRS networks providers.
Disabled by default, set nmea.publish
to true
in .yaml config file to use this feature.
/ntrip_client/nmea
nmea_msgs/Sentence
Data from /sbg/gps_pos
serialized into NMEA GGA format. Requires /sbg/gps_pos
.
Namespace ntrip_client
and topic_name nmea
can be customized in .yaml config files.
The sbg_device
node can subscribe to RTCM topics published by third party ROS modules.
Incoming RTCM data are forwarded to the INS internal GNSS receiver to enable DGPS/RTK solutions.
Disabled by default, set rtcm.subscribe
to true
in .yaml config file to use this feature.
/ntrip_client/rtcm
rtcm_msgs/Message
RTCM data from /ntrip_client/rtcm
will be forwarded to the internal INS GNSS receiver.
Namespace ntrip_client
and topic_name rtcm
can be customized in .yaml config files.
The sbg_device_mag node is used to execute on board in-situ 2D or 3D magnetic field calibration.
If you are planning to use magnetic based heading, it is mandatory to perform a magnetic field calibration in a clean magnetic environnement.
Only ELLIPSE products support magnetic based heading and feature the on-board magnetic field calibration process.
/sbg/mag_calibration
std_srvs/Trigger
Service to start/stop the magnetic calibration.
/sbg/mag_calibration_save
std_srvs/Trigger
Service to save in FLASH memory the latest computed magnetic field calibration.
The SBG Ros driver allows the user to configure the device before starting data parsing.
To do so, set the corresponding parameter in the used config file.
# Configuration of the device with ROS.
confWithRos: true
Then, modify the desired parameters in the config file, using the Firmware Reference Manual, to see which features are configurable, and which parameter values are available.
The sbg_device
node can subscribe to rtcm_msgs/Message topics to forward differential corrections to the INS internal GNSS receiver.
The RTCM data stream is sent through the serial/ethernet interface used by ROS to communicate with the INS.
This enables simple and efficient RTK operations without requiring additional hardware or wiring.
When combined with a third party NTRIP client, it offers a turnkey solution to access local VRS providers and get centimeter-level accuracy solutions.
The driver and the device should be properly setup:
sbgCenter
and in Assignment panel
, RTCM
should be set to Port A
.yaml
file to set rtcm.subscribe
and nmea.publish
to true
yaml
file to update topics and namespaces.ELLIPSE products can use magnetometers to determine the heading. A calibration is then required to compensate for soft and hard iron distortions due to the vehicle the product is installed on. The magnetic calibration procedure should be held in a clean magnetic environnement (outside of buildings).
You can read more information about magnetic field calibration procedure from the SBG Systems Support Center.
The ROS driver provides a dedicated node to easily use ELLIPSE on board magnetic field calibration algorithms.
The ELLIPSE offers both a 2D and 3D magnetic field calibration mode.
1) Make sure you have selected the desired 2D or 3D magnetic field calibration mode (calibration.mode
in the configuration yaml
file).
2) Start a new magnetic calibration session once you are ready to map the magnetic field:
roslaunch sbg_driver sbg_device_mag_calibration.launch
rosservice call /sbg/mag_calibration
success: True
message: "Magnetometer calibration process started."
3) Rotate as much as possible the unit to map the surrounding magnetic field (ideally, perform a 360° with X then Y then Z axis pointing downward). 4) Once you believe you have covered enough orientations, compute a magnetic field calibration:
rosservice call /sbg/mag_calibration
success: True
message: "Magnetometer calibration is finished. See the output console to get calibration information."
5) If you are happy with the results (Quality, Confidence), apply and save the new magnetic calibration parameters.
If not, you can continue to rotate the product and try to perform a new computation (and repeat step 4)
rosservice call /sbg/mag_calibration_save
success: True
message: "Magnetometer calibration has been uploaded to the device."
6) Reset/Power Cycle the device and you should now get an accurate magnetic based heading.
To be able to communicate with the device, be sure that your user is part of the dialout group.
Once added, restart your machine to save and apply the changes.
sudo adduser $USER dialout
Udev rules can be defined for communication port, in order to avoid modifying the port in configuration if it has changed. Udev documentation
A symlink can be configured and defined to uniquely identify the connected device.
Once it is done, configuration file could be updated portName: "/dev/sbg"
.
See the docs folder, to see an example of rules with the corresponding screenshot using the udev functions.
ROS uses an internal system time to time stamp messages. This time stamp is generally gathered when the message is processed and published. As a result, the message is not time stamped accurately due to transmission and processing delays.
SBG Systems INS however provides a very accurate timing based on GNSS time if available. The following conditions have to be met to get absolute accurate timing information:
You can select which time source to use with the parameter time_reference
to time stamp messages published by this driver:
ros
: The header.stamp member contains the current ROS system time when the message has been processed.ins_unix
: The header.stamp member contains an absolute and accurate time referenced to UNIX epoch (00:00:00 UTC on 1 January 1970)Configuration example to use an absolute and accurate time reference to UNIX epoch:
# Time reference:
time_reference: "ins_unix"
The frame_id of the header can be set with this parameter:
# Frame name
frame_id: "imu_link_ned"
The frame convention can be set to NED or ENU:
Please read the SBG Systems Support Center article for more details.
You can select the frame convention to use with the following parameter:
# Frame convention
use_enu: true
[!NOTE] The driver only publish standard ROS messages if the driver is setup to use ENU frame convention.
The X axis should point the vehicle forward direction for both NED and ENU frame conventions. The table below summarizes the body/vehicle axis frame definitions for each convention:
NED Convention | ENU Convention |
---|---|
X Forward | X Forward |
Y Right | Y Left |
Z Downward | Z Upward |
The navigation frame also referred by ROS as the cartesian representation is defined as follow:
NED Convention | ENU Convention |
---|---|
X North | X East |
Y East | Y North |
Z Down | Z Up |
Based on the definitions above, when using a NED frame, if the vehicle X axis is pointing North, the INS should return a zero heading. When using a ENU frame, the INS should return a zero heading when the vehicle X axis is pointing East.
If you experience higher latency than expected and have connected the IMU via an USB interface, you can enable the serial driver low latency mode:
/bin/setserial /dev/<device> low_latency
Please report bugs and/or issues using the Issue Tracker
In order to contribute to the code, please use Pull requests to the devel
branch.
If you have some feature requests, use the Issue Tracker as well.