I’m currently trying to establish RTK injection using an NTRIP on my drone. I’m gonna be using a companion computer and won’t have a telemetry connection to a GCS. The most important points of my setup:
It runs on a Cube Orange+ on a CubePilot carrier board with ArduCopter 4.4.4.
The GPS module is an Here3+ rover connected to CAN1.
The FC is connected to a Raspberry Pi 4 via USB.
The RPi connects to the internet via LTE.
I’m planning to use my own base station, but for now, I’m just trying to connect to rtk2go.com.
I’ve checked out and compiled the RTKLIB binaries at GitHub - tomojitakasu/RTKLIB. Now I’m trying to use the tool str2str to connect to rtk2go.com as an NTRIP service and forward data directly to my flight controller:
…with ttyACM0 being the flight controller port and 115200 being the speed of my usual mavlink connection for issuing positional commands.
As you can see, the service seems to receive something. However, the corrections don’t seem to arrive at the rover. My indicator for success is the following: The drone has yaapu telemetry and I know from prior experience that the GPS fix indicator on my Taranis remote should change from 3D (3D-Fix) to DGP (Differential GPS) or Float if it worked. Is this assumption halfway correct and is there a better way to test this?
Also, is there anything else I need to do to make this work, maybe certain necessary settings on the FC? Or might I have a format mismatch somewhere?
module load ntrip
ntrip set caster 3.143.243.81
ntrip set port 2101
ntrip set mountpoint meerssen
ntrip set username blank@supportgis.de
ntrip set password none
ntrip start
the GPS fix on my remote shows “RTK”. However, I’d like to use str2str instead, as mavproxy seems a little heavy just for RTK injection (the CC has a lot to do and little resources to spare).
To have it working with str2str, you will need to create a passthrough between your ntrip connexion and the GNSS unit which we don’t allow in parallele to using the GNSS for navigation.
If you look at mavproxy ntrip implementation, it converts the RTCM message from NTRIP to mavlink RCTM_msg that ArduPilot is able to understand and relay to the GNSS.
So you need either to find a wait to use the mavlink RTCM messages or have a direct connection from your RPI to the GNSS to do the injection.
As a temp solution, you can still tweak mavproxy like :
I have altered the setup to use MAVProxy. This works for the case of a public caster, as outlined in my initial question. Unfortunately, it doesn’t work with my custom caster.
So, here is my updated setup:
I connect an Here+ Base to a Windows pc (RTK pc). The receiver is set to generate SFRBX and RAWX messages.
I use strsvr from RTKLIB on the RTK pc. It aquires the correction data via serial and forwards it to an NTRIP server. The bitrate of the serial connection is 9600bps. The server converts from u-blox to RTCM2.
The NTRIP server forwards the RTCM data to BKG’s NTRIP caster. It’s a simple NTRIP caster that is configured via the files ntripcaster.conf and sourcetable.dat in the directory conf.
Contents of sourcetable.dat:
For mount point foo_stream, an entry with the credentials user1:password1 was made in ntripcaster.conf
The drone’s CC runs MAVProxy with the following .mavinit.scr in the home directory:
module load ntrip
ntrip set caster xxx.xxx.xxx.xxx
ntrip set port 2101
ntrip set mountpoint foo_stream
ntrip set username user1
ntrip set password password1
ntrip start
When everything runs, I would expect the yaapu telemetry display on my remote to change the GPS fix from 3D to RTK or DGP, but nothing happens, not even after a reasonable waiting time of around 20 minutes. MAVProxy confirms that the NTRIP module was started, but when I get the module’s status with ntrip status on the MAVProxy commandline, it says NTRIP: no data.
Also note that str2str, when run on the CC, seems to receive messages. So something seems to arrive.
If I use a public mount point from rtk2go.com, e.g.
module load ntrip
ntrip set caster 3.143.243.81
ntrip set port 2101
ntrip set mountpoint meerssen
ntrip set username xxx@xxx.xx
ntrip set password none
ntrip start
I think I got it now, though this was ‘way’ more complicated than I had imagined.
The final recipe, hoping I haven’t forgotten anything:
Connect the base station via USB.
Download and open u-center, a monitoring and configuration environment for ublox receivers.
Start u-center and connect the base station.
Open the message view at View->Messages View. You now see a tree view of all messages that can be sent to or received from the base station. They can e.g. configure certain settings on the module or contain information about it’s status.
Enable output of RTCM messages: Go to UBX->CFG->MSG, and, in the drop down field, select the Entry F5-05 RTCM3.3 1005. Tick the Checkbox for USB and click on the Send button at the lower left corner of the window. You just sent a configuration message to your base station, telling it to output RTCM messages of type 1005. Now, repeat this process with every RTCM message type in the drop down field except 4072 and 4072.1.
Give the base station a position. Without a position, messages of type 1005, which are essential for RTK, can’t be send. Go to UBX->CFG->TMODE3. If you alreadY know the base station’s position with sufficient accuracy, set the Mode field to 2 - Fixed Mode, then enter the position in the fields below. If you want the base station to compute a position by itself, set the Mode to 1 - Survey-in and enter the minimum surveying time and the desired accuracy below. When finished, click on the Send button at the lower left corner of the window.
If you chose survey-in, wait for it to finish. See UBX->NAV->SVIN for the current status. This view doesn’t refresh by itself and has to be polled with the Poll button next to the Send button.
Check if the necessary messages are being received from the base station. You can open the packet console with View->Packet console to see what is currently being sent. You problably won’t see all RTCM messages you activated, as the required satellites are currently not visible. There should be at least the type 1005 message and one of the others you activated.
Everything else stays as describes earlier, with the exception that the conversion from ublox to RTCM in strsvr can be turned off.