Hi, I’m using ardusimple with a fix base and 2 rovers. I have a wifi network between my rovers and a laptop (siting close to the base station). Right now I use Radios for corrections. I’m running ublox ros node from kumar robotics (https://github.com/KumarRobotics/ublox/tree/master/ublox_gps) to get ublox/fix topic. As I use radios, the corrections are transparent to my and the driver.
My question is, could I use the wifi network, instead of radios, to make corrections on my rovers from my base? preferentially using ROS, but not excluding.
Sure this is possible, you will have to split the RTCM+NMEA stream and forward the RTCM from the base to the rover. Alternatively you can use double interface to your CPU, and use one interface for NMEA, and another interface for RTCM so you don’t need to worry about the parsing and protocol splitting.
If this is somehow integrated into Kumar’s software we can’t say, maybe someone from the community can comments on this.
Is rtcm msgs available on GPS+POWER serial port on the base station? do I need to make some configuration in order to get them?
GPS+POWER connects to the ZED-F9P’s USB, yes this can output NMEA, UBX and/or RTCM3
RTCM3 can be output simultaneously to UART1, UART2, USB
Ok, so the circuit is:
Base station produce RTCM3 msg and output to XBee uart. XBee broadcast those msg to all clients. A rover receives RTCM3 msg on XBee uart and make corrections to it’s position. Then it put NMEA, UBX and can repeat RTCM3 msg received. am I understanding right? Is RTCM3 msg the only one needed to make RTK corrections?
It this context the RTCM3 represents observations from a known location’s perspective.
The RTCM3 data generated by the Base can be delivery via multiple channels, you could run an NTRIP server on the computer it is attached too. This could get to the greater internet, and connectivity could be had via hard line connections, or cellular. The data could be rebroadcast, or transmitted over different wireless links in different bands/frequencies concurrently. The message mix could also be modified, for example sending GPS only (1005/1074) over a slower/lower bandwidth channel with a further throw.
Generally you want the end-to-end latency of the transport to be as short as possible allowing the rover to correlate the data with it’s own observations without having an overly deep history buffer.