Sensor Configuration

• Web interface overview
• Sensor fusion configuration
• Network configuration
  • Network specifications
  • Default route
  • Network data ports
  • Outbound connections
  • USB recovery network
  • Wi-Fi access point
  • Static IP
• Time synchronization
  • Network Time Protocol (NTP)
  • Precise Time Synchronization (PTP)
  • Pulse Per Second (PPS)
• Input/output system overview
  • UART port configuration
  • UDP port configuration
  • CAN streaming port configuration
  • Differences between CANSTR and CAN Interface
  • Output generator
  • Point of interest configuration
  • Output messages configuration
  • Velocity Measurement input options
• Correction service configuration
  • Supported RTCM3 messages
  • RTKLIB/str2str
• Camera configuration
  • Camera streaming
• Measurement sensor configuration
  • CAN wheelspeed sensor
  • Verifying CAN message configuration
  • I/O wheelspeed sensor

Web interface overview

To configure the Vision Navigator and visualize the current trajectory, the user can access the web interface through a browser using the IP 10.0.1.1 with a direct Wi-Fi connection or 10.0.2.1 with a direct Ethernet connection. Note that these IP addresses only apply when the sensor is configured as the DHCP server or using the access point directly. The figure below presents an overview of the web interface content. In the Wi-Fi case, the SSID is the UID of the Vision Navigator, and the default password is “1234567890”.

Web interface structure overview

The home page of the web interface is the 'Fusion Status' page, which is shown in the figure below. The user can access the different configuration options through the navigation bar at the top of the screen, which also contains status indicators to monitor the sensor. Refer to Fusion Status Dashboard for more information about the status indicators.

Home page of the web interface

Besides the status indicators and badges, this page contains a map with the downsampled GNSS1/2 and Fusion position trajectories. The table at the bottom of the page shows the position, orientation, and velocity data in the second column, while in the last column, the respective covariances are given.

On the home page, the user can find buttons to start (not displayed in the figure above) or stop the Fusion engine. Stopping the Fusion engine is necessary for most configurations. Please note that most of the configuration can also be done via API.

Furthermore, upon pressing the ’Actions’ button, the user can restart the Fusion engine with the ’Reset’ button (see the figure below). Besides that, an initial pose can be saved or loaded in this menu. One can save and label 5 different positions on the device. It is important to note that saving is only possible once Fusion is fully initialized. For Loading, on the other hand, Fusion only needs to be started and a previously warmstarted IMU bias needs to be available. Upon loading a previously saved position, Fusion is locally initialized, which means initializing in GNSS-denied environments is possible.

Actions menu

 Saving a position on an empty slot and adding a label

Sensor fusion configuration

The user can configure the sensor fusion engine by accessing the web interface and navigating to the "Configuration → Fusion" panel. In this section, the following configuration options are available:

• Autostart: Once enabled, the Fusion engine will be launched automatically on system bootup. Note: Enabling this will not start the Fusion engine directly.
• Housing: Prototype (i.e., 3D-printed) or Standard (i.e., aluminum).
• Tuning mode: Expected platform dynamics (see System description).
• Signal power compensation: Allows the user to apply some compensation to the GNSS power. Default should be used unless recommended otherwise by Fixposition.
• GNSS extrinsics: Position of the GNSS antennas with respect to the Vision Navigator sensor frame in meters. These values should be accurate to the mm level.

Fusion engine configuration on the web interface

Network configuration

To access the network configuration page in the web interface, the user must press "Configuration" on the navigation bar and select "Network". As shown in the figure below, this page presents the configuration for the Wi-Fi interface, client, and access point, as well as the Ethernet connection configuration.

Networking configuration page in the web interface

Network specifications

To connect to a Wi-Fi network and access the Internet, the user must specify the configuration of the Wi-Fi interface, which includes the desired Wi-Fi band and whether the access point of the sensor is enabled. Currently, the sensor supports the 2.4 and 5.0 GHz bands or disabling the Wi-Fi module altogether (see the figure below). After updating the configuration of the Wi-Fi interface, it is necessary to reboot the sensor to apply them.

Currently, we only support one band at a time, meaning the access point and the hotspot should operate at the same frequency.

WiFi interface configuration options

The table below summarizes all available network configurations for the Vision Navigator:

Network configuration details

Some details, recommendations, and known limitations to take into consideration:

• Wi-Fi is only suitable as a service interface, as its connection can be unreliable. The device must use Ethernet for regular operation.
• 2.4 GHz is preferred over 5 GHz for Wi-Fi connections due to its range and reliability.
• An Ethernet connection is always prioritized over Wi-Fi for Internet access.

• If the Ethernet is configured as static-ip and it doesn't provide Internet access, make sure to leave the gateway field empty. Only then the Wi-Fi connection will be used for Internet access.

• The only supported Wi-Fi security configuration is "wpa-psk" (WPA2). Currently, we do not support "SAE" (WPA3) nor "open" Wi-Fi connections (no password).
• The Vision Navigator shares Internet access with devices connected to its network.
• The sensor must be configured as a DHCP client employing an intermediary device, such as a router or access point. Then, the DHCP server in the network is in charge of assigning a dynamic IP address to the sensor. Note that the 10.0.1.1 and 10.0.2.1 IPs do not apply when accessing the sensor via the intermediary device.
• Use distinct SSIDs for each Wi-Fi band (2.4 and 5 GHz) to facilitate connectivity.
• The Vision Navigator will only connect automatically to the network marked as "default" in the web interface. However, marking a new Wi-Fi connection as "default" does not activate this connection automatically; the user must press the "connect" button.
• The IP address, netmask, gateway, and DNS of each connection can be configured.
• Wi-Fi client connections are only partially reliable; they sometimes require multiple attempts to succeed in connecting.
• If the Wi-Fi client connection is lost, reconnecting can take up to two minutes.
• The network SSID must match the regular expression ^[-_a-zA-Z0-9]{2,32}$. In other words, the network SSID must contain only alphanumeric characters.
• The Wi-Fi chip regulatory domain is configured as "passive automatic" (i.e., the chip monitors the existing Wi-Fi channels and uses only those valid in the region).
• Most Wi-Fi 6E access points are configured using 802.11ax by default, which the Vision Navigator does not support. The user must change the configuration to one of our supported bands.

Default route

The default route defines the path network packets take if no specific route is determined. Typically, it relates to the Internet access route, for example, when connected to a Wi-Fi hotspot or plugged into the cable modem/router at home. The table below provides the default route in different configurations and states as the interface over which any network packet going outside will travel. For example, the NTRIP client connection request to an NTRIP caster on the Internet would go over the presented interface.

Note that this table shows that when both the Wi-Fi client and Ethernet (DHCP client or static IP with gateway) have Internet access, the Ethernet route is preferred (i.e., in this context, it means used exclusively). There is no such thing as an automatic retry via another route.

Network data ports: Default route

This table is valid under the assumption that the external DHPC server (Wi-Fi hotspot or Ethernet router) does provide a default route (i.e., has Internet access). The user can choose not to do that, allowing for various network setup variations.

In this context, "Connected" means the network link is up. It does not mean "Internet" is available (i.e., it does not imply that the upstream connection is good). For example, you can be connected to a Wi-Fi hotspot on your phone even though it is disconnected from the cellular network. In this situation, and with the configuration 1, 4, or 5, it would mean that the device would no longer access the Internet.

Besides the default route, each interface (Wi-Fi client, Wi-Fi access point, Ethernet) has a specific route for that network. Therefore, connections to an address in that network always go via that interface independent of any default route.

The "Configuration → Network" page of the Web Interface shows the current default route as shown in the figure below, where we can see that the Ethernet connection is preferred over the Wi-Fi client.

Default route example

Network data ports

The following network data ports are available over Ethernet and Wi-Fi:

Outbound connections

The Vision Navigator makes outbound connections to the Internet to the following servers:

• 0.openembedded.pool.ntp.org – NTP time sync.
• Configured NTRIP caster server.

While the web interface is open in a client browser:

• 8.8.8.8 – Checking internet connectivity.

While the remote support functionality is enabled:

• reflector.sensor.fixposition.com – Secure reflector server

The web interface (i.e., the client browser, not the Vision Navigator itself) connects to:

• api.mapbox.com - Map data used on the 'Fusion Status' page.

USB recovery network

When connected to a PC, the USB port on the Vision Navigator acts as a "USB Ethernet gadget." The PC sees a network interface similar to a USB-to-ethernet dongle.

The PC should automatically detect the network interface and configure it. This way, the user can access the web interface via http://10.0.3.1 to change the configuration. The configured password does not protect this access mode to the web interface as with other interfaces (Ethernet and Wi-Fi).

The user cannot configure this network access mode as it is only for recovery (e.g., misconfigured Ethernet and Wi-Fi) and should not use it for data transfer.

The USB network interface should automatically work on Linux (e.g., Ubuntu 22.04). Windows should recognize the sensor as a "USB Ethernet/RNDIS Gadget," not as a (nonfunctional) COM port.

Wi-Fi access point

To change the configuration of the Wi-Fi access point, press the ’Edit connection’ button on the Wi-Fi access point section. As shown in the figure below, the web interface will display a configuration panel where the user can modify the following fields:

• Password: Change the Wi-Fi access point password. Leave the field empty so as not to change it. Default: 1234567890.
• IP address: Set the IP address for the Wi-Fi access point. Default: 10.0.1.1.
• Netmask: Set the network netmask. Default: /24 (255.255.255.0).
• Broadcast SSID: Choose if the SSID should be broadcast (normal operation) or not ("hidden" Wi-Fi). Note that a reboot is required to activate changes to this setting. Some computers or phones may still show the (cached) SSID when it is hidden.

Wi-Fi access point configuration on the web interface

Static IP

To set up a static IP for connecting to the Vision Navigator over Ethernet, press the 'Edit connection' button on the static IP field of the Ethernet section. As shown in the figure below, the web interface will display a configuration panel where the user can modify the following fields:

• IP address: Set a static IP address for the Vision Navigator.
• Netmask: Set the network netmask. Default: /24 (255.255.255.0).
• Gateway: Set the gateway’s IP address. Default: 10.0.2.1.
• DNS: Set one or more IP addresses of DNS server(s). Default: 1.1.1.1, 8.8.8.8, 8.8.4.4.
• Set as default: Choose if this connection should be the default. Only one connection per interface can be the default.

Press the 'Apply' button to apply the selected changes. At this point, the Vision Navigator is not yet using the static IP. Once configured, the user must press the 'Connect' button.

Static IP configuration on the web interface

Time synchronization

To visualize which time source the Vision Navigator is employing, head to the "System → Info" page of the web interface and check the ’Time synchronization’ field. An example is shown in the figure below, where the Vision Navigator is synchronixed to the time information provided by the GNSS receivers.

Time information displayed on the Input/Output Dashboard

The time information can come from one of the following sources:

• Internal clock.
• NTP server
• GNSS time information.

On initialization, the time information provided by the XVN is based on its internal clock. If an Internet connection is provided, the sensor will attempt to communicate with an NTP server to synchronize its clock, see Outbound connections. Once the GNSS1 receiver reads signals, it will synchronize with the GNSS time, which has the highest accuracy. That way, the internal clock of the XVN will be corrected by synchronizing with the GNSS1 receiver. Note that the XVN has an internal battery to keep its internal clock running without the sensor's power source connected.

In reality, the time kept by clocks in different network devices can drift from each other. In time-sensitive applications, this drift is mitigated by using time synchronization. Having time synchronized between any two clocks means that the difference in time between them has an upper bound. This can be achieved by periodically synchronizing the time between the clocks before the time difference gets too large. There are three options to synchronize another system with the very accurate clock of the Vision Navigator: Network Time Protocol (NTP), Pulse Per Second (PPS) signal, and Precise Time Protocol (PTP).

Network Time Protocol (NTP)

If a time synchronization precision of a few milliseconds is sufficient, the user can employ the Vision Navigator's built-in NTP server (port 123).

Precise Time Synchronization (PTP)

If the required time synchronization precision must be in the range of a few microseconds, the user can use the Vision Navigator’s PTP capabilities. The Ethernet MAC with IEEE 1588 of the Vision Navigator integrates a standard IEEE 802.3 Ethernet MAC with a time-stamping module. The IEEE 1588 standard provides accurate clock synchronization for distributed control nodes (e.g., industrial automation applications). Since firmware 2.81.x, the sensor can be a Precision Time Protocol (PTP) Grand Master (GM). The sensor provides a very precise time (sub-microseconds), which can be used by other devices if required.

The PTP functionality can be (de)activated in the Web Interface on the "Configuration → Time" page (see figure below). The following three PTP profiles are supported and can be selected in the Profile drop down menu:

• PTPv2 E2E (IEEE 1588-2008): This is the standard PTPv2 profile, which uses the E2E delay mechanism and is specified according to IEEE 1588-2008.
• gPTP (IEEE 802.1AS): Also known as Generalized Precision Time Protocol (gPTP), it consists of simplifications and constraints to PTP to optimize it to time-sensitive applications. gPTP also introduces the Grand Master (GM) role which can be played by any node in the gPTP domain (such as end-stations or bridges) and is determined by the Best Master Clock Algorithm (BMCA). The GM provides clocking information to all other nodes in the gPTP domain. gPTP devices operate in one of three roles, according to their location in the spanning tree: master, bridge or slave. The Vision Navigator contains the master clock for the time domain, creates gPTP sync messages, and broadcasts them down-tree to bridge and slave nodes. Bridge nodes forward sync messages to bridge and slave nodes as well. If one or more Ethernet bridges are involved in the customer’s network, they must be able to bridge gPTP. This can be implemented with bridges specially designed for this purpose.
• Avnu automotive profile: Due to the static nature of the automotive network, AVnu has specified the Automotive Profile which does some optimizations to gPTP to improve startup time and reduce network load. The main difference from gPTP is that the BMCA is disabled so each device is statically assigned as master or slave.

Precise Time Protocol

Tests have shown that the precision of the time synchronization with the Vision Navigator using PTP is sub-microsecond. The time accuracy is based on the time provided by the GNSS receiver and is approximately 3us on the sensor with good GNSS reception. During periods of operation when there is no or only degraded GNSS reception, the time provided by PTP will naturally start to drift to the same extent as the time from the GNSS receiver and accuracy may suffer. In other words, under these conditions, PTP will continue to provide the system time and synchronize all connected slaves relative to each other and precision stays the same. However, the time provided may deviate from the global time and accuracy suffers. Note that measurement inaccuracies cannot be precluded. For more precise results, the measurements would have to be carried out again with a more accurate measurement setup.

For examples on how to use the PTP, please refer to How to Enable Precision Time Protocol(PTP) for XVN.

Pulse Per Second (PPS)

Using PPS with the corresponding timing message from the GNSS receiver provides the maximum accuracy. However, setting up this method is the most complex. The XVN outputs the PPS signal from the GNSS1 receiver.

An illustration of time pulse function

Time pulse:

• The time pulse function provides a one pulse per second (pps) signal (at top of second).
• The time pulse can be read on pin 5 of the I/O connector (see Hardware connections).
• Once the sensor has received any GNSS signal information, the 1 pps signal will adjust to each second, and the rising edge of each pulse will align to the top of GPS time seconds.
• The duty cycle is 10%, meaning the pulse width is 100 ms.
• The timestamp message is available in the FP_A-TP_GNSS1 message.
• The timepulse is only valid once the receiver has a full PVT (position, velocity and time) navigation solution. Therefore, one should not use the timepulse when there is no GNSS Fix available, i.e., in outages. This is because in such case, the same high precision can not be guaranteed.
• On startup or restart of the GNSS receiver, the timepulse may have one period that is shorter or longer than 1s. This happens when it adjusts from unknown or drifted time to GPS top-of-second.

Input/output system overview

Input/output system overview

The Vision Navigator provides multiple input and output data stream options. This section provides an overview of the I/O system. Note the distinction between:

• Port: Physical (e.g., UART) or logical (e.g., network socket) connection endpoint. Via a connector and an interface this is what the user ultimately connects to.
• Interface: Hardware peripheral which connects a port with a connector.
• Connector: Provides the electrical connection to the interface (i.e., the connector names are written on the sensor).

The network interfaces of the sensor comprise Ethernet, Wi-Fi station (client), Wi-Fi access point, and USB network. See the previous section for more details on network configuration.

UART port configuration

The UART1 and UART2 ports correspond to the pins 7 (UART1_RX), 8 (UART1_TX), 4 (GND) in the I/O connector, and pins 2 (UART2_RX), 3 (UART_TX), and 4 (GND) in the AUX connector (see Hardware connections). The user can configure the baud rate of the UART ports inside the "Configuration -> I/O" panel of the web interface. The available options are 9’600, 19’200, 38’400, 57’600, 115’200, 230’400, 460’800, or 921’600. A baud rate of 115’200 or higher is recommended.

The user can input the wheelspeed sensor and RTCM3 correction data streams into the Vision Navigator via UART. The XVN can stream the output messages (e.g., FP_A-ODOMETRY) via UART.

UART baud rate configuration

UDP port configuration

The UDP0 and UDP1 ports are accessible via ethernet (recommended), WiFi or USB (see the table above for more information). The user can use the UDP ports for inputting data such as wheelspeed or RTCM3 correction data via the designated port numbers. For outputting data on UDP0 and/or UDP1, the user needs to select the 'Output' as 'Enabled', insert the respective IPv4 address, and add a chosen port number that lies within 1024 - 65530. Save the configuration changes and enable the desired output messages.

UDP port configuration

CAN streaming port configuration

All input and output ports are streams of bytes (uint8_t). The CANSTR port packs the output stream of bytes into as many CAN frames as necessary. Depending on the CANSTR configuration, this can be classical CAN frames with up to 8 bytes or CAN FD frames with up to 64 bytes of payload. The figure below shows the CANSTR message format generation. The CANSTR port corresponds to the pins 1 (CANH), 2 (CANL), and 4 (GND) of the I/O connector (see Hardware connections).

CANSTR message format

The user can configure the CAN interface inside the "Configuration -> I/O" panel of the web interface, as shown in the figure below. The following configuration options are available:

• CAN interface: The CAN interface can be enabled or disabled.
• Classical CAN bitrate: The bitrates [Hz] can be: 10’000, 20’000, 50’000, 125’000, 250’000, 500’000, 800’000 or 1’000’000.
• CAN FD (BRS) bitrate: The CAN FD bitrate must be greater or equal to the classical CAN bitrate.

The user must reboot the sensor after updating the CAN interface configuration.

CAN interface configuration

The CANSTR module configuration can be modified in the CANSTR panel inside the "Configuration -> I/O" panel of the web interface, as shown in the figure below. The following configuration options are available:

• CAN ID output: CAN ID for outgoing CAN frames.
  • Standard frame format (SFF): 11-bit value in the range 0x001 - 0x1ff.
  • Extended frame format (EFF): 29-bit value in the range 0x00000001 - 0x1fffffff.
• CAN ID input: CAN ID for incoming CAN frames.
  • Standard frame format (SFF): 11-bit value in the range 0x001 - 0x1ff.
  • Extended frame format (EFF): 29-bit value in the range 0x00000001 - 0x1fffffff.
• CAN frame format: CAN frame format used by the connector.
  • Standard frame format (SFF): Use 11-bit CAN IDs for input and output.
  • Extended frame format (EFF): Use 29-bit CAN IDs for input and output.
• CAN FD: Classical CAN or CAN flexible data rate (FD)
  • Classical CAN: CAN frames of up to 8 bytes payload.
  • CAN FD: CAN frames of up to 64 bytes of payload.
• CAN FD BRS: Enable bitrate switching (BRS) when using CAN FD.
  • Enabled: Use CAN FD BRS.
  • Disabled: Do not use CAN FD BRS.

Differences between CANSTR and CAN Interface

CANSTR is a specialized port built upon the standard CAN interface. It offers the flexibility to utilize the CAN protocol to stream input and output data, which the user can customize within the I/O configuration section of the web interface.
Additionally, the user can configure the CAN ID for these streams as required.

The main distinctions between CANSTR and the traditional CAN interface are:

• The Vision Navigator natively recognizes the Classic CAN message for wheelspeed input with ID: 0x147 for header information and 0x148 for data input when using the adequately configured payload (see Appendix B for more information). For more details on configuring the wheelspeed input via CAN, please refer to CAN wheelspeed sensor.
• CANSTR allows for a more customized approach. Users can assign a specific ID and embed customized data within the payload of either Classic CAN or CAN FD. You can also put NOV_B-RAWDMI information into the payload. This setup is analogous to the UART/TCP/UDP mechanism, especially when streaming wheelspeed data into the system. Moreover, CANSTR provides the capability to input and output other user-defined information.

A vital consideration when working with any CAN interface is the bitrate setting. Ensuring the correct bitrate is paramount for the seamless communication of all devices on the CAN bus.

CANSTR module configuration

Output generator

The user can configure the Fusion output at the Output generators module inside the "Configuration -> I/O" panel of the web interface, as shown in the figure below. The following configuration options are available:

• Fusion output frequency: Rate in [Hz] at which the Fusion generates its output.
  Range: 1-100.
• Fusion output offset: Specifies how much time ahead Fusion calculates its output [s], compensating for output or processing latency (at the cost of some accuracy).
  Range: 0.0-0.2.
• Fusion output filtering: As the Fusion output is only smooth to a certain level, the user can select the level of smoothness of the Fusion output:
  dff
  • Low: Default level of filtering.
  • Medium: Moderate level output filtering.
  • High: Highest available level of output filtering
  There is no correlation between this setting and the FP_A-ODOMSH

• NMEA output format: NMEA format used by the Fusion output. See the table below for more information.
  • Strict NMEA: Strictly follow the NMEA specifications.
  • High-Precision: Enable output of non-standard data fields with more precision.
• Output Point of Interest configuration: Parameters to transform the output from the sensor frame to the Point of Interest (POI).
  • Output translation: Translation vector in [m] from the sensor frame to the POI. This translation is defined with respect to the fixed reference frame of the sensor.
    Range: -100.0-100.0.
  • Output rotation: Rotation from the sensor frame to the POI using ZYX Euler angles (yaw-pitch-roll) in degrees. It employs intrinsic rotations (i.e., the reference frame is updated after each subsequent rotation).
    Range: -180.0-180.0”.

Output generators configuration

1. ENU output: By default the ENU output is set to 'Automatic'.
   • No output: Provide no reference point and thus ENU related messages can not be output.
   • Automatic: Select the reference system (ENU0) automatically as the first ECEF measurement received by the sensor.
   • User defined: Manually define the reference system.
2. User defined ENU: If the ENU output is configured as 'User defined', you can manually insert ECEF coordinates of the reference system here.

ENU Output configuration

Point of interest configuration

The default reference frame of the XVN is located at the X shape on the sensor housing (see Mechanical Specifications). If the user requires the odometry output in a different reference frame, the “Output translation" meaning "Translation from the sensor to output represented by x-y-z Cartesian coordinates" and "Output rotation" meaning "Rotation from the sensor to output represented by Roll-Pitch-Yaw (RPY) in the Cartesian coordinates" fields in the Output generator module of the web interface can be used.

The XYZ displacements from the center of the XVN's reference frame to the desired point are expressed in meters. In contrast, the rotation from the sensor’s frame to the output’s body frame is expressed in degrees using Yaw-Pitch-Roll (YPR) rotations, also known as Euler Angles. For reference, the arrow on the web interface’s map page points towards the output frame’s positive X direction.

For reference, the figure below shows an example of a transformation between the XVN’s body frame and the output’s body frame using the previously described convention. In this example, the point of interest (POI) is located at an arbitrary point inside the vehicle. Therefore, the user must calculate the XYZ translations from the sensor’s frame of reference to the POI and then rotate the frame using YPR angles.

Transform from the XVN's body to the output reference frame

Output messages configuration

A segment of the possible output message configuration

The user can select which messages are assigned to each port at the Output messages module inside the "Configuration -> I/O" panel of the web interface, as shown in the figure above.

Fusion output: The output frequency of these messages is the same as the Fusion output frequency configured in the output generator. By default, the output frequency is 10 Hz, but the user can configure it to the range of 1-100 Hz. For a detailed list of all available messages, their formats, and examples, please refer to Input/Output messages.

Available Fusion messages:

• FP_A-ODOMETRY
• FP_A-ODOMENU
• FP_A-ODOMSH∗∗
• FP_A-ODOMSTATUS
• FP_A-LLH
• NOV_B-INSPVAX
• NOV_B-BESTVEL_FUSION
• NMEA-GN-GGA_FUSION∗
• NMEA-GN-GLL_FUSION∗
• NMEA-GN-GSA_FUSION
• NMEA-GN-GST_FUSION∗
• NMEA-GX-GSV_FUSION
• NMEA-GN-HDT_FUSION∗
• NMEA-GN-RMC_FUSION∗
• NMEA-GN-VTG_FUSION∗
• NMEA-GN-ZDA_FUSION
• FP_A-EOE_FUSION
• FP_A-IMUBIAS

IMU output: All IMU output is generated at the IMU frequency of approximately 200 Hz. Note that the IMU output requires a lot of output bandwidth. For example, on a serial port, the baud rate must be set high enough for the necessary bandwidth. The exact number depends on what messages are enabled for the port.

Available IMU messages:

• FP_A-RAWIMU
• FP_A-CORRIMU
• NOV_B-RAWIMU

TF output: The output frequency of these messages is 1 Hz. See exceptions below.

Available TF messages:

• FP_A-TF_VRTKCAM
• FP_A-TF_POIVRTK
• FP_A-TF_ECEFENU0
• FP_A-TF_POIPOISH∗
• FP_A-TF_POIIMUH∗∗

Text output: Irregular output of text messages (strings). There are four levels:

• ERROR – An error is something from which the sensor cannot recover or something that renders the sensor unusable in normal circumstances.
• WARNING – A warning is something from which the sensor could recover or that does not render the sensor unusable in normal circumstances (i.e., the sensor operated to specifications). But it can, for example, hint at degraded performance.
• INFO – General information.
• DEBUG – Debug information valuable to the support team.

For example, the sensor outputs a "boot screen" on boot. While it does output it to any port where the FP_A-TEXT_INFO message is enabled, it is only practical to observe this output on UART and CANSTR ports. It is not possible to connect to the TCP ports in time to observe this output.

The boot screen is as follows:

Available text messages:

• FP_A-TEXT_ERROR
• FP_A-TEXT_WARNING
• FP_A-TEXT_INFO
• FP_A-TEXT_DEBUG

GNSS output: All GNSS output is generated by default at the GNSS frequency of approximately 5 Hz. In addition, some GNSS output messages cannot be distinguished between GNSS receivers; ensure you use different ports to avoid confusion.

Available GNSS messages:

• NMEA-GN-GGA_GNSS[average, 1, 2]*
• NMEA-GN-GLL_GNSS[average, 1, 2]*
• NMEA-GN-GSA_GNSS[average, 1, 2]
• NMEA-GN-GST_GNSS[average, 1, 2]*
• NMEA-GX-GSV_GNSS[average, 1, 2] 
• NMEA-GN-RMC_GNSS[average, 1, 2]*
• NMEA-GN-VTG_GNSS[average, 1, 2]*
• NMEA-GN-ZDA_GNSS[average, 1, 2] 
• NOV_B-BESTGNSSPOS_GNSS[1,2]
• NOV_B-HEADING2
• FP_A-GNSSANT
• FP_A-GNSSCORR
• FP_A-EOE_GNSS[average, 1, 2]
• NMEA-GN-GGA_NTRIP
• NMEA-GN-GGA_GNSS1TOS
• NMEA-GN-RMC_GNSS1TOS
• NMEA-GN-ZDA_GNSS1TOS
• FP_A-TP_GNSS1

Measurements input: For more information, see Input/Output Messages. Available measurement message:

• FP_B-MEASUREMENTS

Advanced view

Toggler to activate the advanced view for the output messages

In the advanced view, each available message shows its output rate. Zero (0) means the message is disabled and is not output. One (1) means the message is enabled, and its output frequency is 1 Hz. Values greater than one indicate that one of every n-th message is output (e.g., Five (5) means only one of every five messages is output).

While values other than 0 or 1 may not make sense for most messages or scenarios, there are use cases for these values. For example, we can configure the Fusion output to 50 Hz and enable the FP_A-ODOMETRY output on TCP0. Enabling this message implies a rate of 1 by default; thus, its output is also at 50 Hz. This high output rate would not be possible on a low-bandwidth port, such as UART. However, the user can select a rate of 10, meaning the sensor would output only every tenth message (i.e., 5 Hz), for which the bandwidth is sufficient.

Note that there is no guarantee for output rates greater than one to be aligned to the top of the second. For example, for a message generated at 10 Hz, with a rate of 5, the sensor cannot guarantee the time stamps to end in x.0 and x.5, as a slight delay could change the timings to x.1 and x.6 or x.4 and x.9.

In the figure below, the output rate is 10 for the FP_A-ODOMETRY message on the UART1 port. If the desired output frequency is 100 Hz, the actual output frequency is equal to or smaller than 10 Hz.

$\mathrm{real output frequency}\le \mathrm{theoretical output frequency}=\frac{\mathrm{Fusion output frequency}}{\mathrm{output rate}}$

An example of setting up the output rate

Velocity Measurement input options

The Vision Navigator offers multiple methods for streaming wheelspeed data. This section provides a detailed overview of the available options.

1. I/O streaming: Wheel odometry data can be transmitted through I/O using the UART, TCP, UDP or CANSTR protocols, adhering to the FP_B-MEASUREMENTS format (see Input/Output messages). Users must populate the payload according to established guidelines and their specific needs.
2. CAN message streaming: Users can directly transmit the Fixposition-defined CAN message via the CAN interface (refer to Appendix B). This process is independent of CANSTR. Users do not need to configure CANSTR for this functionality. It is important to note that CANSTR operates at a higher application layer. The distinctions between CANSTR and the CAN interface are elaborated here.
3. ROS speed topic streaming: A dedicated ROS topic, ‘/fixposition/speed‘, can be populated with speed data, adhering to the ROS message format specified at this repo. Upon receiving this data, the ROS network forwards it to the Fixposition driver. The driver then recognizes the data package and delivers the corresponding NOV-B_RAWDMI message to the Fusion engine.

Ensuring adequate configurations for seamless data integration and optimal system performance is imperative. The user can input wheelspeed measurements over any port (see Input/output system overview) based on the wheelspeed measurement configuration employed (see Measurement sensor configuration). The corresponding messages must be input at regular intervals, and the input rate must be at most 50 Hz. The latency (from measuring the wheelspeed to inputting it on the selected port) must be as low as possible. Increased, and in particular, irregular latency degrades the Vision Navigator's performance.

Correction service configuration

The Vision Navigator requires RTCM3 data to provide real-time corrections for accurate localization. The user can configure the correction service in the "Configuration -> GNSS" panel of the web interface. The correction service configuration must fulfill the following specifications:

• Coverage: The area of operation of the sensor must match the geographical operation area of the correction service provider.
• Transport: Networked Transport of RTCM via Internet Protocol (NTRIP), version 1 only. This method implies that the sensor must have access to the Internet and the chosen service/server.
• Data format: The supported RTCM3 messages fare listed in RTCM3.
• Data content: OSR-style multi-signal messages (MSM). 
• GNSS constellation: The data must include all four major GNSS constellations (i.e., GPS, GLONASS, Galileo, and BeiDou). Missing systems will degrade performance significantly.

The user must select the desired method to input the correction service data in the "Source" parameter (see figure below for reference). The following methods are available:

• NTRIP client (auto): This is the preferred method. It employs the built-in NTRIP client to connect to a chosen NTRIP caster.
  • This method requires that the sensor has network (Internet) access to the caster server.
  • If the NTRIP caster does not use a login, put dummy or none for the User and Password fields.
• NTRIP client (v1) or NTRIP client (v2): This method forces the built-in client to assume an NTRIP caster version 1 or 2, respectively. This option can be helpful when the "auto" option does not work with a particular caster.
• TCP client: This method employs a built-in raw TCP/IP client to connect to any host/IP and port to get correction data. For this option, no user, password, or mountpoint is needed.
• I/O port: This method requires the user to stream the corresponding RTCM3 messages at the appropriate rates over any of the I/O ports available on the Vision Navigator. In this mode, the sensor does not send its location. If the host system requires a position message, the appropriate output message(s) can be configured (typically, NMEA-GN-GGA_NTRIP). In this configuration, the built-in NTRIP client in the Vision Navigator is disabled, and the sensor does not need an Internet connection for the correction data. It is entirely up to the user to correctly provide the correction data on an I/O port. The user can visualize the number of bytes, messages, and errors received through any port in the "I/O status" field in the "System → Info" page. Please refer to Status Dashboard for the details.

For the NTRIP and TCP methods, one can choose if and how to send the sensor’s location to the caster:

• Automatic: Automatically chooses the best available position from the GNSS receivers and the Fusion engine.
• Manual: The client sends a user-configured position to the caster. The "Use current" button fills the form with the current position from the GNSS receiver (preferring GNSS1, fall-back to GNSS2).
• None: The client sends no position to the caster. Note that most casters, particularly VRS ones, require a position to start streaming correction data.

The "Enter path" button can be used to easily configure a client using a string in one of the following forms:

• For NTRIP client: user:pass@host:port/mountpoint
• For TCP client: tcpcli://host:port

The "Restart client" button force-restarts the built-in NTRIP client. Note that the client automatically keeps trying to connect to the configured caster until it succeeds. If the sensor receives no data for 10 seconds, it automatically tries to reconnect.

RTK configuration page in the web interface

In addition, you can visualize the NTRIP caster source table by pressing the "Sourcetable button". Here you can find more information regarding the NTRIP caster (e.g., host, port, ID, location), available networks (e.g., ID, operator, web data), and corresponding streams (e.g., mountpoint, format, RTCM3 message types, GNSS constellations).

NTRIP caster sourcetable

Supported RTCM3 messages

Besides meeting the general requirements for correction service data, the Vision Navigator requires that the latency (age) of the data should be kept as low as possible (ideally better than 1 second) and at least the following RTCM3 messages for proper operation:

RTKLIB/str2str

RTKLIB’s str2str application has the capacity to divide an incoming data stream into several streams, each with different formats. Users interested in leveraging this functionality on a host system to connect to the NTRIP service, retrieve RTCM3 data, and subsequently relay this correction information to the Vision Navigator via I/O (UART/TCP/UDP), can follow the steps below. These guidelines will cover RTKLIB installation, establishing a connection with the NTRIP service, and streaming data to a designated IP address and port.

1. Update the system packages:

2. Install necessary tools for building RTKLIB: sudo apt - get install build - essential gcc g ++ git

3. Clone the RTKLIB repository: git clone git@github . com : rinex20 / RTKLIB - demo5 . git

4. Navigate to the RTKLIB build directory:

5. Compile RTKLIB

This process will generate an executable named str2str in the RTKLIB build directory.

Within the Vision Navigator web interface, users can navigate to "Configuration → GNSS", then select the "I/O port" option. This will enable users to stream RTCM3 data to any accessible TCP/UART/UDP port on the Vision Navigator device.

Some NTRIP services (including certain VRS services) require receivers to reciprocate with NMEA-GN-GGA_GNSS data. This enables the service provider to assign the user a nearby real or virtual base station. Given these circumstances, users also need to configure Vision Navigator to output the NMEA-GN-GGA_GNSS data. For instance, a TCP port (like TCP4) can be set to exclusively output NMEA-GN-GGA_GNSS data at a rate of 10 or less, as depicted in the figure below.

The setup of the output of NMEA-GP-GGA_GNSS in the I/O section

To establish a connection with the NTRIP service and stream data to a preferred IP address and port, the following command can be implemented:

In this command:

• Replace <username>:<password> with your NTRIP service username and password.
• Replace <ntrip_service_url>:<port>/<mountpoint> with the corresponding URL, port, and mountpoint of your NTRIP service.
• The tcpcli://<IP_address>:<port> argument instructs str2str to output the RTCM data as a TCP server at the specified IP address and port.

This command initiates data streaming. To halt the stream, press Ctrl+C in the terminal running str2str. Depending on your requirements, these steps may need adjustments. For instance, if you desire the stream to initiate automatically at system startup, consider creating a systemd service.

Camera configuration

The user can visualize the camera stream in the "Configuration -> Camera" panel of the web interface. A distorted and downsampled (both in resolution and frame rate) stream of the camera is presented here. As mentioned in Installation guidelines, no static parts or featureless scenes must be present in the image view, as these would affect the sensor’s performance. The user can use the cropping tools on the page to eliminate these featureless areas.

Camera configuration page in the web interface

An example of the image view's cutout

Camera streaming

The camera image streaming implementation on the Vision Navigator employs the Realtime Transport Protocol (RTP), which is a well-established network protocol for delivering video over IP networks. It runs over the User Datagram Protocol (UDP). RTP is designed for end-to-end, real-time transfer of streaming media. The protocol provides facilities for jitter compensation and detection of packet loss and out-of-order delivery, which are common, especially during UDP transmissions on an IP network. RTP allows data transfer to multiple destinations through IP multicast.

The camera stream is not enabled by default. To enable it, head to the "Configuration → Camera" page and change the "Enable stream" status. Two different encodings can be selected in the Encoding setting: H264 or H265. Depending on the streaming method used, different UDP destinations can be chosen: Multicast or Unicast.

Camera stream configuration

Some notes and warnings:

• For the best performance, the images should always be streamed via Ethernet. Image interference commonly occurs during transmission over WLAN.
• The streamed images are compressed to reduce CPU load.
• The receiver must be capable of RTP as well as understand the selected encoding.
• The camera's intrinsic data is available to users upon request. The reference camera model is based on the OpenCV documentation OpenCV Fish-eye Camera Calibration.

For examples on how to enable and read the camera stream, please refer to the Base article Camera Image Streaming with Xsens Vision Navigator.

Measurement sensor configuration

The user can configure the measurement sensor input by accessing the "Configuration → Measurement" panel of the web interface. The measurement sensor, e.g., wheelspeed encoder, data can be coming from any of the UART, TCP, UDP, or CAN ports. However, before setting up the measurement sensor, the corresponding ports should be configured according to Input/output system overview.

Measurement sensor configuration on the web interface

The measurement configuration supports up to five external sensors (up to ten by enabling the advanced features). Each sensor requires a specific definition to be an input to the sensor fusion engine.

• RC (rear centre) – Rear Centre wheel (Most common case). It refers to a velocity in the same rigid body as the sensor.
• RL (rear left) – Rear Left wheel.
• RR (rear right) – Rear Right wheel.
• FL (front left) – Front Left wheel.
• FR (front right) – Front Right wheel.

The user can use one of our presets to configure the sensor (see the figure below). The order of the wheelspeed sensor definition does not matter. The low-level sensor configuration required by any of the ports involves the following fields:

• Measurement Source – To set up the velocity input, start off with selecting between different type of input: Choose Generic Measurement input for direct data input according to I/O wheelspeed sensor or CAN wheelspeed sensor. Alternatively, select a predefined preset, called 'Wheelspeed Sensor'.
• Record raw CAN – When enabled, the sensor records the CAN frames in the bus. Only use when advised, as this option will impact performance.

Once you have selected a measurement source, you will be able to configure the sensor in more detail (see the figure below). When using one of the predefined wheelspeed sensors, some configurations are blocked. 1

1. Use – Enables the wheelspeed sensor. If unchecked, the XVN will not use any other parameters. It can be left unchecked to keep the configuration saved.
2. Trust – Selects how much trust is placed on the measurement based on its reliability and expected slippage. The default value will map to one of the other trust levels depending on the chosen tuning mode. Car, slow and lawnmower will map to the High setting, whereas generic will map to the Very low. This value should be mostly left as default unless the user is experiencing serious wheel slippage, in which case one can experiment lower trusts to see if the impact on the performance is positive.
3. Values sign – When Signed is enabled, the positive and negative values are read. If Unsigned is enabled, all measurements are read as absolute values.
4. Quantization – The expected quantization of the measurements, in the same unit as the measurement values.
   Example: suppose wheelspeed values are being sent via FP_B-MEASUREMENTS in mm/s, while the original source of measurements might be OBD2, where the resolution is km/h. In this case, even though data is sent in mm/s, it is expected that there are gaps in the values corresponding to 1 km/h converted to mm/s, which would correspond to 278 mm/s. In this case, the quantization value to fill is 278.
5. Translation – Translation from the center of the XVN's frame to the center of the wheelspeed sensor axis, expressed in the XVN’s frame in meters.
6. Rotation – Euler angle rotation to move the unit vectors from the XVN's frame to the wheelspeed frame in degrees.
7. Dimension – Enable the use of the wheelspeed measurements for the given axis.

Preset list of the CAN and I/O wheelspeed configurations

Once the wheelspeed configuration is saved, the status of the data input is displayed on the System → Info page.

CAN wheelspeed sensor

The CAN message must be formatted as described in Appendix B for a generic speed input. The user should send the corresponding CAN frames at regular intervals, where the input rate must be at most 50 Hz. The message latency, measured from computing the wheelspeed to broadcasting it over the CAN bus, must be as low as possible. Increased and, in particular, irregular latency degrades the Vision Navigator's performance. The low-level sensor parameters are automatically filled in when one of the preset settings is selected. For example, the figure below presents the configuration when the "Fixposition CAN message (vehicle speed, CAN)" preset is selected.

Example of CAN message (vehicle speed) preset configuration

Based on the CAN frame structure, when the Rear Centre (RC) wheelspeed sensor is selected, the corresponding vehicle wheelspeed value will be written in the Front Right (FR) data field. Thus, the CAN message will be structured as follows:

• FR: vehicle speed value [mm/s]
• FL: 0xffff
• RR: 0xffff
• RL: 0xffff

Else, if two or more wheelspeed sensors are selected, the message structure will be:

• FR: vehicle speed value [mm/s]
• FL: vehicle speed value [mm/s]
• RR: vehicle speed value [mm/s]
• RL: vehicle speed value [mm/s]

The CAN message can support wheelspeed measurements from one or four wheels. However, if two or more wheels are used, the user can combine their vectors and input them as a single rear center wheelspeed measurement. All available presets have been listed in the configuration panel of the wheelspeed module in the web interface (see the figure above). For customizing the CAN message interface of the Vision Navigator, please contact us at [email protected].

Verifying CAN message configuration

For proper operation using the CAN message, the user must verify the following four components:

1. A host machine equipped with a CAN interface should transmit the CAN messages per the specifications detailed in Appendix B. The message adheres to the Classic CAN protocol with CAN ID 0x147 and 0x148 (from 2.102.2). For a single speed input, populate bytes 0-1 with RC. For multiple wheelspeed inputs, assign the payload as follows: FR for bytes 0-1, FL for bytes 2-3, RR for bytes 4-5, and RL for bytes 6-7.
2. Wheelspeed settings in the web interface must align with the composition of the CAN message. For instance, if the user transmits data for four wheelspeed measurements, the user must configure all four data sources in the web interface. Conversely, if only two wheelspeeds (e.g., RR and RL) are used, FR and FL should be left blank in the CAN message. In the web interface, disable sensors 1 and 2 and set sensors 3 and 4 to RR and RL, respectively.
3. Activate the CAN interface on the Vision Navigator system. It is crucial to ensure that the bitrate matches that of the host machine, facilitating seamless communication among all devices on the CAN bus.
4. Note that for this configuration to work, the CAN bus must be connected to CANL (CAN low), CANH (CAN high), and GND (Ground) in the I/O connector.

I/O wheelspeed sensor

For streaming the wheelspeed values via the UART, TCP, or UDP ports, the user must employ the FP_B-MEASUREMENTS message detailed in Output messages. The binary message must be input on a UART/TCP port at a regular interval with a maximum input rate of 50 Hz. The message latency, measured from computing the wheelspeed to broadcasting it over the I/O port, must be as low as possible. The low-level sensor parameters are automatically filled in when one of the preset settings is selected. For example, the figure below presents the configuration when the "Fixposition I/O message (vehicle speed, I/O port)" preset is selected.

Example of I/O message preset configuration

If your system employs ROS1 or ROS2, you can use this ROS Driver to stream the wheelspeed measurements.