APM:Plane 3.4.0 released

The ArduPilot development team is proud to announce the release of
version 3.4.0 of APM:Plane. This is a major release with a lot of
changes so please read the notes carefully!

[color=#0000FF]First release with EKF by default[/color]

This is the also the first release that enables the EKF (Extended Kalman Filter) for attitude and position estimation by default. This has been in development for a long time, and significantly improves flight performance. You can still disable the EKF if you want to using the AHRS_EKF_USE parameter, but it is strongly recommended that you use the EKF. Note that if an issue is discovered with the EKF in flight it will automatically be disabled and the older DCM system will be used instead. That should be very rare.

In order to use the EKF we need to be a bit more careful about the setup of the aircraft. That is why in the last release we enabled arming and pre-arm checks by default. Please don’t disable the arming checks, they are there for very good reasons.

[color=#0000FF]Last release with APM1/APM2 support[/color]

This will be the last major release that supports the old APM1/APM2 AVR based boards. We have finally run out of flash space and memory. In the last few releases we spent quite a bit of time trying to squeeze more and more into the small flash space of the APM1/APM2, but it had to end someday if ArduPilot is to continue to develop. I am open to the idea of someone else volunteering to keep doing development of APM1/APM2 so if you have the skills and inclination do please get in touch. Otherwise I will only do small point release changes for major bugs.

Even to get this release onto the APM1/APM2 we had to make sacrifices in terms of functionality. The APM1/APM2 release is missing quite a few features that are on the Pixhawk and other boards. For example:

[li]no rangefinder support for landing[/li]
[li]no terrain following[/li]
[li]no EKF support[/li]
[li]no camera control[/li]
[li]no CLI support[/li]
[li]no advanced failsafe support[/li]
[li]no HIL support (sorry!)[/li]
[li]support for far fewer GPS types[/li][/ul]

that is just the most obvious major features that are missing on APM1/APM2. There are also numerous other smaller things where we need to take shortcuts on the APM1/APM2. Some of these features were
available on older APM1/APM2 releases but needed to be removed to allow us to squeeze the new release onto the board. So if you are happy with a previous release on your APM2 and want a feature that is in that older release and not in this one then perhaps you shouldn’t upgrade.

[color=#0000FF]PID Tuning[/color]

While most people are happy with autotune to tune the PIDs for their planes, it is nice also to be able to do fine tuning by hand. This release includes new dataflash and mavlink messages to help with that
tuning. You can now see the individual contributions of the P, I and D components of each PID in the logs, allowing you to get a much better picture of the performance.

A simple application of this new tuning is you can easily see if your trim is off. If the Pitch I term is constantly contributing a signifcant positive factor then you know that ArduPilot is having to
constantly apply up elevator, which means your plane is nose heavy. The same goes for roll, and can also be used to help tune your ground steering.

[color=#0000FF]Vibration Logging[/color]

This release includes a lot more options for diagnosing vibration issues. You will notice new VIBRATION messages in MAVLink and VIBE messages in the dataflash logs. Those give you a good idea of your
(unfiltered) vibration levels. For really detailed analysis you can setup your LOG_BITMASK to include raw logging, which gives you every accel and gyro sample on your Pixhawk. You can then do a FFT on the
result and plot the distribution of vibration level with frequency. That is great for finding the cause of vibration issues. Note that you need a very fast microSD card for that to work!

[color=#0000FF]Rudder Disarm[/color]

This is the first release that allows you to disarm using the rudder if you want to. It isn’t enabled by default (due to the slight risk of accidentially disarming while doing aerobatics). You can enable it
with the ARMING_RUDDER parameter by setting it to 2. It will only allow you to disarm if the autopilot thinks you are not flying at the time (thanks to the “is_flying” heuristics from Tom Pittenger).

[color=#0000FF]More Sensors[/color]

This release includes support for a bunch more sensors. It now supports 3 different interfaces for the LightWare range of Lidars (serial, I2C and analog), and also supports the very nice Septentrio RTK
dual-frequency GPS (the first dual-frequency GPS we have support for). It also supports the new “blue label” Lidar from Pulsed Light (both on I2C and PWM).

For the uBlox GPS, we now have a lot more configurability of the driver, with the ability to set the GNSS mode for different constellations. Also in the uBlox driver we support logging of the raw carrier phase and pseudo range data, which allows for post-flight RTK analysis with raw-capable receivers for really accurate photo missions.

[color=#0000FF]Better Linux support[/color]

This release includes a lot of improvements to the Linux based autopilot boards, including the NavIO+, the PXF and ERLE boards and the BBBMini and the new RasPilot board. If you like the idea of flying
with Linux then please try it out!

[color=#0000FF]On-board compass calibrator[/color]

We also have a new on-board compass calibrator, which also adds calibration for soft iron effects, allowing for much more accurate compass calibration. Support for starting the compass calibration in the
various ground stations is still under development, but it looks like this will be a big improvement to compass calibration.

[color=#0000FF]Lots of other changes![/color]

The above list is just a taste of the changes that have gone into this release. Thousands of small changes have gone into this release with dozens of people contributing. Many thanks to everyone who helped!

Other key changes include:

[li]fixed return point on geofence breach[/li]
[li]enable messages for MAVLink gimbal support[/li]
[li]use 64 bit timestamps in dataflash logs[/li]
[li]added realtime PID tuning messages and PID logging[/li]
[li]fixed a failure case for the px4 failsafe mixer[/li]
[li]added DSM binding support on Pixhawk[/li]
[li]added ALTITUDE_WAIT mission command[/li]
[li]added vibration level logging[/li]
[li]ignore low voltage failsafe while disarmed[/li]
[li]added delta velocity and delta angle logging[/li]
[li]fix LOITER_TO_ALT to verify headings towards waypoints within the loiter radius[/li]
[li]allow rudder disarm based on ARMING_RUDDER parameter[/li]
[li]fix default behaviour of flaps[/li]
[li]prevent mode switch changes changing WP tracking[/li]
[li]make TRAINING mode obey stall prevention roll limits[/li]
[li]disable TRIM_RC_AT_START by default[/li]
[li]fixed parameter documentation spelling errors[/li]
[li]send MISSION_ITEM_REACHED messages on waypoint completion[/li]
[li]fixed airspeed handling in SITL simulators[/li]
[li]enable EKF by default on plane[/li]
[li]Improve gyro bias learning rate for plane and rover[/li]
[li]Allow switching primary GPS instance with 1 sat difference[/li]
[li]added NSH over MAVLink support[/li]
[li]added support for mpu9250 on pixhawk and pixhawk2[/li]
[li]Add support for logging ublox RXM-RAWX messages[/li]
[li]lots of updates to improve support for Linux based boards[/li]
[li]added ORGN message in dataflash[/li]
[li]added support for new “blue label” Lidar[/li]
[li]switched to real hdop in uBlox driver[/li]
[li]improved auto-config of uBlox[/li]
[li]raise accel discrepancy arming threshold to 0.75[/li]
[li]improved support for tcp and udp connections on Linux[/li]
[li]switched to delta-velocity and delta-angles in DCM[/li]
[li]improved detection of which accel to use in EKF[/li]
[li]improved auto-detections of flow control on pixhawk UARTs[/li]
[li]Failsafe actions are not executed if already on final approach or land.[/li]
[li]Option to trigger GCS failsafe only in AUTO mode.[/li]
[li]added climb/descend parameter to CONTINUE_AND_CHANGE_ALT[/li]
[li]added HDOP to uavcan GPS driver[/li]
[li]improved sending of autopilot version[/li]
[li]prevent motor startup with bad throttle trim on reboot[/li]
[li]log zero rangefinder distance when unhealthy[/li]
[li]added PRU firmware files for BeagleBoneBlack port[/li]
[li]fix for recent STORM32 gimbal support[/li]
[li]changed sending of STATUSTEXT severity to use correct values[/li]
[li]added new RSSI library with PWM input support[/li]
[li]fixed MAVLink heading report for UAVCAN GPS[/li]
[li]support LightWare I2C rangefinder on Linux[/li]
[li]improved staging of parameters and formats on startup to dataflash[/li]
[li]added new on-board compass calibrator[/li]
[li]improved RCOutput code for NavIO port[/li]
[li]added support for Septentrio GPS receiver[/li]
[li]support DO_MOUNT_CONTROl via command-long interface[/li]
[li]added CAM_RELAY_ON parameter[/li]
[li]moved SKIP_GYRO_CAL functionality to INS_GYR_CAL[/li]
[li]added detection of bad lidar settings for landing[/li][/ul]

Note that the documentation hasn’t yet caught up with all the changes in this release. We are still working on that, but meanwhile if you see a feature that interests you and it isn’t documented yet then please ask.

Hi Tridge,

I’ve been holding out with 3.1 for awhile because 3.3 caused some servo gimbal issues for me, and I finally got it working with 3.1.

I’d love to see some documentation on the gimbal changes, especially if they are visible in the mission planner actions tab.
Looks like a great update overall, I think I’ll update the test rig to 3.4 this weekend. Thanks to you and all the developers for the hard work.

Looking forward to trying this release.

Couple of questions though, when you say the apm has no advanced failsafe support, what does that translate to?

The compass calibrator, probably me just being thick, but what is it? Something similar to compassmot on copter? (compassmot or equivalent would be REALLY nice as I do get quite a bit of throttle based deviation on my compass).

Thanks for the detailed release change! And also for the hard work related to this ultimate version for my APMs.

I see a new feature that is quite cool:

It means we won’t need the RC filter when using some FrSky receivers \o/ Good job!

Now I have a question regarding the missing features in APM: the changelog says:

Can we have a clue one the concerned changes?
I’m not very comfortable with this, as this could mean a lot. It’s just like saying “we have changed some things in the behavior of your plane, but we’re not telling you, you just fly and you’ll figure out by yourselves” :smiley:

Does it auto detect PWM RSSI or if their a new configuration parameter? Where is the documentation?


See plane.ardupilot.com/wiki/advance … iguration/
It was originally added for the Outback Challenge

The compass calibrator, probably me just being thick, but what is it?[/quote]
it is a compass calibrator what works inside the autopilot, instead of in the GCS. It is able to take account of soft iron effects, which can make a big difference on some aircraft.
You can set compsssmot vectors in APM:Plane, but there is no GUI for creating the right values I’m afraid, so you’d need to do it by processing a logfile.

[quote=“RC Mike”]Does it auto detect PWM RSSI or if their a new configuration parameter? Where is the documentation?
Stewart Loving-Gibbard is working on the documentation I believe. He contributed the code.
Meanwhile these auto-docs may help:
plane.ardupilot.com/wiki/ardupla … parameters

Can we have a clue one the concerned changes?
I’m not very comfortable with this, as this could mean a lot. It’s just like saying “we have changed some things in the behavior of your plane, but we’re not telling you, you just fly and you’ll figure out by yourselves” :smiley:[/quote]
It’s an adventure!
But really, the key things are the ones I listed in the release notes. The easiest way to tell something is missing is that the parameters for it don’t appear on the GCS.
You’re right that we should have a table of features by board type though.


added new RSSI library with PWM input support

It means we won’t need the RC filter when using some FrSky receivers \o/ Good job!

Looks like this did not make it to 3.4 on APM 2.6, unfortunately, which is where I get the impression you want to run it. I’m disappointed too - my best test plane has a 2.6 right now.

Hi Tridge,

I Have a Raspilot V1.1 and Zubax CAN GPS, I am looking at modifying the Raspilot to have a CAN onboard.

I will be trying a USB CAN adapter soon, hopefully within 3 weeks.

I would like to develop code.

what work needs to be done on the CAN driver for it to work initially with a USB adapter ?

What driver would work with the Raspilot ?

Is the new features in plane 3.4.0 support the V2 firmware on the Zubax CAN GPS ?

I also would like to get raspilot runing on an odroid XU4


David Skipper

Tridge, for the PID Tuning when you say the I is constantly contributing a high value, what is a high value?

I just looked at my logs from a recent flight and the PIDP’s I is always above 0 and usualy around 2-3 with spikes to 5 when needed.

What is a normal I value and what is a high value?

The number is on a scale of -45 to 45 (it is treated as an angle in degrees). So a value of 5 means the elevator is being pulled up by 1/9 of its full scale, which isn’t very much. It is quite normal to have a small amount of trim like that.
Cheers, Tridge

Excellent info,

Thank you

i have tried to set new parametrs like RSSi_PIN_LOW or ARMING_RUDDER: ArmOrDisarm via APM Planner on my APM 2.6 board but it says these parameters don’t exist (or something similar).
Are those supported on APM?


I just updated to 3.4 and was not able to successfully implement rssi analog. I had this working perfectly before the update.
A note to developers, in case you can help on this. I’ve learned the hard way to download ALL params. BEFORE updating FW and then do a “compare” after the update. I did that this time as well and the rssi params never showed up as changed. I think I know why. If the parameter name never existed, it won’t show up. Imagine my puzzlement this morning when I went to fly and got 0 rssi.

Anyway, does anyone know what I need in params to get analog rssi? I pretty sure I need Pin assignment 103. But there are also radio channels, which I think is for PWM rssi but it’s not clearly stated.

hi Icarus,
Did you set RSSI_TYPE and RSSI_ANA_PIN? It seems to work for me, so if you can confirm its not working then can you provide a tlog?
You are right that the RSSI_* parameters didn’t automatically come forward from past releases, so you do need to reset those. I should have mentioned that in the release notes.
Cheers, Tridge

I got working by exhaustive search for the documentation that is now missing in MP. I didn’t know what to set the values to. MP used to have a short definition of param settings in the far right column but they are now missing. Maybe it’s updated, I haven’t checked in a week.

Also, note my comment on doing compare with old parameter values being useless if those values didn’t exist in the old parameters. Can this be fixed so that anything different is highlight in the compare analysis?
Cheers, Icarus

I apologize as well for the RSSI problems - many were my fault, and will be corrected in Plane 3.4.1.

Current accurate documentation can be found here: plane.ardupilot.com/wiki/ardupla … parameters

Icarus, you’re right Mission Planner was initially missing it’s inline right side documentation on the parameter list pages. The goods news is I just tried Mission Planner again and there is at last documentation of the RSSI parameters, although the latest set of corrections I made post-release has not been incorporated yet. If you are at all confused, use the HTML documentation above.

Tridge, you declined last time we talked about it, but I would still be willing to write some auto-upgrade code for the RSSI parameters to eliminate problems like this. The situation may well be better with the documentation we were lacking, but I still hate to spoil anyone’s flying day if they didn’t read every line of the docs.

Thank you. The part of this documentation on RSSI was what I eventually found. Having that, I was able to insert the correct values.
My main concern was the safety and surprise. I remember on time MP was updated and I started a mission. It was taking a very long time to reach my first WP and with full throttle. It turned out the update had reset MP to meters but not the flight plan. So, my 1,500ft WP was 1,500m :astonished:
Thanks for the help and continuing effort.

The release notes should probably warn that upgrading kills RSSI since the old option name is removed and replaced with another one.
Took me a while to figure that out when I went to the field and was wondering why my RSSI was dead :slight_smile:

Also, a warning that dataflash logs are unusable by most software out there right now