Skip to content

SentiNAV Standalone Software / Executable

SentiNAV can be deployed as a standalone executable. The standalone version is a flexible and user-configurable multiplicative extended kalman filter for fusing IMU and GNSS data (GNSS aided Inertial Navigation Solution). SentiNAV Standalone uses Boost and Protobuf to communicate with SentiBoard and/or SentiUtils.

Tip

The default SentiNAV Standalone Package is configured for GNSS+IMU data. If you want standalone versions supporting additional (or different) sensor data constellations, please don't hesitate to reach out to your SentiSystems Point-of-Contact.

Quickstart

  • Install the standalone executable. On Debian/Linux based systems it is convenient to install SentiNAV Standalone as a service. See SentiNAV Installation for details.
  • ./sentinav --help Will print info on the command line arguments
  • ./sentinav --stats --logfile=sentinav.log --config=sentinav.yaml Will start SentiNAV, print stats to stdout, write logs to sentinav.log, and use the config file sentinav.yaml
  • See SentiNAV Configuration Page for more information about the configuration system.

How it works

State machine

SentiNAV Standalone implements a simple state machine to improve robustness in different scenarios. Here is a quick overview of the states

  • IDLE: INS not running and not initialized. Will stay here until it has received GNSS_NAVPVT messages with Fix for a certain amount of time (configurable)
  • INIT: INS is initializing. If configured with a rover it needs a valid GNSS_RELPOS message and IMU message before initialising the filter
  • NOMINAL: INS is in nominal state. Vehicle is moving
  • ALIGNMENT: INS is in alignment state. Based on GNSS input the vehicle is at rest (thresholds are in the config)
  • DEAD_RECKOGNING: INS has lost fix and is in dead reckogning. Will stay here until it gets fix again

Note

If the filter enteres an illegal state (e.g. vertical veocity, pitch or roll exceeding user configurable thresholds) the filter will enter INIT and reinitialize.

Filter inputs

SentiNAV processes sensor data packets in protobuf format (senti-proto) sent over UDP. SentiUtils and SentiBoard 2.0 can be configured to transmit data on this format. SentiNAV supports the following protobuf inputs:

  • required GNSSPosLLH or GNSSPosECEF: Absolute position measurement.
  • required IMUMsg, IMUMagMsg or IMUMagOrientationMsg: The data rate of the IMU (which also MUST be specfied in the config) should not exceed 100Hz when running SentiNAV on an Embedded computers like RaspberryPi 4/5, Khadas VIM3, Fitlet2 or Jetson TX2.
  • recommended GNSSRelPosNED: With dual GNSS an accurate heading measurement can be utilized.
  • recommended SentiGNSSDop: GNSS quality to weight the GNSS measurement correctly.
  • recommended SentiGNSSRfiStatus: GNSS quality to weight the GNSS measurement correctly.

Filter Outputs

The filter outputs are completely decoupled from the state machine. This means that SentiNAV will start sending out data immediatly when the program is started. When the filter is in IDLE or INIT this data will be invalid and all fields will be 0. You can easily filter out invalid data by checking that the utc_s field of the header is not equal to 0.

Info

The output configuration is configured as a distribution matrix. That means you can forward specific navigation estimate output to specific sources at pre-determined intervals (1Hz, 10Hz, 100Hz), in addition to event driven output (e.g synchronized to TRIGGER_MSG).

In addition, each different output formats can be specified for different endpoints / data consumers.

Tip

One Use Case example is a drone where SentiNAV should send navigation output as mavlink data to the autopilot, while simultaniously also providing the on-board processing unit with high frequency navigation estimates for situational awareness and autonomy functions. This can easily be achived by the following output configuration:

message_outputs:
  - timer100hz: # 100 hz timer
    - states:
      - [127.0.0.1, 40000] # Processing computer ROS node 
                           # listening on UDP 40000 for INSStates SentiProto msg
    - mavlink:
      - [127.0.0.1, 50000] # local ser2net connected to Pixhawk/ArduPilot/Autopilot
                           # (ser2net bridges UDP coms to serial/UART)
  - TRIGGER_MSG: # Event based (every time Trigger message is received)
    - states:
      - [192.168.0.5, 45454] # External unit receiving navigation states at the 
                             # exact timestamp of SentiBoard Trigger event.
Fix types

The FixType reported in the filter output, in addition to GNSSPosLLH and GNSSPosECEF represents:

FixType Description
0 No GNSS Fix
1 GNSS Fix
2 Differential GNSS Fix
3 RTK Fix
4 RTK Float
5 Dead Reckogning
6 SBAS Fix

Log

SentiNAV log Prints two status lines per second as well as warnings and errors. Each state transition is also logged. The status lines contains

  • State: The state of the filter (IDLE, INIT, NOMINAL, ALIGNMENT,DEAD_RECKOGNING)
  • GNSS: Number of NAV_PVT packets recieved
  • REPLPOS: number of NAV_RELPOS_NED packets received
  • DOP: number of NAV_DOP packets received
  • RFI: number of MON_HW packets received
  • IMU: number of IM packets received
  • Messages dropped: Number of packets dropped (checksum error, parsing error etc.) the last second
  • Network errors: Number of failed receives due to network issues last second Then some key filter states are printed
  • LLHHMHG: (lon,lat,height, height_msl, height_geoide)
  • velNED = velocity in NED coordinates [m/s]
  • Quat = Quaternion of the attitude
  • RPY = roll, pitch, yaw in degrees
  • P_pp = Position covariance

Typical status line

[State: ALIGNMENT] [GNSS: 1 Hz] [RELPOS: 1 Hz] [DOP: 1 Hz] [RFI: 1 Hz] [IMU: 99 Hz][Messages dropped: 0] [Network errors: 0] LLHHmHG=(63.4182,10.3983,123.064,83.4001,39.664) velNED=(-0.0431238,0.100129,-0.185677) Quat=(0.999854,0.000366975,0.00351991,0.0167199) RPY=(0.0487912,0.402593,1.91623) P_pp=(1.52514,2.08811'5.19565)

Geoide calculations

To calculate the height over mean sea level SentiNAV needs the following files in the same directory as the executable (right click -> save as...).

Troubleshooting

  • Use nc -u -l $PORTNUM to check that there is data on the port SentiNAV expects it on
  • Check the status line to see the frequency of received data from each port
  • Configure SentiNAV to output the nmea_ins on a local port. NMEA is in ascii and you can thus inspect the filter states

Warning

If there is no output to stdout or log, SentiNAV is currently event driven and only prints out info when it is also receiving data. If there is no output to stdout or the log the most probable cause is that SentiNAV is not receiving any data. Try checking that there is data on the UDP port specified in the config.