The ArduPilot development team is proud to announce the release of the 3.5.0 version of APM:Plane. There have only been a few small changes since the 3.5.0beta1 release 3 weeks ago.
The key changes since 3.5.0beta1 are:
- addition of better camera trigger logging
- fixes to override handling (for users of the OVERRIDE_CHAN) parameter
- fixed a pulse glitch on startup on PX4
See the full notes below for details on the camera trigger changes.
For completeness, here are the full release notes. Note that this is mostly the same as the 3.5.0beta1 release notes, with a few small changes noted above.
The biggest changes in this release are:
- switch to new EKF2 kalman filter for attitude and position estimation
- added support for parachutes
- added support for QuadPlanes
- support for 4 new flight boards, the QualComm Flight, the BHAT, the PXFmini and the Pixracer
- support for arming on moving platforms
- support for better camera trigger logging
New Kalman Filter
The 3.4 release series was the first where APM:Plane used a Kalman Filter by default for attitude and position estimation. It works very well, but Paul Riseborough has been working hard recently on a new EKF variant which fixes many issues seen with the old estimator. The key improvements are:
- support for separate filters on each IMU for multi-IMU boards (such as the Pixhawk), giving a high degree of redundancy
- much better handling of gyro drift estimation, especially on startup
- much faster recovery from attitude estimation errors
After extensive testing of the new EKF code we decided to make it the default for this release. You can still use the old EKF if you want to by setting AHRS_EKF_TYPE to 1, although it is recommended that the new EKF be used for all aircraft.
Parachute Support
This is the first release with support for parachute landings on plane. The configuration and use of a parachute is the same as the existing copter parachute support. See http://copter.ardupilot.com/wiki/parachute/
Note that parachute support is considered experimental in planes.
QuadPlane Support
This release includes support for hybrid plane/multi-rotors called QuadPlanes. More details are available in this blog post: http://diydrones.com/profiles/blogs/quadplane-support-in-apm-plane-...
Support for 4 new Flight Boards
The porting of ArduPilot to more flight boards continues, with support for 4 new flight boards in this release. They are:
- the BHAT board
- the PXFmini
- the Qualcomm Flight
- the Pixracer (the first of the FMUv4 series of boards in the Pixhawk line)
More information about the list of supported boards is available here: http://dev.ardupilot.com/wiki/supported-autopilot-controller-boards/
I think the Pixracer is a particularly interesting board as it is so small, and will allow for some very small planes to fitted with an ArduPilot based Autopilot. It is really aimed at racing quads, but works well on small planes as well as long as you don't need more than 6 servos. Many thanks to AUAV for providing development Pixracer boards for testing.
Startup on a moving platform
One of the benefits of the new EKF2 estimator is that it allows for rapid estimation of gyro offset without doing a gyro calibration on startup. This makes it possible to startup and arm on a moving platform by setting the INS_GYR_CAL parameter to zero (to disable gyro calibration on boot). This should be a big help when flying off boats.
Improved Camera Trigger Logging
This release adds new CAM_FEEDBACK_PIN and CAM_FEEDBACK_POL parameters. These add support for separate CAM and TRIG log messages, where TRIG is logged when the camera is triggered and the CAM message is logged when an external pin indicates the camera has actually fired. This pin is typically based on the flash hotshoe of a camera and provides a way to log the exact time of camera triggering more accurately. Many thanks to Dario Andres and Jaime Machuca for their work on this feature.
Lots more!
That is just a taste of all of the improvements in this release. In total the release includes over 1500 patches. Some of the other more significant changes include:
- RPM logging
- new waf build system
- new async accel calibrator
- SITL support for quadplanes
- improved land approach logic
- better rangefinder power control
- ADSB adapter support
- dataflash over mavlink support
- settable main loop rate
- hideable parameters
- improved crash detection logic
- added optional smooth speed weighting for landing
- improved logging for dual-GPS setups
- improvements to multiple RTK GPS drivers
- numerous HAL_Linux improvements
- improved logging of CAM messages
- added support for IMU heaters in HAL_Linux
- support for RCInput over UDP in HAL_Linux
- improved EKF startup checks for GPS accuracy
- added raw IMU logging for all platforms
- added BRD_CAN_ENABLE parameter
- support FlightGear visualisation in SITL
- configurable RGB LED brightness
- improvements to the OVERRIDE_CHAN handling, fixing a race condition
- added OVERRIDE_SAFETY parameter
Many thanks to everyone who contributed to this release! The development team is growing at a fast pace, with 57 people contributing changes over this release cycle.
I'd like to make special mention of Tom Pittenger and Michael du Breuil who have been doing extensive testing of the plane development code, and also contributing a great deal of their own improvements. Thanks!
Comments
Crash Log
Hi Guys, hoping someone has some time to take a quick look at my flight log from todays flight. Unfortunately it ended badly losing control while flying virtually straight and level in FWBA. Our airframe has been tried and tested over many hours. We were doing a few new tests like flying with a joystick and testing another video transmitter. Really has us stumped. Any help greatly appreciated.
Hi Andrew,
RPM_TYPE = 1, 3.3V pulses connected between Sig and GND on AUX5, RPM_MIN = 0, RPM_MAX = 1000, BRD_PWM_COUNT = 4. Status tab always reports rpm1 = 0 (and rpm2=0). Am I missing anything? Has anyone else got this rpm working? Any help greatly appreciated for this new feature.
@GocGoc,
You need to set RPM_TYPE to 1 to start with, and attach the sensor to signal and ground pins of AUX5 port.
I'd actually suggest you stick it on a scope first, just to see what the signal is like. It looks for pulses with 3.3V TTL levels.
You can use RPM_SCALING to fix the scale factor between pulses and the real RPM value, either due to gearing or the use of multiple magnets.
Cheers, Tridge
Thankyou
Great work realasing this new version and thanks for your hard work everyone!
I am very happy to see the improved camera trigger logging. I have read through the conversation on github regarding this new feature. Still I am not sure what is the best way to construct the hardware in order to detect this signal. Can someone explain this a little bit better? I am using Sony A6000.
Hi, sorry i didnt realise. I just saw big conversation with Andrew Tridgell on the diy drones post with possible similar issue on this post > http://diydrones.com/profiles/blog/show?id=705844%3ABlogPost%3A1899...
I dont even know if its a bug with arduplane but thought this would be good place to get help :) unfortunatly, as per my posts above, i have no logs from the time when the problem happened... so frustrating. Not much can be done really, unless the problem was the same as the one posted by Andrew where he said the the comment below, although i dont really understand what he meant exactly.
"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"
Please report bugs in the issue tracker here. Providing a log for bugs like this make it *much* easier to track down so please provide anything you have available.
I've had no luck reproducing the problem this evening although to get the lots but i just remembered this problem happening one other time during my build. I was showing a friend the half built plane, plugged it in and after 30 seconds or so the controls went nuts again but i forgot about it until it happened again yesterday...
So testing this tonight trying to replicate, i have moved all controls all over the place but its been solid as a rock. I have also left it powered up for over an hour and still solid. yesterday the problem occured approx 5 mins after it was powered up.
So.. bit stuck here.
I am going to move away from SUMD and back over to PPM. at least with an analogue signal the built in ppm decoder will do the work and if something did go wrong with PPM then it would just glitch i think as i confirmed that PPM was getting through to the receiver ok as have camera pan channel on a PWM plug direct from the Rx and that still worked when the SUMD was screwed.
Possible serious bug?… but unsure if its problem is with Arduplane or openLRS. I’m in the process of building a skywalker with arduplane 3.5.0 and during setup and testing on the ground all of my controls went completely crazy, basically no control. Any stick movements caused all the controls to jump all over the place, really badly, plane would have crashed, no control authority. Mission planner showed RC inputs jumping around.
Error messages >
‘MSG FS OFF 1000’ is displayed repeatedly on mission planner and shows up loads of times on the messages tab.
Unfortunatly the pixhawk wasn’t armed so I don’t have any other logs.
Scenario that caused the problem >
The fault occurred when nearly all of my controls were stationary, no stick inputs apart from RSSI over PWM which might have changed a bit. The only other thing I was doing was making small adjustment to one aileron to setup differential ailerons when all of a sudden it went crazy.
My setup >
OpenlrsNG Rx was set with interframe PPM set to 3000us as apparently “ardupilot 3.1 and better works ok with 3000”
openLRSNG Rx then outputting SUMD to the pixhawk
OpenLRSNG set to output 12 full range channels
Testing >
Possible cause? >
@Andrew Tridgell could my problem be the same as the only you listed on the link and comment below for arduplane 3.2.1? It’s the only other place I can find with detail on the msg FS off errors.
http://diydrones.com/profiles/blog/show?id=705844%3ABlogPost%3A1899...
“Comment by Andrew Tridgell on February 8, 2015 at 4:59pm
@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”
just want to thank you guys, specialy Andrew.. my plane is now flying perfect!
best
Jose
-
1
-
2
-
3
-
4
-
5
of 7 Next