Rover-4.7.0-beta2 has been released for beta testing and can be downloaded using Mission Planner, QGC or directly downloaded from firmware.ardupilot.org.
Upgraded from a pretty dated 4.7-dev version (testing GPS stuff) to 4.7-beta2. No surprises or issues across ~3 hours of runtime. New u-Blox driver is working well with Zed-F9P moving baseline modules. Did some nav tuning, including experimenting with PSC_VEL_FF with maybe a little improvement, but thatās not exactly 4.7 related.
I run a solid handful of Lua scripts using a fair amount of the available feature set, and happy to report no breakage there.
I intend to test Zed-X20P modules in more depth as soon as u-Blox releases the update to include moving baseline (rumored to be soon).
Here are some items that are new to 4.7 that Iāve personally not tested but would be good to get some feedback on if you have time to test a couple of them out
Arm automatically after arming checks complete (set ARMING_REQUIRE=3) (@peterbarker, PR:29066)
DCM fallback disabled by default (see AHRS_OPTIONS) (@rmackay9, PR:31632)
MOT_REV_DELAY allows delaying before reversing motors (@tridge, PR:30188)
Pivot turn control improved with steering deceleration max parameter (see ATC_STR_DEC_MAX) (@stephendade, PR:30539)
Rover AMP limiter added (see BATTn_WATT_MAX, MOT_BAT_WATT_TC) (@SpiciestMayo, PR:31285)
using this version I have encountered following issue:
When starting up, GPS indicates flashing green LED as expected. When arming (via RC channel) get red/green flashing LED and message on GCS āEKF varianceā.
ā> After disarming I get a āEKF failsafe clearedā message and back to the flashing green LED.
This keeps happening practically with every arm/ disarm action.
EK3_MAG_CAL = 6 which is a deprecated option. I think this should be returned to ā2ā (the default)
I wanted to run the log through our hardware report tool but we donāt support .log for that tool sadly. Perhaps you can try it yourself.
The vehicle is outside of course? I think the issue is just that the GPSs havenāt calculated their yaw yet. The 1st GPS in particular only has a status of ā3ā while the 2nd one only has 19 satellites. The GPS log messageās āyawā field are always zero.
Could you give stable a try? I think this will help us determine if itās an ArduPilot issue or something external. Iām pretty confident that this isnāt an AP issue actually.
Have already changed back to stable as this EKF issue didnāt appear in such a fashion previously.
The ArduPilot Hardware Report indicated the presence of a compass which is no longer there. (Previous setup). - Trying to remove it now.
But what Iāve discovered is the COMPASS_USE is showing āENABLEDā (on all 3 comopass units) which I would have thought should change to āDISABLEDā by setting GPS for yaw as per GPS for Yaw (aka Moving Baseline) ā Rover documentation
Could you please clarify if it does in facxt need to go to DISABLED or remain ENABLED?
ā¦ā¦the notes within QGC popping up when selecting this parameter, state: āEnable or disable the use of the compass (instead of GPS) for determining heading.ā
Had a test of this. First note was that itās not included in any default builds, so I used the custom build server instead. Would be useful to note that in the documentation.
I was a bit confused as to whether it was working or not, as it did not always reduce the throttle when the power limit was exceeded (on a real vehicle):
Note the area around 15:30:45 - 15:31:00 where the power is ~60W and the throttle does not reduce. But once I increased the throttle further, the throttle limit came into effect.
It would appear that the thresholding is not quite how I expected (maybe something to do with MOT_BAT_WATT_TC?). Iāll need to look a bit more closely at the maths.
Iāve now had a better look at the Rover AMP limiter.
Due to the limiter using a low-pass filter, there is some lag in entering/exiting power limiting. This is particularly visible for power levels slightly (>150%) over BATT_WATT_MAX.
Iāve create a reference table showing the % throttle decrease per second, based on the value of MOT_BAT_WATT_TC and āPower Ratioā (measured power / BATT_WATT_MAX:
Power Ratio
MOT_BAT_WATT_TC=1
MOT_BAT_WATT_TC=2
MOT_BAT_WATT_TC=5
1.1
-9.80%
-4.95%
-1.99%
1.5
-49.02%
-24.75%
-9.96%
2
-98.04%
-49.50%
-19.92%
5
-392.16%
-198.02%
-79.68%
10
-882.35%
-445.54%
-179.28%
So a MOT_BAT_WATT_TC=5 and MOT_BAT_WATT_TC=200, and the vehicle is running at (for example) 300W power and 50% throttle. The power limiter will reduce throttle at 9.96%/sec, so it will take >5 seconds to reduce throttle to under 50%.
From a user perspective, the Rover AMP limiter is useful for large sudden spikes (ie motor stalling) where the stalling power is >2 times the usual running speed.
Additionally, the limiter only applies to throttle (forward/back movement). It will not affect skid-steer turning. So if a motor is stalling in a pivot turn, it wonāt be limited.
So I think
Rover AMP limiter documentation needs to explain the āreaction timeā a bit more clearly, so the user knows when the limiter will activate
Reduce the default value of MOT_BAT_WATT_TC to 2 (instead of 5) for a quicker response
Add a statustext warning when the limiter is active
