Sounds like a good step to try!
Set GPS_INJECT_TO=0. This might be the culprit.
1 Like
Well took both boards out, reset them to default settings, swapped their locations, and put them back in and started back up along with an additional reboot. It didnāt seem to change anything, still no RTK Fix so then I put in the GPS_INJECT_TO=0 parameter and it didnāt change much either, The UART2s are wired together RX on Moving Base to Tx on Rover.
Just for grins, letās set:
GPS_TYPE=18
GPS_TYPE2=17
It looks about the same. I hooked up both wires Rx to TX so either board could deliver signal if it was the moving base.
I did put Rover 4.2.2 on my Cube Orange but it made no difference.
I also set the GPS Types back to normal
GPS_TYPE=17
GPS_TYPE2=18
Just so I didnāt lose track
Sounds good. I have to admit that Iām a bit stumped. For the moment, I suggest GPS_DRV_OPTIONS=0. Boot and make sure that results in a valid GPS2_RAW.yaw value, and then we can move on to getting the XBee connection working.
I agree we need to switch to a different approach. In that approach does the Rover get itās adjusted correction from the Moving Base via MavLink and the moving base still gets the original correction from the base station via the radio?
With GPS_DRV_OPTIONS=0 wonāt the base station be looking for the original base station link from MavLink?
The other path I could go down is using the original SimpleRTK2B + Heading kit that I bought, which has a small RTK2Blite board with rails on it for the radio. I pushed that approach aside to get onboard with getting more compatible with the Ardupilot Auto Config software. However I am getting to a place where I need to get something to mow the grass.
GPS_DRV_OPTIONS=0 simply routes RTCM3 from the moving base through the autopilot to the rover. It adds some processing overhead but does not appreciably change performance. I think we get a little excited by the prospect of offloading processor workload when it isnāt entirely necessary. Tridge (main developer of the moving baseline codebase) has said as much.
I donāt think thereās a need to completely switch hardware out.
Yuri, I went ahead and set GPS_DRV_Options=0 and it does give an rtk Fixed indication on GPS2 (the Rover). Should I go ahead and set GPS_AUTO_CONFIG=0 and put the moving base back on U-center and set UART2 baud for 115200 so we can try out the radio?
No. Set the radio for 460800 and leave auto configure as is.
Sounds fine. I think that is the configuration we are in right now.
Let me correct myself, The UART2 is still set for 460800 and the actual radio is still set for 115200.
I donāt have the software yet and I have not learned how to change the radio baud rate yet.
I suspect that the OTA data rate bottleneck wonāt be a problem since you were getting a good RTK fix before at 115200. Itās just cleaner to let ArduPilot manage the GPS modules rather than relying on u-Center.
Understood that there is yet another learning curve to climb with the XBee config. I donāt use them for a reason 
If you would rather disable GPS_AUTO_CONFIG and use u-Center to configure UART2 for 115200, have at it. We know we can get back to the present situation fairly easily, though now Iām very curious about setting 460800 on the XBee modules - I wonāt try to force your hand anymore there if that makes you more uncomfortable.
I also need a x-bee USB adapter to allow me to plug the radio into my computer. Maybe I could use the X-Bee port USB port on the ArduSimpleF9P board.
I think you are right and it will probably work with one radio set for 460800 baud, and I am happy to try that out for you and the other users after I get up to speed on the radio programming.
For today, lets just see if we can get this mower going the manual way.
What radio would you recommend to connect the Base Station to the Rover? I am a novice when it comes to radios. I just bought what was packaged with the GPS cards.
Your comfort level with u-Center seems reasonably high at this point, so it makes sense to proceed that way. Once things are working, thereās no need to change anything unless you find that the XBee radios lack the range or obstacle penetration that you require.
The answer to your question opens a big can of worms, and the simple answer is that I prefer the method that works for a given use case. Stick with the XBees unless they prove inadequate.
I tend to prefer using an internet based NTRIP service routed through Mission Planner for fixed base to moving base RTCM3. However, that requires a stable internet connection and a constant GCS telemetry connection. My telemetry, including RTCM3 injection is presently routed through an SIYI HM30 unit that also carries redundant RC and HD video.
Failing an NTRIP service, I still prefer to route fixed base RTCM3 through Mission Planner, but that again requires a constant GCS telemetry connection and a means by which to get the fixed base data to the GCS computer (USB works but can be inconvenient - I crafted a way to use a Raspberry Pi to forward it when I was using a local fixed base and Mission Planner RTCM3 injection).
If you want to avoid using Mission Planner as the conduit, there are plenty of radio options for a more direct connection between a local fixed base and the moving base. I like the 915MHz SIK radios (like these from mRo).
@ktrussell uses Adafruitās Feather LoRa modules with a great deal of success, potentially extending the range over what might be possible with SIK radios (I have no direct comparison data). However, that requires programming the modules with custom code that is available in his repository.
I have also used ESP32 modules with Espressifās ESP-Now protocol in a very similar way to Kennyās LoRa implementation. The range is comparable to 915MHz radios (if maybe slightly better), but, again, the modules require custom programming, as discussed in my blog post from last year.
There are plenty of other options, but these are the ones with which I am most familiar.
Changing topics slightly, Iāve been somewhat vocal here about ArduSimpleās recommended configurations. I dislike them. They require a user to gain familiarity with u-Center, which is not the easiest software to navigate and often results in frustration. Iām least impressed with the SimpleRTK2B+Heading configuration, though they did recently modify it to be a bit more compatible with ArduPilotās ecosystem. On the other hand, itās a shame the SimpleRTK3B+Heading board is so expensive - itās very easy to configure and requires no additional software. I recognize that they are challenged to provide the most compatible hardware possible for a broad range of use cases, but it seems that the default data rates and pin mapping tend to be somewhat limiting in an ArduPilot application. The hardware is OUTSTANDING, but Iād (selfishly) like to see a bit more out-of-the-box compatibility with our use case. I should also give more credit where itās due - their customer service has always been top notch!
1 Like
Well Yuri, I had some surprising results. I set Auto_Config to zero, went on U-Center changed the baud rate of only UART2 to 115200 and booted it all back up. What I got was an RTK Fixed indication on GPS (Moving Base) and GPS2 (Rover) dropped of the screen.
After a long time 10 minutes or so it shows up GPS2: RTK Fixed
The MavLink inspector shows about 18100 which is consistent with the heading
1 Like
Excellent!
Do you still have the crossover cable(s) connected? We arenāt using them at all right now. At a minimum disconnect the moving base TX2 to rover RX2 line. While the radio wonāt ātake overā anything, removing this cable avoids any comms conflicts inbound to the moving base module.
No, I cut that cable and the extra ground wire I but between the boards. They are not needed. I will clean them up and get those wires out of there.
It was alarming to see GPS2 stats missing from the screen completely and there is a long delay after every reboot.
The long delay is a bit puzzling. The extra ground wire was unnecessary - the boards have a common ground if they are powered from the same source (and adding ground connections can cause noise problems).