While I can’t compare and contrast too many flight controllers, I used a PX4 FMUv5 controller when I first got started. It was adequate, and I don’t think a GPS-for-yaw mower needs much more. However, I upgraded to a Cube Orange and have been very pleased. I make significant use of onboard Lua scripting, and I can’t help but think the faster processor helps with GPS-for-yaw as well. @ktrussell used a Kakute controller up until recently, and he has likewise found that the Cube Orange is a good upgrade.
I used a Holybro plug-and-play GPS module for proof of concept. It was non-RTK capable, and as such, nearly useless for mowing applications. It did, however, prove that I was on the right track.
I then upgraded to a single Here2 M8P based module with an M8P base station. No matter how I configured things, I could never maintain an RTK Fixed solution (almost always RTK Float). Also, several combinations of magnetometers proved equally disadvantaged on a large steel rover with a combustion engine and spinning blades. I did some decent mowing with that setup, but it never achieved the kind of accuracy I really wanted.
The next step was a pair of simpleRTK2B Zed-F9P boards and a foray into GPS-for-yaw. I was on the bleeding edge when it came to practical use of GPS-for-yaw, which induced a lot of frustration, but I was able to finally reduce the magnetometer errors (and eventually completely eliminate them as the firmware matured). I REALLY like those boards and continue to use them today.
After I upgraded to F9Ps on the mower, I was still using an M8P base station, and RTK Float was still my usual mode of operation. As soon as I upgraded the base station to yet another simpleRTK2B board, everything really started to click, and the mower maintained RTK Fixed almost continuously.
For the price and the ease of integration into the ArduPilot ecosystem, I highly recommend the Cube Orange with Zed-F9P-based boards for all GPS needs in a mowing application. At a minimum, it’s a proven combination, and there’s a lot to be said for not reinventing the wheel (as tempting as it is sometimes!).
Thank you so much @Yuri!!
I will basically second Yuri’s advice. Be sure the controller you get has 2MB of flash (or more). I was happy with the performance of the Kakute F7, but it only had 1 MB of flash which meant it could not run “off-the-shelf” Ardurover that includes the GPS for Yaw feature. If you do not plan to use GPS for Yaw, then 1 MB is fine. The difference in price from something like the Kakute F7 to a Pixhawk Cube Orange is significant.
I was able to get the GPS for Yaw to work on an old Pixhawk 1 (2.4.8) (which has 2 MB of flash). (Demo here: https://youtu.be/A1QbHG6SBUk). I did not put it into operation in the field, but it probably would work OK. I do like the Cube Orange, though. With it, you know you’ve got the horsepower for things to come. The Holybro Durandal controller is pretty popular and I believe has the same processor as the Cube Orange. I probably would have gone with it instead of the Cube Orange but stock was not available in the US.
Ublox sells a C099-F9P evaluation board. I have 4 of them (used them for a work project and for my mower). I also have several Ardusimple RTK2B boards (for same project). The Ardusimple boards are easier to connect. The C099-F9P boards have a built-in wifi chip that can be used between the boards for the RTK corrections from base to rover, but the range is so short that they really are not useful and the extra complexity is of no use. The Ardusimple boards have a connector ready to go to connect to the flight controller.
Good luck with your build! One word to the wise: Be careful with your GPS_POS… parameters. It is very important for the X, Y and Z relationships between your Moving Base and your Rover GPSes specified by those 6 parameters to be pretty close. I have helped another person recently and that was the problem. It gave me a little trouble also a couple of weeks ago when I was getting mine going.
Initial thoughts on beta4:
The firmware updated without issue as always, however, Mission Planner immediately crashed when I tried to connect MAVLink telemetry via TCP. I updated Mission Planner to the newest beta, and that did not solve the problem. I was able to connect via USB, and once the parameters were downloaded, I was able to successfully connect via TCP.
Also, many of my tuning/calibration parameters were lost (making my initial auto mission behave EXTREMELY poorly, especially with that aggressive NAVL1_PERIOD of 2s!). Thankfully I routinely back those settings up, so I reloaded them from a recent file, and all seems well now.
Also, something has gone very wonky WRT fence avoidance. With the same BendyRuler settings as I mentioned in this thread, the mower did not perform well, as you can see in the screenshot. I’m not blaming beta4 just yet, though, because I failed to move two waypoints out of the fence confines like I usually do, but I think it’s worth noting this oddity.
Unforunately, my time to explore this fully is quite limited until later in July (I’m doing some last minute mowing before some other commitments will take me away from this project for a couple of weeks).
That doesn’t sound good at all. Sorry for the troubles…
- the MP evaporation issue has been reported by numerous users (about 5) including myself. I hope @meee1 can get to the bottom of it but he’s struggling to reproduce it with his setup.
- Re the parameter loss, were all parameters lost or just some? If all were lost then this sounds like the parameter-reset-issue which shouldn’t happen anymore because 4.1 includes protection against this. AP will record an “internal error 0x10000000” which should appear on the HUD if it has restored the parameters (which maybe it didn’t). It also keeps a backup of parameters in the APM/STRG_BAK directory. If you have time could you send me any onboard logs, tlogs and the contents of this directory? No pressure though.
- I’ll investigate the Rover fence avoidance feature. This release includes some fixes to how the vehicle backs away from obstacles My short-term guess is setting AVOID_BACKUP_SPD=0 will restore the previous behaviour.
Thanks for the quick reply Randy. I’ll see if I can snag some logs before I’m done for the night.
I’ve seen the MP evaporation act before and watched a bit of the discussion. Usually a simple update to the latest beta fixes it. This time, it was a little worse.
Most of the parameters were saved. The lost ones were mostly anything having to do with accelerometer calibration.
I’ll set the avoidance parameter as suggested for now - thank you again!
The lost accel cal parameters is odd. I’ll check with the other developers.
User GRS26 has discovered that MP evaporation is linked to have two GPSs enabled. I suspect this is an important clue that will help us get to the bottom of the issue.
I don’t see AVOID_BACKUP_SPD as an available parameter, even after a refresh (I don’t have simple avoidance enabled). However, the avoidance algorithm seems to be behaving normally on missions where the waypoints do not fall within the fence confines.
I should be able to get some logs and data to you later.
Randy, I’m uploading all of the logs from today’s session - I’ll email you a link as soon as the upload completes.
I think you’ll see a brief boot in beta3 and then all subsequent logs under beta4, along with the parameters I changed after my first miserable attempt in auto mode (check out that short NAVL1_PERIOD when things aren’t calibrated!). The BRD_IMU_TEMP parameters were not lost in the update - I simply had not updated them properly in the saved file I used for recovery.
@Yuri_Rage as far as I can recall, we haven’t changed anything in Rover’s BendyRuler since the Beta release began, so nothing should be different in your usecase.
Also, waypoints inside the exclusion fence are a strict no go! We do not protect against that case as far as I remember, and the vehicle will keep trying to “reach the destination” but obviously fail to do so.
I just updated one of my rovers with dual CAN GPS to 4.1beta4 (Mateksys H743-Wing). Missionplanner 184.108.40.206 had the CTD (evaporation?) problem. Version 220.127.116.11 (build 1.3.7842.42227) is working fine so far.
Thanks for the report. It definitely seems to be dual-GPS related. I’ll bet if you set GPS_TYPE2 = 0 it will stop evaporating. This is not a long term solution of course though. Hopefully @meee1 will get to the bottom of this.
Thanks, Rishabh. I figured perhaps my poor waypoint placement could be to blame, which is why I mentioned it. I spent the remainder of the day running missions without waypoints inside the fences, and performance was as expected.
Missionplanner version 18.104.22.168 is not evaporating with dual GPS setup. It is running as it should. At least for me.
FYI, the MP evaporation is fixed in the latest beta (22.214.171.124).
Sorry for the question but … Which link here is the version (126.96.36.199)?
All zip and all msi files have the same date/time and the same size, so I would expect them all to be the same version.
The problem is that my mission planner is 1.3.74 build 1.3.7563.27684 and it closes when it connects to my pixhawk 4.
According to @rmackay9 the latest beta version (188.8.131.52) doesn’t close but I don’t know where to download it.
Thanks for your help