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
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)
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.
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.
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!
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.@ktrussellshould 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
UNHEALTHY GPS SIGNAL Issue:
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.
GPS_POS_X/Y/Z:
The fix here is great! Pivot Turns are very precise now and I believe that general tracking in Auto is improved.
BEFORE:
AFTER:
(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.
bonjour a tous !!!je suis tous nouveau fraichement arriver ;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:
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.
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.
;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:
,???
bonjour