Rover-4.1.0-beta7 has been released for beta testing!

Rover-4.1.0-beta7 has been released for beta testing and can be downloaded from the ground stations (e.g. Mission Planner, QGC) using their beta firmwares links

The changes are in the release notes and also copied below

  1. Enhancements
    a) Flywoo F745 supports external I2C compasses
    b) GPS-for-yaw arming check added
    c) GPS_DRV_OPTIONS allows forcing UBlox GPS to 115200 baud
    d) Lua scripts can be placed in root of ROMFS (only relevant for developers)
  2. Bug Fixes
    a) Beacon driver protected from requests for data for non-existant beacons
    b) CAN threading fix to resolve potential lockup when lua scripts use CAN
    c) EKF3 GSF can be invoked multiple times with source switching (no longer limited by EK3_GSF_RST_MAX)
    d) EKF3 IMU offset fix (vehicle’s reported position was slightly incorrect if INS_POS_XYZ params set)
    e) Motor test stops and reports failure if arming fails
    f) OSD overwrite and nullptr check fix
    g) Proximity sensor pre-arm check disabled if avoidance using proximity sensors is disabled
    h) RCOut banner displayed at very end of startup procedure to avoid invalid output

The feeling in the dev team is that we are actually getting fairly close to the stable release so this could be the last beta releases before the official stable release.

All testing and feedback is greatly appreciated!


Great news, Randy…and great fixes as always! Looking forward to getting this one onto the mower and on its way.

Also, I think this is as good a thread as any to raise this possible documentation issue:

The speed/throttle tuning documentation specifically advises against using the ATC_SPEED_FF term, claiming that it is unused:

The P, I and D gains for this controller are held in ATC_SPEED_P, ATC_SPEED_I, and ATC_SPEED_D parameters respectively. ATC_SPEED_FF is not used.

However, as I delved into tuning in a probably unhealthy amount of detail, I noticed that the AR_AttitudeControl::get_throttle_out_speed() method specifically adds the FF term to the output.

Am I simply misreading the code, or should the documentation be updated to reflect the inclusion of the FF term for speed/throttle tuning?

Great to see this Randy (@rmackay9) . I specifically noted 1c: “GPS_DRV_OPTIONS allows forcing UBlox GPS to 115200 baud”. I assume that is my request for UART2 baud on both GPSes to be set to 115200, although it does not explicitly state “UART2”. I was not expecting to see this enhancement, given @Tridge’s comments elsewhere.

I installed beta7 and the latest MP beta this morning, checked that GPS_AUTO_CONFIG was 1, and checked the box to set the bit for the 115200 baud in GPS_DRV_OPTIONS (which set the mode to 5). I did not get an RTK Fix on the MB. Checking with Ucenter, I saw that the baud for UART2 for both GPSes was still 460800.

Just wondering if I missed something.

Thank you much!

no, this is for the uart connected to ArduPilot. It is for some ublox M8 modules that can’t handle 230400

OK. Understood. That explains it!


Thanks for the note re the speed controller’s FF. I’ve updated the docs to instead say “ATC_SPEED_FF should b left at zero”.

I have thought a couple of times that we should use FF and instead get rid of the cruise-speed and cruise-throttle parameters. The only thing is that it might be harder for people to mentally calculate what FF should be. If we did this we would change what the “Learn Cruise” does to instead set the FF value so this method would be no harder.

… anyway, there are bigger fish to fry probably. S-Curves is what I’ve got to do next.


Thanks for the explanation - I understand. There’s always room for improvement, but I am satisfied that throttle tuning for rovers is perhaps a low priority. I haven’t found it to be a particularly difficult challenge, it was just a curious discovery that FF was included in the control loop output.


It’s been raining a bit here this week, so I haven’t had much chance to test the new build. I did look through the release notes, and it looks like a lot of them directly address many of the concerns in the ongoing discussions regarding moving base configurations and GPS-for-yaw. The weather is improving, and I hope to do some good testing shortly. Thank you as always for the fixes!

1 Like

I took beta7 for a test drive yesterday and today, and here’s what I’ve got:

  • EKF yaw not recovering if GPS-for-yaw lost (issue) – resolved for beta7 (we think)

    • This seems to be working. I experienced several yaw realignments over the course of several hours of mowing.
  • GPS-for-yaw at 5hz leads to more GPS unhealthy messages (discussion) – resolved for beta7 (we think)

    • I notice no change here. The GPSs occasionally report “No Fix” or even “No GPS” for very brief periods. It is typically not enough to throw the EKF off, but it does result in warning messages. I have GPS_RATE_MS * = 200. While I did not test the faster 10Hz rate, I suspect these warnings would be fewer at that rate, though previous testing shows that performance is worse at 10Hz despite the false perception that it’s better because the FC complains less.

    • I suspected my heavy use of Lua scripting might be causal here, so I disabled all scripting during today’s session. It made no difference - the sporadic anomalies and warnings remained present.

  • Unhealthy GPS Signal when GPS_DRV_OPTIONS=0 (discussion) – resolved for beta7 (we think)

    • I have not yet tested this but probably should.
  • ArduSimple F9 GPS does not work with GPS-for-yaw unless GPSs directly connected (discussion) – resolved for beta7 (we think)

    • Unless there were further changes after my previous testing of this feature, I expect this works as advertised (but should generally not be recommended, since a direct connection between the F9P UART2 ports provides a cleaner communication path and more stable operation).
  • Kenny Trussell suggestions for GPS-for-yaw config improvements when GPSs directly connected (discussion) – resolved for beta7 (we think)

    • I’m not certain the changes directly address the issue at hand in the referenced thread, but it appears overcome by events. There are plenty of interface boards capable of 230400 and 460800 baud rates, including the one Kenny uses. @ktrussell should probably weigh in here.
  • GPS_SAVE_CFG option does not performs a complete save of the uBlox F9 config (discussion) – resolved for beta7 (we think)

    • Tested today. No change from previous. GPS_SAVE_CFG=1 followed by GPS_AUTO_CONFIG=0 on successive boot cycles yields constant “Unhealthy GPS Signal” warnings just like before.
  • GPS_POS_X/Y/Z relative to IMU or COG? (discussion, PR) – resolved for -beta7

    • Appears fixed per discussion.

I have been running beta7 for a few days and it has been working fine.

Some notes in follow up to @Yuri_Rage’s post:

I can corroborate that if GPS_AUTO_CONFIG=0, “Unhealthy GPS Signal” is constant. No noticeable issue with navigation or yaw, however.

GPS-for-yaw config improvements:
As far as I can tell, everything is fine here. Personally, I still feel that that ArduPilot should let the user specify the value to which Auto Config will set the GPS UART baud rates, but it is not a show stopper.

The fix here is great! Pivot Turns are very precise now and I believe that general tracking in Auto is improved.

BEFORE: image
AFTER: Good Pivots cropped

(Full disclosure: I had the INS Position values all at 0. Fixing that and the fix to the code enabled the new and improved pivots.)

Possible issue with BendyRuler:
I have been using BendyRuler quite a bit with exclusion fence polygons and circles created in Mission Planner. If I turn off avoidance by setting AVOID_ENABLE=0 and plan a mission through an exclusion fence, the vehicle will pause briefly when it encounters the fence, but then pass on through the fence.

1 Like

bonjour a tous !!!je suis tous nouveau fraichement arriver :smiley:;tous d abord un grand bravo a toute cette evolution ,je suis impressionné je suis depuis un petit moment toute l evolution ;j ai moi meme investie dans un kit ardusimple avec systeme 3gps ;pas simple :sueur_sourire:mais avec un peu de patience on y arrive !!la ou je bloque c est justement sur les positions gps et imu .sur ardupilote il y a un correcteur -5.5 POS GPS1 X,Y,Z et la??mon gps droit 0.233 .gps gauche -0.233 et les deux en x -0.183 ET LA Z??? je ne sais pas ?? j espere que j ais reussie a me faire comprendre :sueur_sourire:

un grand merci pour votre aide.

1 Like

Hi @Christophe,

For the GPS position it is described here on the wiki.

So Y is right, X is forward and Z is down. So if the GPS is above the center-of-rotation then it should be a negative number. E.g. 10cm above the center of rotation would be -0.1.

bonjour rmackay9. :sourire:

UN GRAND MERCI .pour votre réponse rapide !!!
je vais corriger mes parametres de configuration .
je suis accuellement en realiation d un rover electrique a deux roues motrice.

encore merci a tous :clin d’œil:

1 Like

bonjour :grinning:

je vien de finir ma configue et je voulais avoir une confirmation !:thinking:

si je DÉSACTIVE use compass 1 ,use compass 2 , use compass 3!

toutes les données des boussoles sont disabel …il reste les info gps ??

j ai ma base et mon rover en rtk fixe ,

Sur mon écran je vois l’ orientation de mon rover ligne rouge qui correspond à ma direction visuel de mon rover placé dans mon jardin.

sur mon écran Yaw(deg) 25.42

esque que ma config est bonne ??

je voudrais l orientation donnee uniquement par mes deux gps sans boussol.

je pense que j ai réussie​:sweat_smile::sweat_smile:,???


Le mer. 25 août 2021 à 04:03, rmackay9 via ArduPilot Discourse a écrit :


Ok, so you’re using GPS-for-yaw which is described here on the wiki.

There’s an active discussion here as well regarding setting up GPS for yaw using two ArduSimple GPSs.

:hugs:bonjour :grinning: rmackay9

MERCI pour votre patience et vos reponses rapide!!!

juste pour info !!

j ai lue la discution ,les interrogations sur le kit (Moving Base)petit carte empilé sur une grand carte rtk2b .

je dispose de se kit pensent me simplifié la vie en configurant avec ardusimple en suivant leur doc.

Mais sans résultat pour le lacet !!!

j ai donc suivie la configue de deux cartes rtk2b cote a cote avec une liaison rx ,tx et la petit carte (Moving Base) en base fixe

et cela fonctionne bien !!!

amicalement christophe🤗

Le jeu. 26 août 2021 à 02:23, rmackay9 via ArduPilot Discourse a écrit :

1 Like

Ah, excellent news! Thanks for the feedback.

I know Rover-4.1.0 is on the cusp of release candidate status. Is there anything else in need of testing or validation?

1 Like