My apologies for being a bit slack in keeping up with the ArduPlane forum questions lately. If you have a look at my blog post from today you'll see what I've been up to.Now that we've got the AP_HAL code in place, the move to github done and the PX4 port working, I'd like to do a new ArduPlane release soon. It would really help if you could all add any issues that need to be addressed for a new release in the issues list. Please label them as ArduPlane issues, and give enough information for me to try and reproduce it (flight logs, explanations etc). If you had an issue in the old google code list and it is still relevent then please re-enter it in the new list (sorry about that).
There has been a lot of code changes since the last release. Much of that is internal (AP_HAL changes and PX4 support), but there are also new features, for example:
ArduPlane now has a new flight mode called TRAINING mode which I'm really delighted with. I developed it in collaboration with an MAAA flying instructor, and it is meant to be used to teach people to fly RC models. The way it works is that if your roll/pitch is less the the limits you configure then you have complete manual control. If your roll goes past the limit then the APM prevents you going past the limit - much like the way training wheels on a bike prevent the bike from falling over if you lean too far, but when you are riding well the training wheel doesn't touch the ground and you are riding a normal bike. The same goes for pitch. Training mode is fantastic for learning to fly manually. I still need to write the docs for training mode (unless someone else volunteers to do that!), but I've flown it a lot and it works wonderfully.
Another new feature is one that has been requested many times, which is that you can mount your APM any way up in your plane. So if it fits better to have it mounted upside down or sideways then you can now do that by setting the AHRS_ORIENTATION parameter. I went for a flight today with my PX4 mounted upside down and it worked really well.
PLEASE ADD VTAIL MIXING FOR camera gimbal
I'm interested in camera trigger too. :)
Failsafe condition = Loiter rather than Circle please so that height is maintained.
I also have a failsafe issue and it would be great if it could be solved in the next version of Arduplane. When I get into a failsafe situation, my rx not only sends low pulse values from its RC3 channel, but actually all channels, including the mode-switch, get into their R/C failsafe position, and stay at that position untill radio link is back on. I now use the auto mode when I get into a R/C failsafe situation, but would be great if we would have some more flexibility. One part of the solution is to have the APM failsafe mode override the control modes. A similar issue was raised and recently solved for arducopter:
I'm interesting in tigger camera by event. Thanks for your work.
I like this idea! Very nice.
It should be fairly simple to add to APM. Just change RC_Channels_aux.cpp to add gimbal_mix1 and gimbal_mix2 targets, which will be based on how _roll_idx and _tilt_idx are handled now.
I'll add it as a enhancement request. It won't be in this release, but should get into a future release.