mirror of
https://github.com/PX4/PX4-Autopilot.git
synced 2026-07-24 15:27:41 +08:00
90913df7de
* feat(gps): inject SPARTN corrections alongside RTCM Add a SPARTN transport-layer framer and feed gps_inject_data through both RTCM3 and SPARTN parsers so PointPerfect-style SPARTN streams can be reassembled and written to the receiver the same way RTCM already is. Gated by CONFIG_GPS_SPARTN (default on). Disabled on px4_fmu-v6x where flash is already at the limit; enabled on ark_can-rtk-gps. Depends on PX4-GPSDrivers for automatic u-blox SPARTN input enable. Signed-off-by: alexklimaj <alex@arkelectron.com> * fix(gnss): avoid undefined shift in SPARTN CRC-32 Use uint64_t for the CRC working register so n==32 does not perform 1u << 32 (clang-analyzer BitwiseShift). Signed-off-by: alexklimaj <alex@arkelectron.com> * make format * feat(gps): enable SPARTN support in board configurations * feat(gps): enhance SPARTN support with additional frame tracking and status reporting * fix(gps): frame RTCM3 and SPARTN from a single buffer Feeding every inject chunk to an independent framer per protocol let each one resync inside the other's payloads. That is not symmetric: RTCM3 is covered by CRC-24Q, but SPARTN's header carries no usable integrity check (TF006 is 4 bits over a non-byte-aligned field) and TF005 permits an 8-bit message CRC, so a stray 0x73 in an RTCM3 payload is framed as SPARTN at roughly 1 in 1024. RTCM3-only is what every board actually runs, and over 50 MB of it the two framers produced 211 bogus SPARTN frames (210 declaring CRC-8), each re-injecting up to 1 kB of the stream back into the receiver. The reverse direction produced none. Frame both protocols from one buffer instead: whichever preamble comes first is framed, and a valid frame consumes its own payload, so bytes inside one protocol's frame never start the other's. The same 50 MB now yields zero. Frames are also injected in arrival order rather than all RTCM3 then all SPARTN, and one buffer replaces two (2248 B/instance, down from ~4350 B). Also reject TF002 message types 5-119, which SPARTN reserves, as the one header field with a checkable range. CONFIG_GPS_SPARTN was default y, so it built into every target with a GPS including px4_fmu-v6x, which the flash report showed gaining the framer despite the intent to keep it off. Default it to n and enable it explicitly where it is wanted; the ark GPS boards already opt in, and SITL opts in so the framing tests keep running in CI. Rtcm3Parser and SpartnParser are replaced by CorrectionFramer; their tests carry over to it. RtcmStress fed "garbage" drawn from 0x01-0xD2 to avoid a preamble, which includes 0x73, and RtcmBustedSender ended its stream on a candidate the framer was still waiting to complete; both now avoid every preamble and flush respectively. * feat(gps): enable SPARTN on ARK flight controllers Covers receivers attached over UART rather than CAN. All four targets link with margin; fmu-v6xrt has no px4board on this branch yet. Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com> --------- Signed-off-by: alexklimaj <alex@arkelectron.com> Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com> Co-authored-by: Jacob Dahl <dahl.jakejacob@gmail.com>
29 lines
1.2 KiB
Plaintext
29 lines
1.2 KiB
Plaintext
# RTCM3 data exchanged with GNSS receivers.
|
|
#
|
|
# Published under two topic names that share this definition (see TOPICS below):
|
|
#
|
|
# rtcm_corrections - external fixed-base corrections fed into the vehicle (MAVLink
|
|
# GPS_RTCM_DATA, UAVCAN RTCMStream, GPS drivers in dump mode). Multiple
|
|
# sources are allowed, one uORB instance each; consumers select an instance
|
|
# via their stale-link logic.
|
|
#
|
|
# rtcm_moving_baseline - moving-base GPS output (RTCM 4072 or equivalent) intended for a rover.
|
|
# Single publisher per vehicle (on-board moving base, or a CANnode
|
|
# forwarding MovingBaselineData); consumers only read instance 0.
|
|
|
|
uint64 timestamp # [us] Time since system start
|
|
|
|
uint32 device_id # [-] Unique device ID of the publisher that produced this RTCM
|
|
|
|
uint16 len # [-] Length of data
|
|
uint8 flags # [-] LSB: 1=fragmented
|
|
uint8[300] data # Correction payload (fixed-base RTCM3 and/or SPARTN frames, or moving-baseline RTCM3)
|
|
|
|
uint8 ORB_QUEUE_LENGTH = 16
|
|
|
|
# Sized for the fixed-base corrections case (up to four independent sources). The moving-baseline
|
|
# topic only uses instance 0 (single publisher per vehicle).
|
|
uint8 MAX_INSTANCES = 4
|
|
|
|
# TOPICS rtcm_corrections rtcm_moving_baseline
|