Hey all, I’ve been following a lot of the threads and youtube videos from @ktrussell and @bitdog etc and it has been a big help in getting my ZTR mower equipped with flight controller and servos. Thanks for all the posts.
My machine is driving great now in the yard by RC and I’m working on nav today. I think I’ll be able to get the ZED-F9P GPS RTK setup working today, but I can’t seem to get my external compass calibrated. I picked up the LIS3MDL board and whatever I do the calibration fails (usually “bad radius”).
Is there a better sensor I ought to be using? Are people using Large Vehicle MagCal with good success? I’ve been using QGroundControl on a Mac and I saw this was NYI (https://github.com/mavlink/qgroundcontrol/issues/8142), but maybe I need to find a Windows box for Mission Planner.
Would it be possible to kick off Large Vehicle MagCal using the mavlink console even without UI support?
You should be able to perform a large vehicle magcal using mavproxy on your Mac. Relying on magnetometers for orientation on large rovers is a bit of a problem in my opinion. We did not use them on our vehicles and use moving baseline gnss but I have done some tests that indicate that good results are achievable just based on a single funds module and using the course over ground as a heading.
@jimovonz thank you! I didn’t know about mavproxy. That solves a ton of my issues. I was able to get MP going from a windows machine within sik radio reach.
I’m going to order another F9P and opt for the moving base. I assume ardupilot will correctly forward mavlink-injected RTCM to both units?
I am glad to be of some assistance The vast majority of my direct interactions with the FC are via Mavproxy on Ubuntu. There have been recent additions to the Rover code that make configuring 2 x F9P modules in a moving base line setup quite easy. It is pretty much ‘plug n play’ baring setting a few parameters. The ‘rover’ module that reports the heading does use RTCM corrections but these come from the onboard ‘base’ module so do not affect your telemetry bandwidth. The FC handles the configuration and transmission of corrections for you. However, if you want an accurate position as well as heading, then the moving base module needs the corrections from a stationary base station (either your own local setup or from a CORS site via internet) . This does affect your telemetry bandwidth. If you have your own base station then there are options for reducing the amount of RTCM correction data that you have to send. We use a wifi connection to our vehicles and I think that we would definitely struggle with the bandwidth available over your typical telemetry radio over the distances we require.
I have my base surveyed-in and a socat bridge from the F9P UART into mavproxy DGPS module (socat UDP-DATAGRAM:127.0.0.1:13320 file:/dev/ttyS0,ignoreeof). Screenshot is from u-center on the F9P rover-side.
As far as I understand it the RTCM3 messages are getting packed into mavlink messages. Then they’re shipped over my sik radio to the rover FC (a Kakute F7 AIO).
What’s odd is when I ran RTCM3 directly over the serial radio to a windows machine running a SNIP RTCM3 decoder they stream across just fine.
Hi @rboyd,
I have run similar setups before with a local base station. It looks like you have everything configured OK but you are suffering from corruption over your link. The legit messages are the only ones that have passed CRC and the other message types are all junk with only failed CRCs. Is it possible that the SNIP decoder simply quietly dropped corrupt packets? You will get better results over a radio link at lower bandwidth so you could try reducing the amount of data you are sending. There are a number of ways to achieve this:
Reduce the frequency - 1Hz is typical but I doubt that you would see much difference in that accuracy of your results at 5Hz
Reduce the number of constellations used - When attempting to get the best results over a radio telemetry link, I compromised on using just GPS + Beidou which gave me approx 80% of the available satellites in my region.
Use the Type 4 RTCM messages in place of the type 7 - these require less data.
There are a couple of ways to reduce the amount of data being output from your base station. Firstly - make sure that you are only outputting RTCM and not UBX/NMEA on the UART connected to your radio. Since the base stations only job is to output RTCM messages, you can set the main navigation rate using the Configure - RATE and setting the measurement Period. I would try 2000ms to start. There is definitely an accuracy trade of with respect to the age of correction data but your typical rover is set to allow loosing corrections for approx 30s before dropping an RTK fix.
After you have set the navigation rate, you should enable only the specific RTCM messages that you need. Use the Type 4 messages (1074, 1084, 1094…). If you decide to exclude some constellations then remember to disable the corresponding RTCM messages to save bandwidth. Set the lowest bit rate for your radio link that meets your data needs.
With regard to wifi modules, I have used a number… From an esp32 with external antenna to full blown outdoor units. We have the luxury of having very large vehicles, so we have full size industrial companion computers and accessories. We currently use the Mikrotik Metal 52 AC in client mode for most of our rovers. Our base stations have the same unit configured as an AP along with an LTE modem and an RPi4 running Ubuntu + CasterREP. The range we get depends on the terrain and what obstacles are in the way but we have never been out of range line of sight and this would be over 1km. We would not expect anything but 100% RTK fix solutions for the entire length of a mission which can last hours. We use high gain survey grade GNSS antennas that are 200mm diameter and typically get a dozen or so satellites at 45 db-Hz or better. We use two serial connections to the Pixhawk and use a dual TTL serial - Ethernet converter to connect to the on board network at 921kbps each. One of these channels is reserved for RTCM corrections + diagnostics exclusively.
Quick update: I had some ESP32 boards floating around here that I never unpacked. I was able to flash https://github.com/DroneBridge/ESP32 (after modifying the code to allow higher baud) and got much better throughput than over the sik. I think I’ll just use a RPi here though.
I ordered some Ubiquiti UAP-AC-M mesh APs to dot the yard with so I should hopefully be able to do wifi to the rover.
I haven’t tried to pipe the RTCM3 through the bigger pipe yet. Hoping to get to that tomorrow. Real work getting in the way.
Update: I got the ESP32 swapped out for a Raspberry Pi Zero W running mavlink-router.
Waiting on a box of cat5e to be delivered tomorrow for POE injectors on my mesh APs, then I should finally be able to get RTCM to the yard.
Working on installing the second F9P tonight for the moving base.
I flipped autopilot on for the first time this evening while I was playing the role of crash test dummy. Even with bad heading and HDOP it was really cool to have it takeover steering for a few seconds, until it almost ran me into a telephone pole and I had to kill power. I have a proximity sensor and a relay board I still need to get wired up.
Sounds like you are making some good progress. I think that the Ubiquity gear will make a big difference. It just so happens that I am evaluating the bigger brother of that unit right now:
The vast majority of my direct interactions with the FC are via Mavproxy on Ubuntu. There have been recent additions to the Rover code that make configuring 2 x F9P modules in a moving base line setup quite easy. It is pretty much ‘plug n play’ baring setting a few parameters. The ‘rover’ module that reports the heading does use RTCM corrections but these come from the onboard ‘base’ module so do not affect your telemetry bandwidth. The FC handles the configuration and transmission of corrections for you. However, if you want an accurate position as well as heading, then the moving base module needs the corrections from a stationary base station (either your own local setup or from a CORS site via internet) . This does affect your telemetry bandwidth. If you have your own base station then there are options for reducing the amount of RTCM correction data that you have to send. We use a wifi connection to our vehicles and I think that we would definitely struggle with the bandwidth available over your typical telemetry radio over the distances we require.
