rt-navi
is a proof-of-concept that real-time application of our
P.V.T solver is possible and gives correct results.
To do that, we use a U-Blox GNSS receiver that we operate in "raw/manual" mode and serves mostly as a measurement system
that we feed to the solver. The solver resolves does all the work and we eventually compare the manual performance to the
firmware. We use U-Blox receivers because they are well documented, well supported and fully capable,
that many not apply to other manufacturers.
rt-navi
is not particularly tied to the receiver, if support for other ever become feasible,
we may give it a try.
rt-navi
expects a single serial interface and currently does operate with a single receiver.
This application is part of the Nav-solutions framework and is licensed under Mozilla V2 Public license.
rt-navi
deploys PPP navigation (direct/absolute) by default. A RTK
proof of concept will be developed in near future.
The PPP navigation mode is compatible with any U-Blox supporting the RAW messaging. RTK is feasible starting from F9P serie.
Install the latest release from the official portal:
cargo install rt-navi
Download our latest application and build it manually.
rt-navi
can then be cross-compiled but it requires the std
library.
git clone https://github.com/nav-solutions/rt-navi
cargo build -r
rt-navi
cannot be compiled with --all-features
(currently).
We use features to select the U-Blox protocol revision, and you can only select one at a time.
The default UBX protocol to be compiled is v23
.
In this example, we switch to more recent protocol:
cargo build --no-default-features --ubx31
List of supported revisions:
- V14
- V23
- V27
- V31
Use -p,--port
to specify the serial interface to the U-Blox.
rt-navi
uses the $RUST_LOG
environment variable to define its logging behavior. Use trace
to unlock all traces.
RUST_LOG=debug rt-navi -p /dev/ttyACM0
[2025-05-11T09:31:21Z INFO anise::almanac] Loading bytes as DAF/SPK
[2025-05-11T09:31:21Z DEBUG rt_navi] deployed with User {
profile: Some(
Pedestrian,
),
clock_sigma_s: 0.001,
}
[...]
[2025-05-11T09:31:21Z DEBUG rt_navi] deployed with Config {
timescale: GPST,
method: SPP,
user: User {
profile: None,
clock_sigma_s: 0.001,
},
[...]
[2025-05-11T09:31:21Z INFO rt_navi] solver deployed
[2025-05-11T09:31:21Z DEBUG rt_navi] deploying ublox..
[2025-05-11T09:31:21Z DEBUG rt_navi::ublox] UBX-RXM-RAWX
[2025-05-11T09:31:21Z DEBUG rt_navi::ublox] UBX-NAV-PVT
[2025-05-11T09:31:21Z DEBUG rt_navi::ublox] UBX-RXM-SFRBX
[2025-05-11T09:31:21Z DEBUG rt_navi::ublox] UBX-RXM-RATE
[2025-05-11T09:31:21Z DEBUG rt_navi::ublox] UBX-MON-VER
[2025-05-11T09:31:21Z DEBUG rt_navi::ublox] ublox: hw-version: 00080000, sw-version: EXT CORE 3.01 (111141) , extensions: ["ROM BASE 2.01 (75331)", "FWVER=TIM 1.10", "PROTVER=22.00", "MOD=NEO-M8T-0", "FIS=0xEF4015 (100111)", "GPS;GLO;GAL;BDS", "SBAS;IMES;QZSS"]
Soon the navigation messages gathering starts, and so does the measurement collection.
When both align and everything becomes feasible, the solver naturally consumes all of this data and we obtain a P.V.T:
rt-navi
currently requires a U-Blox receiver to operate. We offer several compilation options
to select the U-Blox protocol ("protocol"
version being very important, because it actually
defines which receiver you can operate!):
ubx_proto23
v23 (Default, for M8 series)ubx_proto14
v14ubx_proto27
v27 (for F9 series)ubx_proto31
v31 (for newer series)
TODO
We offer a few options to specify initial x
, y
and z
coordiates. This reduces the constraint
to initial fix and make it easier to obtain. We recommend using this only if you have a rather good idea.
rt-navi -p /dev/ttyACM0 --coords-ecef-km=1000.0,2000.0,3000.0
rt-navi
uses the combination of several major crates to achieve its objectives