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:

  • new flight mode 'TRAINING'
  • support for PX4 autopilot
  • CIRCLE mode now holds altitude
  • support for counter-clockwise loiter (thanks to Jochen)
  • support for the 1.9 firmware on MTK GPS
  • support for mounting the APM board in lots of different orientations
  • improved the MPU6000 accel/gyro filtering a bit more
  • secondary elevator support (thanks to Michael Warren)

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!

Happy flying!

Views: 14845

Reply to This

Replies to This Discussion

Great stuff, I'll try test this week, thank you for this version.

Tridge, you may well have seen this but if not here's the link: http://diydrones.com/group/apmusergroup/forum/topics/improvements-t...

You are a great Tridge !

This week I'll try the new features.

Fausto

WOW nice!!! thanks

hmm but I saw it is not anymore compatible with arduino 1.0.1 so we have to use 1.0.3.

How can we setup it for Visual Studio???

Hi Andy,

I haven't tried building with visual studio, sorry. Can you build with Arduino 1.0.3?

I don't do builds with Windows myself, so I'm not familiar with the VS build.

Cheers, Tridge

yes Arduino 1.0.3 does work. The 2.68 did only work on 1.0.1 and Visual studio.

 

In the 1.0.3 I had to choose from the ArduPilot menu the right APM board. I can't do this in Visual Studio so is there a possibility to bypass this?

 

Andy

The 2.69 release is based on the new AP_HAL, which has different build requirements which are incompatible with the ordinary Arduino IDE - you need to use the special ArduPilot-Arduino 1.0.3, not the vanilla Arduino 1.0.3. Its not surprising that the changes to the build break compatibility with however Visual Studio was building Arduino sketches, but I know nothing about Visual Studio so don't know how you'd go about fixing this.

Hi,

Can you pse post a download or source control link for that? I can't find it.

Regards

Soren

sorry for disturbing once again. I got the APM2.0 and when I stat the APM up I get following error:

Failed to boot MPU6000 5 times
PANIC: failed to boot MPU6000 5 times

Andy

Hi Andy,

Failed to boot MPU6000 5 times
PANIC: failed to boot MPU6000 5 times

That's very strange. The 2.69 release includes some extra paranoia checks that check that the MPU6000 is properly initializing, and it tries resetting the MPU6000 up to 5 times until it responds correctly. Is there anything unusual about your board? For example, do you have any modifications to it? Is it from the 3DR store?

Are you using the firmware from MP or are you building the firmware yourself?

Cheers, Tridge

I use the regular APM board from 3DR. This happens with the MP firmware or my self built one and there are no modification to the board.. And with the 2.68 the MPU6000 does work...

Andy

Hi Andy,

I use the regular APM board from 3DR. This happens with the MP firmware or my self built one and there are no modification to the board.. And with the 2.68 the MPU6000 does work...

Interesting! That may mean we have a SPI initialisation problem with the AP_HAL_AVR code.

During the development of the AP_HAL we found a similar problem and tracked it down to the initialisation order in the SPI code. We changed the order to match the order in the old code (the code used in 2.68) and the problem went away. So we thought the problem was solved.

Now I wonder if there is something more subtle going on. There are a number of techniques we can use to track this down.

First off, can you check if the problem is entirely consistent. The problem we had during AP_HAL development was intermittent. For example, it happened most times when the APM board was first powered on, but if you then power cycle it quickly or use the reset switch then it would boot normally. Can you try a lot of boots in a row (say 20 or more), using both a power cycle and the reset button and see if it always fails in the same way, or if it sometimes boots correctly?

After that, I'd like you to test a modified version of the code, with some extra debugging enabled. In libraries/AP_InertialSensor/AP_InertialSensor_MPU6000.h you'll find a line like this:

#define MPU6000_DEBUG 0

change the 0 to a 1, and also add this in hardware_init() inside the loop where it is trying 5 times to try initialising the board:   _dump_registers();(I can send you new files, or a hex file if you'd prefer).What I'm trying to do is see what the MPU6000 registers look like when it fails to initialise. That may give us some clues as to what is going on. My guess is that we'll see the registers showing it is stuck in a sleep state.Thanks for your patience!Cheers, Tridge

RSS

© 2014   Created by Chris Anderson.

Badges  |  Report an Issue  |  Terms of Service