Thank you! I’ll check them immediately!
I followed the instructions suggested by @ktrussell and I set these values:
- SERIAL4_PROTOCOL = 5 (“GPS”) assuming the 2nd GPS is connected to serial port 4
- GPS_TYPE = 17 (“UBlox moving baseline base”)
- GPS_TYPE2 = 18 (“UBlox moving baseline rover”)
- Set the GPS_POS1_X/Y/Z and GPS_POS2_X/Y/Z parameters for the GPSs (see Sensor Position Offset are here)
- GPS_AUTO_SWITCH = 1
- AHRS_EKF_TYPE = 3 (to use EKF3)
- EK2_ENABLE = 0 (to disable EKF2)
- EK3_ENABLE = 1 (to enable EKF3)
- EK3_MAG_CAL = 5 (“Use external yaw sensor”)
- EK3_MAG_CAL is not used for this feature so it can be left at its default value (“0” for Plane, “3” for Copter, “2” for Rover)
- EK3_SRC1_YAW = 2 (“GPS”) or 3 (“GPS with Compass Fallback”)
on Mission Planner and I wrote them to my Pixhawk 5X.
This is my current configuration:
The distance between both GPS modules is 0.90 m.
I’m using this kit from Holybro and so I have 2 x H-RTK F9P rover modules and 1 x F9P base station, so all the modules run on ublox chips.
I tested the configuration without the RTK corrections and the heading seems to be fine and I’m able to make the vehicle move towards the GPS waypoint (even if there are some errors since the GPS signal isn’t very well).
Now, I would like to use the RTK corrections in order to improve the positioning and the heading information.
Following this document: CubePilot Here+ RTK GPS — Copter documentation I can understand that I can use Mission Planner to inject the RTCM3 corrections from the base to the first GPS module connected to GPS1 connector.
But, what I have to do in order to inject also the RTCM3 corrections to the second GPS modules?
I see that you directly connect both rover modules on UART2, the problem is that my GPS modules use a JST 1.25 10-pin connector and this is the pinout:
I connected the first GPS to GPS1 and the second on the 6-pin connector named GPS2 on my pixhawk 5X.
I think the module doesn’t have an additional UART interface so I do not know how to make enable the communication between them. May be I can use SDA and SCL and enable the RTCM3 messages IN and OUT on I2C under u-center? Are these two pins used by pixhawk or does the GPS port on pixhawk only use the RX and TX pins?
Is there another way to inject RTCM3 corrections from the base station directly to the second GPS by using mission planner?
Today, I disassembled my modules and I’ve found out that, fortunately, there is a connector for the UART2 on both the modules!
So, I can wire both modules by using their UART2 as @Vincent_Miceli and @Yuri_Rage did .
GPS1 RX → TX GPS2
GPS1 TX → RX GPS2
GPS1 GND → GND GPS2
In this way, should I set with u-center:
RTCM3 as protocol IN and OUT on GPS1 on UART2
RTCM3 as protocol IN on GPS2 on UART2
and enable these messages: 1005,1074,1084,1094,1124,1230 on UART2 ?.
Then, I should inject the RTCM3 messages from the base station to the first GPS1.
Is it everything correct?
What kind of baud rate should I set for UART2?
Set 230400 or 460800
1 Like
Thank you! Should I set anything else in mission planner or in my F9P modules?
1 Like
Set:
GPS_AUTO_CONFIG=1
GPS_DRV_OPTIONS=1
1 Like
Today, I updated the firmware on my two F9P modules from v1.12 to the latest v1.30 and then I changed the configuration on UART2 on both modules.
I set the baudrate for UART2 to 460800, but I wasn’t able to change it to UART1 and it is still 38400. Is it mandatory to change also the baudrate of UART1?
This is my configuration for UART1 and UART2:
and I also enabled the following messages: 1005,1074,1084,1094,1124,1230 on UART1, UART2 and I2C on both modules.
Is my configuration OK or should I find a way to set also the baudrate of UART1 to 460800?
I will connect a wire between both UART2 ports to inject the RTCM3 corrections from GPS1 to GPS2.
Sorry for the stupid question!
Reset them to default and get out of u-Center. Use GPS_AUTO_CONFIG as I have been telling you.
1 Like
Thank you for your suggestion.
So should I also reset the settings on UART2 for the RTCM corrections?
If I use GPS_AUTO_CONFIG, how can the GPS2 understand that it will receive RTK corrections on its UART2 port from the GPS1? Shouldn’t I enable the RTCM3 protocol on UART2?
That’s what GPS_DRV_OPTIONS=1 tells the autopilot when it does the configuration.
I can’t explain any clearer:
Set things back to default in u-Center
Set GPS_AUTO_CONFIG=1
Set GPS_DRV_OPTIONS=1
1 Like
@marcusbarnet I think that the part you are missing is that Ardupilot can relay RTCM messages between the two F9P modules. For this GPS_AUTO_CONFIG to work, each module needs to be connected the to flight controller via the modules UART1 (no direct connection between the modules is required). Ardupilot takes care of the config of both modules and forwards the RTCM data from the base F9P to the rover F9P.
1 Like
Sorry, I didn’t get that these two parameters are enough to make both GPS1 and GPS2 work in RTK.
I’ve found their explaination on: Complete Parameter List — Copter documentation
GPS_AUTO_CONFIG = 1 → Enable automatic configuration for Serial GPSes only (hope it works also on pixhawk 5X)
GPS_DRV_OPTIONS = 1 → Use base station for GPS yaw on SBF (should it be -ublox-?!)
I just can’t understand if I still need to connect UART2 from GPS1 to UART2 on GPS2.
By reading this post from @Yuri_Rage, it seems that I still need to connect both modules by using their UART2 interfaces: KevinG's Autonomous zero-point turn Lawn Mower - #107 by Yuri_Rage
It is imperative that the rover and moving base communicate directly with one another, with the moving base providing RTK injects directly to the rover using the boards’ built in UART 2 ports. The flight controllers do not provide enough bandwidth/processing time for those injects to be passed through the controller successfully and at a high enough rate to support GPS yaw.
My ugly solution is pictured here. I wasn’t sure if it was going to be permanent (or even if it would work), so I soldered some female headers onto the UART 2 (TX2/RX2) pins of each board, and then secured jumper wires with some hot snot. They are the green and white wires pictured.
You simply connect TX2 from one board to RX2 of the other, and vice versa. ArduPilot’s GPS autoconfiguration should take care of the rest, so there should be no need to use uCenter to configure the ports directly.
Is it correct?
However, I have a pixhawk 5X and it provides two ports: GPS1 with 10-pins and GPS2 with 6-pin connector and my two F9P modules are connected to these ports at the moment.
My configuration should be:
Base station placed at a fixed position on the field → First F9P module as moving base → Second F9P module as rover.
No direct connection between the two F9P modules (UART2) on the vehicle is needed
1 Like
OK, thank you a lot!
Wait just a second.
If you use GPS_DRV_OPTIONS=1, you MUST connect the two GPS modules via their UART2 ports (which is what I thought you intended to do from the start).
If you prefer that all of that traffic be routed through the autopilot, then set GPS_DRV_OPTIONS=0. In that case, you do not need to wire the two modules directly together.
2 Likes
Exactly! I want to avoid to use autopilot to route the traffic since it might be quite slow compared to a direct serial cable connection (I guess).
So, to recap, reset module from u-center, then:
GPS_AUTO_CONFIG=1
GPS_DRV_OPTIONS=1
and wiring:
GPS1 RX → TX GPS2
GPS1 TX → RX GPS2
GPS1 GND → GND GPS2
and without doing anything else, I will just have to inject RTCM3 corrections from my base station to autopilot by following these instructions (Here+ RTK GPS — Copter documentation), is it correct?
2 Likes
Yes, that is correct.
1 Like
Sorry - I did sort of jump in there. @Yuri_Rage is correct with regard to GPS_DRV_OPTIONS settings. However, I have used the GPS_DRV_OPTIONS = 0 settings with no direct connection between modules on multiple vehicles with no heading issues (I have been using a moving baseline setup with F9P modules long before it was suported by Ardupilot with my own custom code - including direct connection of the modules). The RTCM data represents approx 1% of the bandwidth of the serial port and I do not see any advantage to the extra effort required to connect the two modules directly.
2 Likes
As long as the F9P firmware is 1.13 or better, I agree that there is little detriment in passing the data through the autopilot. I still use GPS_DRV_OPTIONS=1 because it is fairly easy to set up.
And if the F9P firmware is out of date, it should really be updated! There are lots of known issues with legacy firmware for that module.
1 Like
For the moment, I think I’ll first try to use the cable between both UART2 ports and I’ll will let GPS_DRV_OPTIONS=1 to handle the settings on both modules.
I updated both modules mounted on the rover to [ZED-F9P HPG 1.30 firmware] released on 23-Dec-2021.
Tomorrow, I’ll update the base station with the same firmware.