APM:Plane 3.2.2 released

The ardupilot development team has released version 3.2.2 of APM:Plane. This is a bugfix release for some important bugs found by users of the 3.2.1 release.

The changes in this release are:

[ul][li]fixed a bug that could cause short term loss of RC control with some receiver systems and configurations[/li]
[li]allowed for shorter sync pulse widths for PPM-SUM receivers on APM1 and APM2[/li]
[li]fixed HIL mode altitude[/li][/ul]

The most important bug fix is the one for short term loss of RC control. This is a very long standing bug which didn’t have a noticeable impact for most people, but could cause loss of RC control for around 1 or 2 seconds for some people in certain circumstances.

The bug was in the the AP_HAL RCInput API. Each HAL backend has a flag that says whether there is a new RC input frame available. That flag was cleared by the read() method (typically hal.rcin->read()). Callers
would check for new input by checking the boolean hal.rcin->new_input() function.

The problem was that read() was called from multiple places. Normally this is fine as reads from other than the main radio input loop happen before the other reads, but if the timing of the new radio frame
exactly matched the loop frequency then a read from another place could clear the new_input flag and we would not see the new RC input frame. If that happened enough times we would go into a short term RC
failsafe and ignore RC inputs, even in manual mode.

The fix was very simple - it is the new_input() function itself that should clear the flag, not read().

Many thanks to MarkM for helping us track down this bug by providing us with sufficient detail on how to reproduce it. In Marks case his OpenLRSng configuration happened to produce exactly the worst case
timing needed to reproduce the issue. Once I copied his OpenLRS settings to my TX/RX I was able to reproduce the problem and it was easy to find and fix.

A number of users have reported occasional glitches in manual control where servos pause for short periods in past releases. It is likely that some of those issues were caused by this bug. The dev team would like to apologize for taking so long to track down this bug!

The other main change was also related to RC input. Some receivers use a PPM-SUM sync pulse width shorter than what the APM1/APM2 code was setup to handle. The OpenLRSng default sync pulse width is 3000 microseconds, but the APM1/APM2 code was written for a minimum sync pulse width of 4000 microseconds. For this release I have changed the APM1/APM2 driver to accept a sync pulse width down to 2700 microseconds.

Many thanks for this great firmware am very new to it but enjoying the learning curve. I currently have 3.2.0 installed if I update with Mission Planner will it keep all the settings and calibrations I have done so far?

Thanks Hally

Hello,
Starting with the release of 3.2.1, I started getting numerous “Bad _____ Health” messages. e.g. Bad Gyro, Ba Accel, Bad AHRS. If I roll back to 3.1.1 (I couldn’t find 3.2.0) they seem to go away. So my question is, was there an improvement in detection of these “Bads” or is the FW causing erroneous warning reports. My plane seems to function normally flying with a warning the whole flight.
Thanks!

@Icarus,
You would need to post a log so we can see if it is real sensor failure that you are seeing.
Cheers, Tridge

Hello everyone, I have a plane problem after update.
I was in automatic mode waypiont aircraft to fly in just for that one repeatedly not to go waypiont 2.
In other modes Plane, it works very well.

Thanks for the help

[quote=“kungrc”]Hello everyone, I have a plane problem after update.
I was in automatic mode waypiont aircraft to fly in just for that one repeatedly not to go waypiont 2.
In other modes Plane, it works very well.

Thanks for the help[/quote]

That has happened to me when I had the Mission Reset switch on. Make sure it’s off before you takeoff. To reset mission make sure it’s in the auto mode and briefly turn the switch on then back off.

.