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
@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
btw, this fix also means that 11 channels works fine with OpenLRSng on APM2. I have my Taranis setup to send 12 channels now, of which the APM2 can use 11. I may change it to allow for 12 if I can't find any issues with that.
Cheers, Tridge
@MarkM, I think I know what is happening, although I haven't been able to reproduce the exact symptoms. I think it is just that OpenLRSng uses a default sync pulse width of 3000usec, which is less than the 4000 our code could handle.
I've built a new firmware that can accept sync pulse widths of 2700usec, and put it here:
http://uav.tridgell.net/MarkM/ArduPlane-apm2-3.2.2-test2.hex
can you please try that? Please also send me your exact OpenLRSng settings (screenshots of TX and RX settings pages would be good). Even if this fixes your issue I'd like to reproduce the exact symptoms if I can.
Cheers, Tridge
@MarkM, I've now setup an OrangeRX 433MHz LRS TX and RX, running OpenLRSng version 3.8.0, connected
to a Taranis. I still can't reproduce the problem though.
Can you send me screenshots of your OpenLRSng configuration, both TX and RX? I'll try setting up exactly the same settings and see if I can reproduce it then.
Cheers, Tridge
@MarkM, thanks for confirming which patch is the issue. Given your receiver is 8 channels, what I suspect may be happening is your inter-frame gap is too small. Can you control the inter-frame gap?Even better if you happen to own a logic analyser and can get a trace :-)
I'm going to try simulating a small inter-frame gap with my setup and see if I can reproduce the issue.
Cheers, Tridge
@MarkM, thanks for that! It seems very likely the change that caused the issue was the increase of the maximum number of RC input channels on APM2 to 11 from 8.
https://github.com/diydrones/ardupilot/commit/236efad159720cf0897ea...
To confirm that I've build you a version of 3.2.1 without that change:
http://uav.tridgell.net/MarkM/
if you can please load that and confirm it works that would be much appreciated.
Once that is confirmed Grant and I will see if we can work out why it causes an issue. We did look at this change very carefully and expected it not to cause issues. If you confirm it is the issue then we'll look at it again, and try to simulate your receiver (which from the logs has 11 input channels).
Is the number of channels on your tx/rx configurable btw? If it is, can you try lowering the number of channels and seeing at what number of channels the issue happens?
Thanks!
-
1
-
2
-
3
of 3 Next