Rover-4.3.0-beta5 has been released for beta testing and can be installed using MP or QGC’s beta firmwares link or downloaded manually from firmware.ardupilot.org.
The changes vs -beta4 are in the release notes and copied below.
Autopilot specific enhancements
a) ARKV6X support
b) MatekH743 supports 8 bi-directional dshot channels
c) Pixhawk boards support MS5607 baros
d) SpeedbyBee F405v3 support
Balancebot pitch control improvements and pitch limiting
DroneCAN Airspeed sensor support including hygrometer (aka water vapour) readings
EFI support (electronic fuel injection engines)
Harmonic Notch support (Rover only)
Pre-arm warning if multiple UARTs with SERIALx_PROTOCOL = RCIN
Siyi gimbal support
Bug fixes
a) AtomRCF405NAVI bootloader file name fixed
b) BRD_SAFETY_MASK fixed on boards with both FMU safety switch and IOMCU
c) Compass calibration continues even if a single compass’s cal fails
d) Gremsy gimbal driver sends autopilot info at lower rate to save bandwidth
e) Invensense 42605 and 42609 IMUs use anti-aliasing filter and notch filter
f) OSD stats screen fix
g) RC input on serial port uses first UART with SERIALx_PROTOCOL = 23 (was using last)
h) RunCam caching fix with enablement and setup on 3-pos switch
i) RTK CAN GPS fix when GPSs conneted to separate CAN ports on autopilot
Re getting 4.3.0 released as stable, the balance bot changes resolve one blocker. The reminaing blocker is questions over S-Curve’s straight line tracking. I hope to put effort into resolving this over the coming couple of weeks.
Refering protection with ATC_BAL_LIM_TC/ATC_BAL_LIM_THR, this is a test of the balance bot mentioned here,which has stepper motors with encoders, driven by Pololu TIC500’s, and in which an Arduino does the conversion Speed/Direction to Direct/Quadrature generating the quadrature signals:
The configuration is such that the motors move CW/CCW with a RC pulse (800/1500/2200), so that with a 1500 µs pulse the motors don’t rotate; in this way no direction signals are required.
For this test: ATC_BAL_LIM_TC,0.3 ATC_BAL_LIM_THR,0.1 MOT_THR_MAX,90
and throttle is applied first full forwards (THR.ThrIn=100) and then full backwards (THR.ThrIn=-97).
With THR.ThrIn=100 the protection works but not with THR.ThrIn=-97: THR.ThrOut grows towards -90 (MOT_THR_MAX=90), and the balance bot falls immediately.
When going forward the pitch ATT.Pitch is slightly negative, but when going backwards it turns slightly positive and, without the protection, it goes to 90º (falls).
Here are the RCIN.C2 messages: at first 1956 µs (forward) and later 1115 µs (note it is a 3-channels car radio):
Here is the log. I can do a video if necessary; it is easy to reproduce, and the protection is quite notorious going forward, and also the lack of it going backwards.
Recall that I am not using direction signals: the Pololu TIC 500’s can move the wheels CW/CCW according to the RC pulse they receive (1500µs<>no rotation).
Pixhawk1:
AUX1/2: not connected.
AUX3/4: left encoder wheel inputs (Direct/Quadrature).
AUX5/6: right encoder wheel inputs (Direct/Quadrature).
MAIN1/2: outputs generating RC pulses 800 to 2200 µs for left/right Pololu TIC 500’s (not PWM).
RCIN.C2>1500µs would demand THR.ThrIn>0. → protection works. RCIN.C2<1500µs would demand THR.ThrIn<0. → protection does not work.
According to comment in line 781: // very low negative throttle output means we must lower pitch_high (e.g. reduce leaning backwards), I tried to force protection going backwards:
I modified line 782 to: _pitch_limit_high =1; //MAX(_pitch_limit_high - pitch_limit_incr, 0);
(16 bytes less)
The problem continued: protection forward, no protection backwards, immediate fall.
I modified line 791 to: }_pitch_limit_high =1;
(8 bytes less)
The problem continued: protection forward, no protection backwards, immediate fall.
I modified line 795 to: _pitch_limit_high =1;return output;
(8 bytes less (compiler optimization?))
The problem continued: protection forward, no protection backwards, immediate fall.
So if going forward protection is active, _pitch_limit_low is considered, but going backwards it seems that _pitch_limit_high is not considered, but I don’t know the code.
Please, suggest any other test that can force protection going backwards.
Please, also check precedence and parentheses on line 759: _pitch_limited = (desired_pitch <= _pitch_limit_low || desired_pitch >= _pitch_limit_high);
and if function pitch_limited(): bool pitch_limited() const { return _pitch_limited; }
is used elsewhere.
(Edited because of three replies limit)
Yes, it works beautifully!!!
With the balance bot dimensions (with stepper motors with encoders) I tried first, pitch tuning was very difficult and critical, but it was possible lowering the upper plate 35mm and using 60mm diameter wheels instead of 100mm. I could drive in Auto, Acro and Manual, forward and backwards, as in this indoors video:
