This article details the current heading feature available on Piksi® Multi and Duro as of firmware release v1.3. First, the document describes how to set up the Piksi Multi evaluation kit in order to produce heading. Secondly, the document describes how heading can be configured in the general sense. These features can be used to compute the heading and/or attitude of a rigid body or to augment other attitude sensors in navigation, control, and attitude/heading reference systems.
Note: while the Attitude unit provides the heading, the Reference unit can still provide a precise RTK position using stationary base station.
Additional information is also provided in the Moving Baseline RTK White Paper.
Evaluation Kit Configuration
Hardware
For the heading use case with the Piksi Multi evaluation kit, the following system diagram is the recommended configuration. Two Piksi and two antennas should be placed on a moving vehicle. A crossover serial cable should be placed between the RS-232 0 ports between the two evaluation boards. One Piksi (the left Piksi) operates only to provide GNSS Observations to the other Piksi that computes an RTK derived heading (right Piksi). For the purposes of this article, we will call the Piksi that operates to provide the raw GNSS observations only the “Reference Receiver” and the Piksi producing heading measurements the “Attitude Receiver.”
Figure 1 - RTK heading setup with Piksi Multi Evaluation kit
Software
Piksi Multi software must be configured to enable heading output. First, it must be configured to compute its differential solution in what is called “Time-matched mode”. By default, Piksi operates in “low-latency” mode in which there is an inherent assumption that the base station is stationary. In the time-matched mode, each differential GNSS solution epoch is triggered by receipt of the raw observations from a moving secondary receiver. This means that the Piksi differential pair must have equal observation rates which are configured through the “solution rate” and the “output every n obs” settings. It also means that there can be additional latency on the navigation output from any communication delay. As such, we recommend using a direct serial cable rather than a radio to provide corrections. Please refer to tables 1 and 2 below to indicate the required settings.
Reference Receiver Settings
These settings are to be configured on the Reference Receiver only providing observations to the attitude receiver. The Reference Receiver can still do RTK with corrections from either a stationary base station or an NTRIP client. Refer to RTCM Input and NTRIP Client articles for more information regarding NTRIP input.
| Name | Value | Units | Description |
| solution | |||
| dgnss_solution_mode | Low Latency | n/a | Configures Piksi to compute a low latency RTK solution if RTK corrections are received from a stationary base station. |
| soln_freq | 10 | Hz | 10 Hz is the current maximum RTK low latency solution rate on Piksi Multi. |
| output_every_n_obs | 2 | n/a | Enables 5 Hz raw observation output to the Attitude receiver. Observation rate must be the same as on the Attitude receiver. |
| uart0 | |||
| enabled_sbp_messages | 74,117 | n/a | Configures Piksi to send its raw observations and GLONASS biases to the Attitude receiver. |
Table 2. Reference receiver only settings
Attitude Receiver Settings
These settings are to be configured on only the Attitude Receiver computing the RTK heading.
| Name | Value | Units | Description |
| solution | |||
| dgnss_solution_mode | Time Matched | n/a | Configures Piksi to compute a time-matched solution on receipt of observations from a base station. |
| soln_freq | 5 | Hz | 5 Hz is the current maximum time-matched solution rate on Piksi Multi |
| output_every_n_obs | 1 | n/a | Enables 5 Hz raw observation on base and rover. Observation rate must be the same as on the reference receiver. |
| send_heading | True | bool | Enables SBP/NMEA heading output. Heading is calculated from the base station to rover and represents the inverse tangent of the north and east components of the baseline. No smoothing or additional processing is provided to improve heading output. |
| heading_offset | Depends on installation | degrees | Adds an offset to the heading output to rotate the heading vector to align the baseline heading with a desired 0 heading. Valid values are -180.0 to 180.0 degrees. See figure 3 for detail of how this offset is applied in a real system |
| dynamic_motion_model (firmware v2.3 and newer) | High Dynamics | n/a | Sets required dynamic motion model. Use the same setting for all types of applications. |
| uart0 | |||
| enabled_sbp_messages | 0 | n/a | Configures Piksi to not send any data from UART0 |
Table 2. Attitude receiver only settings
Heading Communication (SBP and NMEA)
Heading output will be sent provided the “output_heading” setting is True and the Piksi is in RTK Fixed mode. The heading produced is intended to be the vehicle heading and includes the heading_offset. The heading output is produced by the Attitude receiver in the differential pair.
SBP
For interfaces that are configured in SBP mode, the heading output can take the form of the Swift Binary Protocol (SBP) MSG_BASELINE_HEADING message which is a message id of 0x020F in hexadecimal or 527 in decimal format. This message’s content is detailed below in an excerpt from the Swift binary protocol document; please refer to the SBP support portal page for more information about SBP and the baseline heading message.
Figure 2: SBP baseline heading message excerpt from SBP documentation
NMEA
If an interface is configured in NMEA mode, the heading output is the NMEA HDT message. The HDT message consists of a single field representing the true heading in degrees that should take the form: “ $GPHDT,x.x,T*hh<CR><LF>”
Heading Forwarding
Starting with the firmware v2.4.15, the Reference receiver can forward the heading message received from the Attitude receiver. By doing so, the Reference receiver will provide the RTK position as well as the heading (computed by the Attitude receiver). The feature is supported only in SBP protocol.
To enable the feature, three things are required:
- Enable the message MSG_BASELINE_HEADING — 0x020F— 527 on the interface used by the Attitude receiver to communicate with the Reference receiver. In the example described earlier in this guide:
uart0.enabled_sbp_messages = 527 - On the Reference receiver, change the setting system.heading_forwarding to True (check Show Advanced Settings checkbox to see this option)
- On the Reference receiver, make sure the message MSG_BASELINE_HEADING — 0x020F— 527 is in the list of the enabled messages on the interface to read the RTK position (<interface>.enabled_sbp_messages)
Note that using this method, the latency in the heading information is now tied to the latency you have in the communication between the Reference and the Attitude receivers.
Generalized Heading Information
In general, the key thing that is required to produce heading output are Piksi and two antennas on the same moving vehicle and raw GNSS observation communication between the two Piksis. When an RTK fixed baseline is achieved, the heading is output by the device. This heading is derived from the baseline vector and the heading_offset setting through the equation below. Where is the heading communicated by Piksi, is the East component of the baseline vector, is the North component of the baseline vector, and is the heading offset setting, and is the baseline heading computed from the baseline vector. The vehicle heading, labeled , is computed from the baseline heading plus the heading offset setting ( ) configured by the user. Equation 1 and Figure 3 below visually represents these mathematical relationships.
Equation 1: baseline heading computation
Figure 3: Visual depiction of the relationship between the baseline vector components, the two heading antennas, the Heading output (HDG) and the heading_offset setting