Hey everyone,
I’ve been working with Here4 with the latest firmware from GNSSPeriph. So far, I’ve successfully configured UAVCAN to receive GPS, Magnetometer, and RawIMU measurements.
Now, my goal is to send RTCM messages to enable RTK. I’ve been using RTCM 3.2 (from EUREF casters) with message types 1006, 1008, 1020, 1033, 1045, 1077, 1087, 1097, and 1127. The strange part is that, although I can see the RTCM messages in the DroneCAN GUI tool, the GPS doesn’t seem to be getting an RTK fix/float.
I’m wondering if anyone has experience with a similar setup or has insights into potential pitfalls I might be overlooking. Is the F9P pre-configured to consume RTCM corrections? Any insights would be greatly appreciated.
Are you sending the RTCM correction through ardupilot, also what is the source of corrections? There is currently an existing issue in Ardupilot where the RTCM packet size greater than 300 is not parsed.
I am not using ardupilot software to send the RTCM corrections since I don’t have access on a pixhawk. I’m communicating directly through CAN with the Here4 via UAVCAN library sending uavcan.equipment.gnss.RTCMStream messages. The corrections are provided by an NTRIP client (tried both RTK2GO and EUREF NTRIP casters), and they are spitted in 128 byte chunks. Below there is a screenshot from the DroneCAN GUI RTK Information panel which shows some indicative RTCM messages as they are received from the NTRIP caster.
If you are using ntrip, note that GPS L5 is still considered experimental and is marked unhealthy, and this information might now be published.
Is it mandatory to use the L5 band? Shouldn’t the GPS be able to operate using just the L1 and the respective corrections?
Unfortunately, since I don’t have access to a Pixhawk I cannot connect the device on Windows and therefore to the U-Center to modify any of the GPS parameters. The best alternative I found was PyGPSClient in which I have access to some of the UBX parameters and monitor the message traffic. In the UBX messages I expected to see the RXM-RTCM acknowledgment but there aren’t any of them as shown in the image below. I tried also setting GPS_DRV_OPTIONS to 32.
If you don’t have L5 band correction, that might be ok. GPS_DRV_OPTIONS to 32 will atleast enable use of L5 band even without correction the quality of position is quite good. The automatic setting of L5 band related stuff was introduced in v1.12, so you need to update the GPS module for that to work.
@sidbh Don’t these methods require a Pixhawk? I have already tried the Serial Passthrough from DroneCan GUI tool on Ubuntu with the PyGPSClient as I mentioned before, but I am not able to do that in windows. What firmware version should I use for the NEO F9P?
@AlexPapadimitriou the firmware at v1.12 has nothing to do with Here4 as flight controller. Here4 as flight controller will run Ardupilot firmware. GNSSPeriph project is for GPS only operation.
The serial passthrough should work from v1.9 onwards. I would look into firewall settings on your machine preventing GUI Tool to open a port. You can also try Mission Planner, that also allows creating TCP/IP port through Here3+/Here4 Passthrough option in DroneCAN Config panel
I wasn’t able to work on that for a while but I’m on it again.
So I’ve updated the firmware to the latest v1.13 from GNSS_Periph and set the GPS_DRV_OPTIONS to 32. However, the RTCM corrections provided by the NTRIP caster do not seem to be acknowledged regardless of the mount point selection.
I also tried to connect it via serial port, but I don’t see any data there (also tried it with GPS_DRV_OPTIONS=4)
I it at all possible to debug this without the use of Pixhawk? Have you successfully used NTRIP for RTCM corrections with Here4?
@AlexPapadimitriou you can use U-Center on linux, you will need to install wine. I have run u-center on linux and it works nicely with wine. Yes, I have tested RTK operation of Here4 through ntrip server and it has worked. Can you share what is the firmware hash of the ublox? it is generally printed at boot on Log Message window in DroneCAN GUI Tool and should look something like this u-blox 1 HW: 00190000 SW: EXT CORE 1.00 (8d3640) Also have you tried pushing corrections directly through Dronecan serial passthrough?
@sidbh Indeed I was able to install u-center and connect via serial passthrough. The NTRIP client of u-center works fine and I get RTK-Float and sometimes fixed too. I’ve also tried RTKLIB with DroneCAN’s serial forwarding and it seems to work fine since it get RTK-Float instantaneously. However, using the UAVCAN protocol (and the same NTRIP caster) doesn’t seem to work that well as the fix status very rarely gets RTK-Float. In my opinion it seems like it drops some of the messages or maybe the format is wrong since I split them in 128 byte chunks. The firmware hash is u-blox 1 HW: 00190000 SW: EXT CORE 1.00 (8d3640).
@AlexPapadimitriou there is a RTK Panel available on DroneCAN GUI Tool. You can use that to analyse the RTCM messages flowing through the wire over DroneCAN. You can verify if what you are sending is making it on the wire intact. You can use dronecan_bridge.py tool in pydronecan to expose DroneCAN to multiple ifaces at once for this.
Hi everyone,
I was wondering if there was anyone able to successfully utilize RTK directly using UAVCAN (without Pixhawk and Mission Planner involved). I am currently publishing the RTCM stream in a similar way that can be found in the PX4-Autopilot repo. However, using the RTK Panel of the DroneCAN GUI tool, as @sidbh proposed, many messages seem to be lost as can be seen in this video, and I don’t get RTK-Float/Fix. For this test I was using the following RTCM messages: 1005, 1074, 1084, 1094, 1124, 1230, from an RTK2GO NTRIP Caster, published at approximately 5-6hz.
@AlexPapadimitriou is your CAN bus terminated? make sure that you turn on CAN Termination on the bus. Here4 has option to turn on termination by setting CAN_TERMINATOR or CAN2_TERMINATOR.
Usually Cube has at least one terminator on, if you are using some other means to push CAN packets you need to ensure that correct termination resistors are present.
@AlexPapadimitriou if you are not seeing the messages regularly on the GUI Tool, most likely there is an issue from the publish side. Which platform are you publishing the messages from. If you can provide detailed setup, I can suggest procedure to debug issues.
@sidbh I’m using an NVIDIA Jetson Orin NX platform with a dedicated CANbus card. I am using CAN1 from Here4 to establish the communication at 1Mbit/s with txqueuelen set to 10 by default (I have also tried it with txqueuelen set to 1000 without any luck). My application uses UAVCAN messages to communicate from Here4 to ROS2 and vice versa, inspired by this project. I haven’t noticed any issues receiving the messages from Here4 neither in DroneCAN GUI tool nor in my UAVCAN application.
Please let me know if there are more details you would like to know.
Use DroneCAN GUI Tools Node Stats panel. Set DEBUG parameter to 4, you will get the CAN and dronecan stats. See if there are any errors visible there. Do share it here as well.
Have you tried bridging to virtual can (vcan) and publish the RTCM messages and verify they appear correctly on dronecan gui tool.
Try reducing the Baudrate to 500kbaud, 250kbaud etc through CAN_BAUDRATE parameter, and on your platform see if that helps.
There is an option to take raw logs of dronecan packets using dronecan_bridge.py tool here pydronecan/tools/dronecan_bridge.py at master · dronecan/pydronecan · GitHub . Use fileout:<log filename> as one of the endpoints for dumping the results, other endpoint being vcan if using that or the original can. Share the resulting logs.
Here you can find the a video of the DroneCAN GUI stats panel. There are some timeouts regardless if the the RTCM messages are flowing.
I tried bridging my can interface with a vcan and connecting to the vcan instead using the DroneCAN GUI, but the results were similar.
Reducing the baudrate seems to cause an issue on the device. Initially I got IERR 0x800277 on the debug log messages and I couldn’t access the device parameters (got a timeout). I had to change to CAN2 which was still at 1Mbit/s in order to access the parameters again. I tried that on both 250000 and 500000 and for both the CAN buses.
I tried to get the raw logs using dronecan_bridge.py vcan0 fileout:log.txt. However, I get the following error: Unable to connect to fileout:log.txt - [Errno 19] No such device.
