I've just released ArduPlane 2.69 [UPDATE: revised to version 2.70 after bug fix (see comments). This release includes a lot of internal changes, principally the AP_HAL changes, which is why it took so long. I've also been doing a lot of test flights to try to ensure that all these large changes haven't broken anything.
As has been discussed previously, the biggest change in this release is the move to the new AP_HAL hardware abstraction layer. This was a large internal change, that by itself didn't change the behaviour of ArduPlane, but did allow us to make ArduPlane much more portable. As a result, this is the first release of ArduPlane that works on the new PX4 autopilot board. Unfortunately the documentation on how to setup ArduPlane on PX4 is still lacking, so if you have a PX4 and want to run the 2.69 release then you will either have to dive into things a bit yourself to get it to work or wait a bit longer for the documentation updates. Sorry about that!
Of course we still support the APM1 and APM2 and I plan on keeping ArduPlane working on both those boards as long as possible. What I expect to happen is that some new features in future releases will only be enabled on the PX4, but for now ArduPlane on the PX4 works just the same as it does on the APM1 and APM2.
As you might expect from the fact that it has been over 2 months since the last ArduPlane release, there have also been quite a few changes not related to the AP_HAL and PX4 work. Many thanks to everyone who has contributed patches and ideas that made it into this release! I know not every requested feature made it in, but I thought it was better to get the new release out now.
Some of the key changes in this release are:
One of the changes I am most pleased with is the addition of a new flight mode called TRAINING mode. This mode was developed in cooperation with a MAAA flight instructor, and is designed to help people to learn R/C manual flying. When you are in TRAINING mode you have manual control over roll until you reach the LIM_ROLL_CD roll limit, at which point the plane won't roll over any more. The same applies to pitch - you have manual pitch control until you reach LIM_PITCH_MIN or LIM_PITCH_MAX, at which point the plane won't pitch beyond those limits. This means that as long as you stay within the configured limits you are flying the plane manually, and you can quickly learn to fly an R/C plane manually, knowing that the APM will prevent the plane from going upside down. I'll do a separate blog post about how we are using TRAINING mode to teach new pilots good R/C manual piloting skills.
Another significant change in mode behaviour is that CIRCLE mode now holds altitude. This is important because CIRCLE is used in the first stage of failsafe conditions, and if your plane is badly trimmed it could lose quite a lot of altitude before the RTL stage of failsafe kicks in. Note that this doesn't mean that CIRCLE is now the same as LOITER - in a LOITER the plane will adjust its roll to keep going around the target position, whereas in CIRCLE the position of the plane isn't considered - it just holds a small roll angle, which results in a large circle that drifts with the wind. This is deliberate as we want CIRCLE to not be dependent on the GPS, and to involve no sharp turns.
The other change that is probably worth expanding on is the ability to mount the APM in many possible orientations. This has been an open request for a long time as for certain types of airframes it is very useful. Just set the AHRS_ORIENTATION parameter to one of the supported orientations and your APM will quite happily work upside down or sideways.
I'm expecting it won't be 2 months till the next release, as I have a bunch of other changes pending that I held off for this release (for example, the AP_Mission code from Brandon, and the new AP_Scheduler code), but meanwhile I'm very happy with how this release is flying, and I hope you all will be too!
I figured that from the system.pde file. Another question, when I build it on px4, which uart port of px4 would it point to ? (uart1, 2 , 5, 6 ?)
Have a look at libraries/AP_HAL_PX4/scripts/rc.APM. You'll see it uses /dev/ttyS1 by default.
I will soon change that though, as the USB port now supports dual streams, so I'm planning on changing it so MAVLink starts on both ttyS1 and the ttyACM0 USB port.
Hi Mike and Wim,
Have either if you posted logs of running the CLI tests so we can try to work out what is going wrong? I've chased down a few reports like this since 2.69 came out and so far they have turned out to be either hardware faults (so 2.68 didn't actually work, despite initial reports) or user error (eg. loading the HIL version of the code).
I would like to chase all of these reports down, but please make sure you give enough information for me to have a chance to help you. We've tested a lot of APM2.0 and APM2.5 with the 2.69 release and we have yet to find one that fails. That doesn't mean there isn't a bug, but it does mean it must be fairly rare (or the around 50 boards we tested happened to be lucky ones!). That means we really need your help in narrowing this down.
Please see my comment to Mike and Wim. I need a bit more information to try and track these reports down.
Havent got a reply from you? Could you share how you set up your Aurora 9 to work with the failsafe?
If you could post a tlog from mission planner showing the failed startup, plus logs from testing the sensors in the CLI that would be appreciated.
I know that several people have reported a problem. For all of the people who have since posted logs (either privately or publicly) the problem has been resolved. For those who haven't posted any logs I really can't do anything to help. You are welcome to try and debug it yourself, but if you want assistance, then I need logs.
I did flight testing of the 2.69 release using a SkyFun, a HotDog an X8 and an ugly stick.
It was also tested on 30 APM 2.5 boards and 26 APM 2.0 boards by engineers at 3drobotics.
Cool, flew 2.69 on my x8 Friday. Worked well. Are you running default PIDs on Your x8?
I've tweaked things a bit. Note that you shouldn't really expect the right PIDs for one X8 to be the same as for another. It depends on the motor, payload weight, prop, what servo horn hole you use, what servos you use etc etc.
I've been meaning to put together a more comprehensive tuning guide to help people get the right parameters. Even better if we could get an auto-tuning system to work!
I don't have an Aurora 9, the test I referred to before was to check that ArduPlane reacted correctly when I changed all channels to a low value on failsafe.
If your radio can't put out failsafe values low enough, then perhaps you should instead setup your radio to output a known set of valid values during on loss of R/C signal? For example, set it to output the switch position for RTL, with neutral stick positions.