Rover-4.3.0-beta4 has been released for beta testing and can be installed using MP or QGC’s beta firmwares link or it can be downloaded directly from firmware.ardupilot.org.
The changes vs -beta3 are in the release-notes and copied below.
Scripting supports implementing AUX functions
Bug fixes
a) BMI085 accel scaling fixed
b) Build with gcc 11.3 fixed (developer only)
c) EKF3 alt discrepancy if GPS or baro alt changed soon after startup fixed
d) Harmonic Notch and ESC telem fix when motor outputs are non-contiguous
e) NMEA GPS’s KSXT message parsing fixed (affected position accuracy)
f) Scripting random number generator fix
Unlike Copter, this probably won’t be the final beta release but any and all testing and feedback is greatly appreciated.
Thanks, Randy. I didn’t figure you were that quick!
For the benefit of those following the topic and release cycles, the HNTCH* parameters have been made available to the user in Rover for quite some time now, however, harmonic notch filtering is not yet implemented in Rover firmware, which could be a source of confusion.
I submitted a PR to 4.4-dev for that implementation which has been merged, and it appears that it may make it into the official 4.3 release as well (TBD).
I expect that most Rovers, particularly electric ones, will not benefit from such filtering, but some combustion engined Rovers may gain a minor advantage by enabling some degree of notch filtering.
I am trying this version ArduRover 4.3beta4 on a balance bot with conventional sensored low KV brushless motors, with wheels directly driven (no pinions/gearboxes). I have looked (for the first time) logs of THR Speed/DesSpeed and I observe a huge 10x discrepancy:
The trajectory for both is in Acro, forth and back a 3.5m straight at home (no GPS, wheel encoders). For the lower part I reduced P on the speed PID, and that made things worse.
The real behavior may be around 1m/s (3s each straight), so close to THR Speed.
Is this normal?
Examining past logs, discrepancy is much lower. This is the same, corresponding to this video:
Re the bad speed control performance (aka, “THR Speed/DesSpeed* and I observe a huge 10x discrepancy”), the biggest contributor to this will be the CRUISE_THROTTLE and CRUISE_SPEED value which is used for the feed forward component OR maybe it is the balance bot tilt PID controller params.
Also if you’re using wheel encoders, I think the big change in 4.3 is that the WRC_ gains must be greatly reduced.
If you have a log I can look at I might be able to give better advice.
As indicated here I cannot assign a switch to “Learn Cruise Speed”, since I use car three channels radios on Rovers, so I look at the logs (till some day copying one of these radios parameters to a radio with more channels).
Certainly several are out of range, as you can extract from the .BIN below, but that was the best I could get with this motors and ESC’s (direct drive to wheels without gears).
See from .BIN. I had not used them in 4.2.x, and I haven’t noticed much effect.
I will appreciate it. Here it is (.BIN and .tlog), and this is the video of it:
It consists of a mission trial (unsuccessful), some straights and some turns. Finally it falls without apparent reason.
The mission (Auto at the beginning, also some straights, indoor with wheel encoders) fails without apparent reason:
so mode is changed to Acro for the straights and turns.
Note that the motors are low KV sensored brushless, with the sensors connected to both the ESC’s and the Pixhawk1 as encoder signals. The result seems reasonable:
If the wheel-rate-controllers are not being used then there shouldn’t actually be any tuning changes required from 4.2.x to 4.3 I think.
This wheel encoder related issue is actually a blocker for the Rover-4.3.0 release so I would like to try and separate differences seen between 4.2 and 4.3 VS tuning required for a new vehicle. To do that I wonder if you could try Rover-4.2 and Rover-4.3 again with one of your vehicles and see if there is any difference? Ideally it would be good to test with your best performing vehicle… or the vehicle that you knew was running OK with 4.2.
Re tuning this new vehicle, I think it might help to set ATC_BAL_SPD_FF to zero. I actually think we should completely remove this parameter because it is a feed-forward using the current speed as an input. This seems extremely strange to me.
I have never written a good balance bot tuning guide but I think it should be done in this order:
confirm the wheel encoders are correctly reporting the distance and speed the vehicle is moving
tune the wheel rate controllers ← you don’t use these though so we can skip this
tune the pitch controller by referring to the PIDP log message or use real-time monitoring
tune the speed controller like a regular rover
For step3 we can see the D term is providing most of the output of the PID controller and it is often hitting the limits (-1 to +1) so I think the ATC_BAL_D-term is too high.
Thanks for the answer. I will test all you say in the following days, but what I experienced on v4.2->v4.3 is that, maintaining parameters (wheel rate controllers disabled), I needed in all balance bots to increase heavily ATC_BAL_D (up to 0.5); if not it began oscillating back and forth on the same place, even disarming by itself (CRASH_ANGLE=45). That stopped oscillations, but a vibration remained (motors pinions teeth knocked).
Later I could get acceptable tunings, always with high ATC_BAL_D, with warnings when writing them, but never on the one with these conventional low Kv sensored brushless motors, with direct drive (no gearing) to the wheels. They have a very high torque (the balance bot can climb ramps).
Also, I don’t know the code, but specially I cannot understand how could happen with the x1000 error on the encoder signals v4.2 interrupt handler (which can be optimized in execution time) that tuning resulted better and with less effort than in v4.3 with the error corrected.
I’m not sure how you’re tuning the Pitch controller but in any case, this should be done in Manual mode and ideally using real-time display of the PID controller’s inputs and outputs (e.g. “piddesired” and “pidachieved”).
I also suspect that these parameter changes should be made to your vehicle
ATC_BAL_FF = 0 (currently 0.5). If anything I would have though this gain should be negative but I have not yet tried this on my own balance bot
ATC_BAL_IMAX = 1 (currently 10). I don’t think it helps to be larger than 1 although it may also not matter.
WRC_ENABLE = 0 (currently 1). I think you said that you weren’t using the wheel encoder controller…
Sadly my balance bot has some hardware problems but I will resolve these issues over the next few days and test some of my advice myself.
I’m continuing my investigation of BalanceBots and I’ve got some enhancements to the pitch controller which moves the ATC_BAL_SPD_FF (feedforward using speed) to ATC_BAL_PIT_FF (feedforward using vehicle’s current lean angle). In my testing this improves the pitch control and allows reducing the ATC_BAL_ gains to reduce the bobbing. Feel free to give this a try if you have time.
I’ve also found that, as you said, the WRC_ (wheel rate controller) doesn’t add any value.
Thanks, I’ll certainly try it (compilation shows it occupies 5K more than version I tried on 20221027, so it contains many changes). In the mean time, I think I have:
an acceptable v4.3 setup on one balance bot;
an acceptable v4.2 setup on the balance bot with direct drive (I think the oscillation was a steering oscillation, not a pitch oscillation (so I reduced ATC_STR_RAT_P to 0.04 and ATC_STR_RAT_I to 0.08, but that gives a slow steering)).
Question: if in your branch you are moving to μs, why still in WheelEncoder_Quadrature.cpp: irq_state.last_reading_ms = timestamp * 1e-3f;?
Txs. This branch is just looking at the control, not the estimation. I think it’s sometimes best not to mix two changes together because it adds confusion as to which change is causing the improvement.
By the way, if you are seeing wobbles in Manual mode and WRC is disabled then the wheel encoder change should not be related.
I always use Acro (or Auto), since in Manual I find that balance bots turn too fast only with a small movement of the radio steering stick (or wheel in pistol radios). How can I control steering rate?
I think tuning the pitch controller in Manual mode is better than Acro because Acro mode has an additional speed controller that run on top of the pitch controller. This will make it harder to input quick changes to the desired pitch angle.
I’ve created a PR that adds add a MANUAL_STR_EXPO which I hope will help resolve the issue with using manual mode. Maybe you could give it a try to see if it helps? If it doesn’t then we can add a MANUAL_STR_SCALE (or similar) param to linearly reduce the manual steering response.
compiled and flashed. Code size was only 56 bytes more than before.
I don’t see any parameter named MANUAL_STR_EXPO to adjust. From Parameters.cpp/.h above it seems to me some declarations, but no code, although I don’t know the code, and I am not too familiar with git.
Steer handling in Manual continues more difficult than in Acro, but I didn’t try Manual before too much.
What am I missing? (May be I didn’t download the correct branch)
Should I find MANUAL_STR_EXPO in MP → CONFIG → Full Parameter Tree?
