APM:Plane 3.2.0 released

Archive
1

The ardupilot development team is proud to announce the release of
version 3.2.0 of APM:Plane. This is a major release with a lot of
new features.

The changes span a lot of different areas of the code, but arguably
the most important changes are:

[ul][li]automatic stall prevention code[/li]
[li]PX4IO based RC override code on FMU failure[/li]
[li]I2C crash bugfix[/li]
[li]new autoland code from Michael Day[/li]
[li]compass independent auto takeoff[/li][/ul]

I’ll go into each of these changes in a bit more detail.

[color=#0000FF]Automatic Stall Prevention[/color]

The automatic stall prevention code is code that uses the aerodynamic load factor (calculated from demanded bank angle) to adjust both the maximum roll angle and the minimum airspeed. You can enable/disable this code with the STALL_PREVENTION parameter which defaults to enabled.

When in stabilised manual throttle modes this option has the effect of limiting how much bank angle you can demand when close to the configured minimum airspeed (from ARSPD_FBW_MIN). That means when in FBWA mode if you try to turn hard while close to ARSPD_FBW_MIN it will limit the bank angle to an amount that will keep the speed above ARSPD_FBW_MIN times the aerodynamic load factor. It will always allow you at bank at least 25 degrees however, to ensure you keep some maneuverability if the airspeed estimate is incorrect.

When in auto-throttle modes (such as AUTO, RTL, CRUISE etc) it will additionally raise the minimum airspeed in proportion to the aerodynamic load factor. That means if a mission demands a sharp turn
at low speed then initially the turn will be less sharp, and the TECS controller will add power to bring the airspeed up to a level that can handle the demanded turn. After the turn is complete the minimum airspeed will drop back to the normal level.

This change won’t completely eliminate stalls of course, but it should make them less likely if you properly configure ARSPD_FBW_MIN for your aircraft.

[color=#0000FF]PX4IO based RC override code[/color]

This releases adds support for PX4IO based RC override. This is a safety feature where the stm32 IO co-processor on the PX4 and Pixhawk will give the pilot manual control if the main ArduPilot micro-controller fails (or the autopilot code crashes). This is particularly useful when testing new code that may not be stable.

As part of this new RC override support we also have a new OVERRIDE_CHAN parameter, which allows you to specify a RC input channel which can be used to test the RC override support. See the documentation on OVERRIDE_CHAN for details.

[color=#0000FF]I2C bugfix[/color]

This release fixes another I2C bug in NuttX which could cause the Pixhawk to lock up under high I2C load with noise on I2C cables. This bug has caused at least two aircraft to crash, so it is an important fix. I hope this will be the last I2C crash bug we find in NuttX! An audit of the code was done to try to confirm that no more bugs of this type are present.

[color=#0000FF]New Autoland code[/color]

This release incorporates some new autoland capabilities contributed by Michael Day. The key new feature is the ability to trigger an automatic landing when a RTL completes, which for the first time allows a user to setup their aircraft to land using only transmitter control.

The way it works is there is a new parameter RTL_AUTOLAND. If that is set to 1 and the aircraft reaches its target location in an RTL it will look for DO_LAND_START mission item in the mission. If that is found then the aircraft will switch to AUTO starting at that section of the mission. The user sets up their land mission commands starting with a DO_LAND_START mission item.

There is more to do in this autoland support. We have been discussing more advanced go-around capabilities and also better path planning for landing. The code in this release is an important first step though, and will be a good basis for future work.

[color=#0000FF]Compass independent takeoff code[/color]

The auto-takeoff code has been changed to make it more independent of compass settings, allowing for reliable takeoff down a runway with poor compass offsets. The new takeoff code uses the gyroscope as the
primary heading control for the first part of the takeoff, until the aircraft gains enough speed for a GPS heading to be reliable.

Many thanks to all the contributors, especially:

[ul][li]Paul and Jon for EKF and TECS updates[/li]
[li]Bret and Grant for stall prevention testing[/li]
[li]Michael for all his autoland work[/li]
[li]all the work on NavIO, PXF and Zynq by John, Victor, George and Siddarth[/li]
[li]The PX4 team for all the PX4 updates[/li]
[li]Flaperon updates from Kirill[/li][/ul]

More complete list of changes:

[ul][li]allow GCS to enable/disable PX4 safety switch[/li]
[li]make auto-takeoff independent of compass errors[/li]
[li]report gyro unhealthy if calibration failed[/li]
[li]added support for MAV_CMD_DO_LAND_START[/li]
[li]added RTL_AUTOLAND parameter[/li]
[li]disable CLI by default in build[/li]
[li]new InertialSensor implementation[/li]
[li]added landing go around support[/li]
[li]enable PX4 failsafe RC override[/li]
[li]added OVERRIDE_CHAN parameter[/li]
[li]changed default AUTOTUNE level to 6[/li]
[li]changed default I value for roll/pitch controllers[/li]
[li]added CAMERA_FEEDBACK mavlink messages[/li]
[li]use airspeed temperature for baro calibration if possible[/li]
[li]added STALL_PREVENTION parameter [/li]
[li]fixed handling of TKOFF_THR_MAX parameter[/li]
[li]added ARSPD_SKIP_CAL parameter[/li]
[li]fixed flaperon trim handling (WARNING: may need to retrim flaperons)[/li]
[li]EKF robustness improvements, especially for MAG handling[/li]
[li]lots of HAL_Linux updates[/li]
[li]support wider range of I2C Lidars[/li]
[li]fixed fallback to DCM in AHRS[/li]
[li]fixed I2C crash bug in NuttX[/li]
[li]TECS prevent throttle undershoot after a climb[/li]
[li]AP_Mount: added lead filter to improve servo gimbals[/li]
[li]Zynq and NavIO updates[/li]
[li]fixed preflight calibration to prevent losing 3D accel cal[/li]
[li]perform a gyro calibration when doing 3D accel cal[/li]
[li]added DO_CONTINUE_AND_CHANGE_ALT mission command[/li]
[li]added support for DO_FENCE_ENABLE mission command[/li]
[li]allow gyro calibration to take up to 30 seconds[/li]
[li]improved health checks in the EKF for DCM fallback[/li][/ul]

[color=#FF0000]Note:[/color] If you use flaperons you may need to re-trim them before you
fly due to the change in flaperon trim handling.

I hope that everyone enjoys flying this new APM:Plane release as much as we enjoyed producing it! It is a major milestone in the development of the fixed wing code for APM, and I think puts us in a great position for future development.

Happy flying!

2

Thank you guys! :slight_smile:

3

Keep up the good work! Thanks guys!

4

PLEASE HELP,

I am not getting the DO_LAND_START command in the flight planner. No matter how much I try to update the Mission Planner.

Help I would like to test this today.

Kind regards

Andreas

5

A very minor thing (and not specific to 3.2 as it’s been present in 3.1.x):

During an Auto mission, if one goes into guided mode (Fly-to-here) and then resumes Auto the aircraft no longer tracks to the next waypoint, it invariably drifts off course slightly, tracking then carries on again when the next waypoint is reached. Also in RTL it doesn’t track the course.

Not a major problem in most situations.

Thank you all for an amazing firmware, what can be achieved with this is amazing!

6

Question regarding dual compass behavior: which compass ends up where? If I am using a Pixhawk with a 3DR GPS/Compass, which is which in the logs? How about with two 3DR modules - I assume they take precedence over the internal compass?

Is there any way to see which compass is being used?

Thanks!

7

[quote=“dmurray14”]Question regarding dual compass behavior: which compass ends up where? If I am using a Pixhawk with a 3DR GPS/Compass, which is which in the logs? How about with two 3DR modules - I assume they take precedence over the internal compass?

Is there any way to see which compass is being used?

Thanks![/quote]
For Plane, the external will become the primary compass and the internal becomes the backup. You cannot have more than one external compass on I2C as of now. Both compasses are logged. I don’t know if you can tell if the Pixhawk is ignoring the Primary compass and has downgraded to the internal.

8

Hi,

I was doing yesterday my first maiden flight with the new version of the 3.2 Pixhawk and I had something very strange after the 9 minutes, I have almost lost my plane but I was able to landed. Here is my story, maybe someone can help me:

Before we flew we did the spectrum scan with the dragonlink new microRx while the telemetry was ON and the vTX 800mw is ON and the camera too, and everything was fine. (But we flew without the vTX nor the Camera)

After few good loiters in manual and stabilize modes, we tried the RTL and it was ok, then we decided to change the RTL mode from the mission planner to be the Cruise Mode on the taranis switch, we did the change in the mission planner and send it via the telemetry while it was flying on stabilize mode and we switched to cruise and it was perfect in the air.

Then we changed to RTL mode from the cruise mode to try it again while we were in the stabilize mode, after that, we clicked the RTL switch on the Taranis and it started to do a slight left bank, (we found that the compass was giving the bad health message) so we changed to manual mode but the plane started to fly in crazy loops and the response of the servos were very slow or locked and it was a miracle to have it landed after few minutes of crazy flights.

We checked everything on the ground and there was no single problem, we checked if any of the items is over heat, but also, no problem at all. We did a ground test trying all the servos with high speed throttle also and there was no problem neither any delay. I have even tried the micro-power on the dragon at 100 meters and there was no problem.

After that, we decided to do a second flight, and just after few seconds of the airborne, the plane started to do loops and fly like crazy and we were only in the manual mode.

Do you think there is a problem with the Pixhawk, Compass, Airspeed sensor?
but how can they make a problem if we were in the manual mode? do you think the changes we did remotely for the same switch between RTL and Cruise, caused that problem even for the manual modes?

We were using the RFD900 0.5W Telemetry and it was away 30cm from the CC BEC Pro of the servos and 40cm from the dragonlink Rx and 20cm from the Compass, Do you think the High powered Telemetry did it but why it didn’t do it at the first 10 minutes? why only after we did the change between the RTL and Cruise? is it a coincidence?

The APM power module is 3 cm under the compass, do you think this is an issue, but also in the manual mode, the compass doesn’t have any effect, am i correct?

here is the video of the second flight: youtube.com/watch?v=1EyTZuJjXMI

and here is the setup photo inside the Talon:

9

@john2014, logs are much more useful than videos. Do you have the .bin log off the microSD card? Do you have the telemetry log?

10

Hi Tridge,

I have PM you the links of the files few minutes ago, if you didn’t receive them, I will resend them.

11

@tridge

here is the folder where I put the BIN, I didn’t know which files I have to upload, so I have uploaded all the 9 files, but I guess it is 280.bin

drive.google.com/folderview?id= … sp=sharing

12

Hi john, did you set up your CG apropriatelly?, in the video seems like you have to aft Center of Gravity, so the plane seems quite uncontrolable, probably increasing the loss of control with the autopilot gyro, trying to over correct. Any way, the log file is the best way to discover the problem

Enviado desde mi iPad con Tapatalk

13

HI Piruja

In the second video, it looks like it was a CG issue but it was not, we have even checked after the flight and the CG was correct.

In the first flight, it flew for 10 minutes without a problem and after we switched modes over the telemetry we go this issue, maybe it is coincidence.

We are checking also if ESC can affect (EMI) the digital servos, we have the Castle Edge 100A and also we are checking if the high powered Telemetry RFD900 0.5W can affect also the Servos.

In the manual mode, the Pixhawk will not interfere I guess so, it was not correcting itself.

I have posted the BIN files and we are trying to figure out what is the problem.

Thanks for your help

14

ALT_MIX The percent of mixing between GPS altitude and baro altitude. 0 = 100% gps, 1 = 100% baro. It is highly recommend that you not change this from the default of 1, as GPS altitude is notoriously unreliable. The only time I would recommend changing this is if you have a high altitude enabled GPS, and you are dropping a plane from a high altitude baloon many kilometers off the ground.

ALT_MIX Parameters of the failure?I am trying to RTK mode control.

15

@ Piruja

Where you able to find anything from the BIN files?

16

Hi John,
As I mentioned in the other discussion, I have looked at this log, but haven’t found anything yet.
Here is a graph of your 2nd manual flight with the VTAIL mixing decoded:
uav.tridgell.net/ManualFailure/john_manual.png
what that shows is the actual servo output for the VTAIL compared with the correct output as computed by a mixing function on the 2nd and 4th RC input channels. As you can see, they match, which means as far as this log is concerned it was correctly passing through pilot input to servo output for this vtail in manual mode.
The SERVO_OUTPUT_RAW message comes directly from the PX4IO output controller. It reports what is being actually sent to the servo, not what we’ve asked to send, so it should always be an accurate picture of the behavior of the servo.
As with Martins log this leaves me a bit stumped. I’m starting to wonder if perhaps there is a timing effect going on in px4io that is affected either by noise or voltage? It doesn’t make much sense though, as the logs show your servo voltage only varies by 0.2V over the entire flight.
Have you done any more ground tests? Have you found a way to reproduce it without flying?
Cheers, Tridge

17

HI Tridge,

Thanks for your help. We are very surprised that it happened in manual mode when it was supposed to be 100% controllable by us.

After we have miraculously landed, we did multiple ground tests, as micro power from the Tx, full throttle, and putting extra loads on the servo and there was no error at all. We have even checked the CG and it was 100% correct.

We decided to go for another flight and after few second of taking off, it did the same, it was acting like heavy tail despite the CG was 100% correct and it was on manual mode. We have landed between the trees and we have checked the CG and it was 100% correct.

here again the video of the second flight: youtube.com/watch?v=1EyTZuJjXMI

I don’t know, it is like magic. we feel we have to downgrade the pixhawk to the previous version to have it was before.

The only think we didn’t try on the ground test was the Airspeed sensor, we will put extra wind on it to see it will affect anything, but will do anything in the manual mode?? It should not. Am i correct?

18

[quote=“John2014”]I don’t know, it is like magic. we feel we have to downgrade the pixhawk to the previous version to have it was before.
[/quote]
If you find a previous version does fix it then I think we may need to do a version bisection search to find where it went wrong. I could create a set of versions evenly spaced between the previous stable release and the current one, then you could try the one half-way and see if the issue occurs. The result of that would tell you if you need to try an earlier or later build. If I created 100 versions then it would take 7 flights to narrow it down to one of those 100 changes.
That would still take a long time, but may be the only way. Do you have enough time to try something like that?

It shouldn’t make any difference at all, but the issue you describe doesn’t make any sense either! So we have to not assume that normal assumptions hold.
Cheers, Tridge

19

Hi again John,
I’ve noticed that RC input channel 7 changes a fair bit in your manual flight, but isn’t assigned to anything in the config. Can you tell me what channel 7 is assigned to on your transmitter?
Cheers, Tridge

20

Hi Tridge,

There is nothing connected on the Ch7. We are using the Taranis Radio and it is assigned on the potentiometer S2 frsky-rc.com/product/pro.php?pro_id=137

I was thinking of something if we can find it inside the logs, let’s assume there was a weight shifting inside the plane for unknown reason, despite we were flying stable, and we were in the RTL mode. Can you check if the Pixhawk has felt something 1/10 of the second just before it starts to move/lock the servos . We were at the RTL mode then stabilize then manual.

[quote=“tridge”][quote=“John2014”]I don’t know, it is like magic. we feel we have to downgrade the pixhawk to the previous version to have it was before.
[/quote]
If you find a previous version does fix it then I think we may need to do a version bisection search to find where it went wrong. I could create a set of versions evenly spaced between the previous stable release and the current one, then you could try the one half-way and see if the issue occurs. The result of that would tell you if you need to try an earlier or later build. If I created 100 versions then it would take 7 flights to narrow it down to one of those 100 changes.
That would still take a long time, but may be the only way. Do you have enough time to try something like that?

Well, we do have time as we don’t have any other option.

It shouldn’t make any difference at all, but the issue you describe doesn’t make any sense either! So we have to not assume that normal assumptions hold.
Cheers, Tridge[/quote]

We will run an airspeed test tomorrow on the ground when it is on the manual mode.