The ardupilot development team is proud to announce the release of version 3.2.1 of APM:Plane. This is primarily intended as a bugfix release, but does have some new features.
The major changes in this release are:
[ul][li]fixed a mission handling bug that could cause a crash if jump commands form an infinite loop (thanks to Dellarb for reporting this bug)[/li]
[li]improved support for in-kernel SPI handling on Linux (thanks to John Williams)[/li]
[li]support UAVCAN based ESCs and GPS modules on Pixhawk (thanks to Pavel, Holger and and PX4 dev team)[/li]
[li]Multiple updates for the NavIO+ cape on RaspberryPi (thanks to Emlid)[/li]
[li]multiple automatic landing fixes, including improvements in flare detection, glide slope calculation and lag handling[/li]
[li]fixed a bug that could cause a change altitude MAVLink command from causing a sudden descent[/li]
[li]re-enable CLI on non-APM1/APM2 boards[/li]
[li]Lots of EKF changes, including reducing impact of ground magnetic interference, reducing the impact of a GPS outage and integrating optical flow support[/li]
[li]added initial support for the PX4 optical flow sensor. Just logging for this release.[/li]
[li]added support for MAVLink packet routing[/li]
[li]added detection and recovery from faulty gyro and accel sensors[/li]
[li]improved arming checks code to detect a lot more error conditions, and change the ARMING_CHECK default value to check all error conditions.[/li]
[li]added support for BBBMini Linux port[/li]
[li]increased number of AVR input channels from 8 to 11[/li]
[li]auto-set system clock based on GPS in Linux ports[/li]
[li]added SBUS FrSky telemetry support (thanks to Mathias)[/li][/ul]
[color=#0000FF]IMU Failure detection[/color]
Perhaps the most important change for this release is the improvement to the detection and recovery of bad IMUs. We have had a number of reports of bad IMU data in flight from both the mpu6000 and lsm303d. Where possible the drivers how try to detect the failing sensor and reset it. Sometimes it can’t be reset, in which case it will be locked out and the other IMU will be used, unless it is the last available IMU, in which case it will still be used. In either case the user is notified of the failure via the GCS so they can land.
[color=#0000FF]UAVCAN support[/color]
The main new feature in this release is support for UAVCAN ESCs, GPS modules, compasses and barometers. Note that while support is in for UAVCAN ESCs and I have been flying with a UAVCAN ESC on my test plane for a few weeks very successfully, support for configuring the ESC is still fairly basic. You will need a debug cable to connect to the ESC to configure it as per the http://uavcan.org website. We hope to add MAVLink enabled configuration soon.
Many thanks to everyone who contributed so much to this release with bug reports, patches and suggestions. My apologies that we didn’t get everything done that we wanted to get done. We have pushed some things out to the next release to prevent the release date sliding back any further.
Nice and thanks! I should give Arduplane a try again. I haven’t been using Arduplane for a long time now after I gave up and switched to multicopters.
Basically, I had a simple question that I found no documentation on and nobody could answer (perhaps because I didn’t include some hot chick in my profile picture):
How do I go about limiting the throws that Arduplane uses when in an auto mode, because I use very large throws when flying aerobatics manually with high rates?
I thought of 2 things:
[ul]
[li] manually limiting the range of RC?_MIN and RC?_MAX[/li]
[li] lower the *2SRV_P proportional gains.[/li][/ul]
I don’t know what’s the best approach in cases like mine. If somebody could please explain that, then I can blow the dust off my plane and continue with my plane endeavours again.
I seem to have a small bug with 3.2.1 on my APM I’m afraid
After upgrading to 3.2.1 I kept getting lockup’s on ailerons, elevator and rudder, can be easily seen with rapid deflections from min to max on the transmitter. The surface will freeze for a moment before resuming.
Thought it might be my Taranis+OpenLRS setup but having changed the firmware back to ArduPlane 3.1.1 everything works as expected again.
Re-flash back to 3.2.1 and the lockups come straight back again.
Would like to go back to 3.2.0 but mission planner 1.3.19 will only let me go back to 3.1.1 or earlier.
[quote=“turdsurfer”]Nice and thanks! I should give Arduplane a try again. I haven’t been using Arduplane for a long time now after I gave up and switched to multicopters.
Basically, I had a simple question that I found no documentation on and nobody could answer (perhaps because I didn’t include some hot chick in my profile picture):
How do I go about limiting the throws that Arduplane uses when in an auto mode, because I use very large throws when flying aerobatics manually with high rates?
I thought of 2 things:
[ul]
[li] manually limiting the range of RC?_MIN and RC?_MAX[/li]
[li] lower the *2SRV_P proportional gains.[/li][/ul]
I don’t know what’s the best approach in cases like mine. If somebody could please explain that, then I can blow the dust off my plane and continue with my plane endeavours again.[/quote]
The new Autotune feature will take care of that. You can adjust the tune level. In your case you may want to start with level 5. Maybe start with P gain for pitch and roll about 20% lower than default.
There are some new parameters since you use it so you need to become familiar with. My biggest problem has been the TECS_SPDWEIGHT parameter. See discussion: viewtopic.php?f=102&t=9646&hilit=TECS
[quote=“turdsurfer”]Nice and thanks! I should give Arduplane a try again. I haven’t been using Arduplane for a long time now after I gave up and switched to multicopters.
Basically, I had a simple question that I found no documentation on and nobody could answer (perhaps because I didn’t include some hot chick in my profile picture):
How do I go about limiting the throws that Arduplane uses when in an auto mode, because I use very large throws when flying aerobatics manually with high rates?
I thought of 2 things:
[ul]
[li] manually limiting the range of RC?_MIN and RC?_MAX[/li]
[li] lower the *2SRV_P proportional gains.[/li][/ul]
I don’t know what’s the best approach in cases like mine. If somebody could please explain that, then I can blow the dust off my plane and continue with my plane endeavours again.[/quote]
You could set up dual rates, and do the Radio Calibration on low rates. The autopilot will then set low rates as its limits, but in Manual mode you can switch to high rates for aerobatics.
[quote=“MarkM”]I seem to have a small bug with 3.2.1 on my APM I’m afraid
After upgrading to 3.2.1 I kept getting lockup’s on ailerons, elevator and rudder, can be easily seen with rapid deflections from min to max on the transmitter. The surface will freeze for a moment before resuming.
Thought it might be my Taranis+OpenLRS setup but having changed the firmware back to ArduPlane 3.1.1 everything works as expected again.
Re-flash back to 3.2.1 and the lockups come straight back again.
Would like to go back to 3.2.0 but mission planner 1.3.19 will only let me go back to 3.1.1 or earlier.[/quote]
Hi Mark
Clearly you have updated the firmware many times on the unit could you please tell me if each time you change it do you loose all of the settings and calibrations that you had previously set up?
Many thanks for your replies guys I have done a backup of the param file so that sounds good.
I take it from what you guys say also all calibrations like radio, magnetometer and APM are also backed up in that file and won’t need doing again either?
Thanks guys now sorted and updated to 3.2.2 without loosing anything. Being new to APM I had not realised that every single thing is stored in the param file even calibrations etc.
