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:
- fixed a mission handling bug that could cause a crash if jump commands form an infinite loop (thanks to Dellarb for reporting this bug)
- improved support for in-kernel SPI handling on Linux (thanks to John Williams)
- support UAVCAN based ESCs and GPS modules on Pixhawk (thanks to Pavel, Holger and and PX4 dev team)
- Multiple updates for the NavIO+ cape on RaspberryPi (thanks to Emlid)
- multiple automatic landing fixes, including improvements in flare detection, glide slope calculation and lag handling
- fixed a bug that could cause a change altitude MAVLink command from causing a sudden descent
- re-enable CLI on non-APM1/APM2 boards
- Lots of EKF changes, including reducing impact of ground magnetic interference, reducing the impact of a GPS outage and integrating optical flow support
- added initial support for the PX4 optical flow sensor. Just logging for this release.
- added support for MAVLink packet routing
- added detection and recovery from faulty gyro and accel sensors
- improved arming checks code to detect a lot more error conditions, and change the ARMING_CHECK default value to check all error conditions.
- added support for BBBMini Linux port
- increased number of AVR input channels from 8 to 11
- auto-set system clock based on GPS in Linux ports
- added SBUS FrSky telemetry support (thanks to Mathias)
IMU Failure detection
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.
UAVCAN support
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.
Happy flying!
Comments
Matthias, is the spc board essentially this:
@Paul : If you need more info about frsky, do contact me . I had updated the doc indeed there :http://plane.ardupilot.com/wiki/common-frsky-telemetry/
@MarkM, thanks for testing it! I did a test flight of it yesterday afternoon and also found it fine, so I will do the 3.2.2 release today.
I really appreciate you helping us track this down. This is a bug that we've had for a very long time. Occasionally people reported stutter in servo movement, but we never worked out why and the dev team could never reproduce it. What we needed was a setup like yours where the effect was very clear and even better it was with a hardware config that I could reproduce.
Cheers, Tridge
@Tridge,
Nice work indeed, I haven't flown it but on the ground that latest firmware seems faultless!!
I've tried rapid stick movements at various throttle positions, with and without the ailerons/flaps attached, varying flight modes and adjusting Ail, Ele, Thr, Rud, Flaps and activating/deactivating inverted flight mode all at the same time and it's perfect.
Will probably be a few days before I can flight test it as I was flying with the first update you put together for me today and quite literally flew the motor off the plane :D
Once the firewall/motor mount are all glued back in I will certainly be flying it, unless you get 3.2.2 out before hand ;)
Thanks again for sorting this, it really is appreciated. Thanks to you, when I fly I look like I know what I'm doing :D
@Tridge,
Nice work!
Regards,
TCIII AVD
@MarkM,
Grant and I believe we've now got to the bottom of this. It turns out that your OpenLRSng configuration just makes the bug much more likely to happen, but it can happen with any setup. It can even happen on a Pixhawk with SBUS or DSM input. It is a very old bug (over 2 years I think), it is just very unlikely to happen except with fairly specific timing.
The trigger for your config is your FLAP_IN_CHANNEL setting, which is 6. If you turn that off (by setting it to 0) then the issue won't happen. It could happen with other channel inputs though, so it could happen before we added the FLAP_IN_CHANNEL option, just with different inputs.
What happens is that the hal.rcin->read() call used to implement the FLAP_IN_CHANNEL logic was clearing the _new_input flag in the HAL RCInput code. If that call happened just before the main radio input code ran, so that another frame couldn't arrive in between, then the plane code would think there was no new RC input frame.
You can tell this is happening because there are messages like this in your log:
2015-02-08 00:12:05.69: MSG {Message : MSG FS OFF 1042}
2015-02-08 00:12:14.74: MSG {Message : MSG FS OFF 1379}
2015-02-08 00:12:24.90: MSG {Message : MSG FS OFF 1186}
2015-02-08 00:12:42.08: MSG {Message : MSG FS OFF 1043}
those messages happen when a RC Input failsafe event ends, but there is no "MSG FS ON" message preceding each one. That is because the failsafe was less than 10 frames, so the start of the outage wasn't logged.
I've built a new firmware with a fix and I'd appreciate you testing it:
http://uav.tridgell.net/MarkM/ArduPlane-apm2-3.2.2-test3.hex
If testing all looks good I'll release a 3.2.2 release soon.
Cheers, Tridge
@Jake,
SBUS and DSM are both TTL serial based protocols.
I think having a converter box for PPM-SUM makes no sense as it just moves the problem to that box. That box would still need firmware on it, which we'd need to write. It is easier for us to make and distribute fixes to the firmware for ardupilot than it is for us to distribute fixes for a converter box.
Cheers, Tridge
Surely that would have to be asked of Spektrum, Futaba, FrSky JR etc as they're the ones making the transmitters and receivers.
I would have thought a digital signal would be worse though, might be the wrong analogy but analog TV signals would still give you some picture with a weak signal. Digital gives you nothing.
Hmm... After the umpteenth problem with using 1980's style analog signals for communication... Is there any thoughts to switch to digital communications?
I'd suggest developing a digital protocol using I2C, CAN, TTL serial, or whatever. Then use only digital signals on the APM board and code. Anyone wanting to support analog signals could then use a special converter box. This would avoid polluting the code with handfuls of proprietary protocols or dealing with analog signals.
We've had many, many, many posts here of flyaways and crashes related to the use of PPM signals, both onboard and externally related. Tens of thousands of dollars worth of gear has been lost. Is there any point where the devs will consider it worthwhile to upgrade to a digital signal path?
Just tried that 2700usec build and the problem has come back with it :(
Can't help with a logic analyser, but I had taken screenshots of my lrs config a few days ago to save me reconnecting just to verify what settings I have. I've uploaded the screenshots to my ondrive - https://onedrive.live.com/redir?resid=F62D8DBECA5CE9A2%21531
When you say inter-frame gap, is that the same as the sync time on the lrsng config (currently 3000us) or the PPM frame config on the Taranis (currently 22.5ms 300u)?
I had found this thread - http://diydrones.com/forum/topics/apm-ppm-from-openlrsng?id=705844%...
Which had me thinking the sync time might be too short as even the openlrs wiki says
-
1
-
2
-
3
-
4
-
5
of 5 Next