I've just released ArduPlane 2.71 for your flying pleasure.

As was described in the 2.71-beta thread, these are the major changes from 2.70:

  • prevent control mode changes due to receiver input change when in throttle failsafe
  • auto-scale analog input based on board voltage. This also removes the INPUT_VOLTAGE parameter, as it is no longer needed
  • added TKOFF_THR_MINSPD and TKOFF_THR_MINACC parameters. These allow you to set a minimum ground speed or X acceleration before the motor is started in auto mode. This is to better support hand launching in AUTO mode, and bungee or catapult launching.
  • added TKOFF_HEAD_HOLD option. This determines if auto takeoff will try to hold heading while climbing out. For a hand launch it is often better just to hold the wings level, instead of trying to hold heading.
  • changed FBWB altitude control from elevator to lock in the altitude when the elevator stick is neutral. This fixes a problem with altitude changing in FBWB mode due to slight tuning errors. You can set the climb rate for FBWB with the FBWB_CLIMB_RATE parameter. It default to 2 m/s
  • auto-detect when the compass is way off due to interference and switch to GPS navigation until the compass is healthy again. This is designed to prevent flyaways due to very bad magnetic interference.
  • prevent servo output overflow on large PID gains. This is especially important for elevon aircraft
  • changed default STICK_MIXING behaviour to use FBWA style stick mixing in AUTO mode. This prevents the pilot from causing radical turns if they don't know that the plane is in an AUTO mode. You can get the old behaviour by changing the STICK_MIXING parameter to 2.
  • Added a software VTail mixer, enabled using the VTAIL_OUTPUT option.
  • Fixed loading of missions with DIGICAM control commands, so DIGICAM control works again
  • Don't trigger a GCS failsafe if the GCS has never connected
  • Fixed fence MAVLink target IDs (fixes a problem with AndroPilot)
  • Added HIL_SERVOS parameter to allow real servos to move in HIL mode
  • Fixed an off-by-one in PX4 channel output (last PWM output channel wasn't sent)
  • Fixed scaling of joystick speed when controlling a camera gimbal with a joystick
  • Fixed creation of APM directory on SDCard on PX4
  • fixed auto-config of uBlox baudrate for uBlox modules set to 9600 baud
  • Fixed PX4 startup in FMU only mode
  • Added APM/boot.log on SDCard on PX4

Many thanks to everyone who contributed to this release!

One thing that isn't in this release but will be in the next release is the new L1 navigation controller from Brandon and Paul. They are doing fantastic work and testing is good so far, but I wanted to get the new features above out first before adding the new navigation code. I hope we will release a 2.72 release with the new L1 controller in the next couple of weeks.

Happy flying!

Cheers, Tridge

Views: 11731

Reply to This

Replies to This Discussion

will DO Commands for the mount be implemented soon? They are non functioning for arduplane... or was it fixed in this release?

FYI, on an unrelated note. I am now experirncing an error screen (asking if I want to report) when trying to setup a grid using grid v2. Grid works fine, but the v2 does not, and causes an error. This error did not happen before the update.



So great! I am reading your codes recently.I am absorbed by the codes.

May I ask a question?

When I analyze the function stabilize(),I am confused by the control loops.For example,I draw the control loop for the function stabilize_roll():

especially for get_servo_out():

g.channel_pitch.servo_out = g.pitchController.get_servo_out(nav_pitch_cd, speed_scaler, control_mode == STABILIZE);

AP_RollController::get_servo_out(int32_t angle, float scaler, bool stabilize):
















In the control loop there are :kp_angle,_stabilized_gain,kp_ff,kp_rate,I want to know when and where do the parameters assigned the value?


The value of kp_angle,_stabilized_gain,kp_ff,kp_rate are from GCS?And which one is kp_angle or kp_ff?

I did not find the _integrator and differential used  in the control loop.


Cheers for the release info, I noticed that the logging issue hasn't been fixed from 2.70, can see there are 8 logs on the apm but unable to download,
More details here



Hi Zheng,

I think the confusion probably arises from the optional APM_CONTROL code in ArduPlane. Jon Challinger added a new set of roll/pitch controllers in libraries/APM_Control. These are not used by default, but if they are enabled they use the additional parameters you are asking about.

You should also know that these control loops are undergoing some big changes at the moment. Brandon Jones, Paul Riseborough and myself have been adding in support for a L1 controller for navigation. That is currently in master and will be in the next release. Paul has now started working on a new pitch controller which will change a lot of what you are looking at.

Cheers, Tridge

Hi Tridge,
   Thank you so much.It is so fantastic in the open project.I hope I can do something for the project one day.
   You mean that the controllers in libraries/APM_Control are not used.So there is another question:The function stabilize() calls the stabilize_roll(),and then calls the get_servo_out(),Where is the difination of the funciton get_servo_out?It is in the libraries/APM_Control,isn't it?
    I opened the pde-type files in the ArduPilot Arduino IDE,but I can't find the connections between the pde-type files and the files in the library folder.How do they be used and included?





Hi Zheng,

The get_servo_out() function is only called if APM_CONTROL != DISABLED, like this:

// Calculate dersired servo output for the roll
// ---------------------------------------------
g.channel_roll.servo_out = g.pidServoRoll.get_pid_4500((nav_roll_cd - ahrs.roll_sensor), speed_scaler);
// calculate roll and pitch control using new APM_Control library
g.channel_roll.servo_out = g.rollController.get_servo_out(nav_roll_cd, speed_scaler, control_mode == STABILIZE);

otherwise it calls get_pid_4500() using the pidServoRoll PID object.

In general to find the function you need to know the object type it is being called on, the find the definition of that class in libraries. In this case you'll see in Parameters.h that pidServoRoll if of type PID. You can also see a #include <PID.h> in ArduPlane.pde. That pulls in the definition of the PID class from libraries/PID/PID.h. So look in libraries/PID/ for how the function works.

Have fun exploring APM!

Cheers, Tridge

Tested v2.71 on Saturday flying 2 waypoints with a DO_JUMP command (so just repeat the mission). I changed one waypoint half way during the mission moving it to 200m from home and raising it from 50m to 80m AGL.

The mission can be viewed on Droneshare (http://www.droneshare.com/view/bjqo6as)

Nothing untoward to report although someone with more knowledge can analyse the logs better than I can.

The only thing that I didn't like was me forgetting to reset Home Altitude to zero before launch. Wouldn't it be more appropriate if the altitude displayed on the MP could be automatically set to AGL rather than ASL? It's more important and relevant for me to know how high I'm flying above the ground rather than above the sea which is 600km away :)

Hi Djalma,

Sorry again for the slow reply. I'll try to make up for it with a thorough analysis! (if you just want the short answer, it is that you need to set AHRS_BARO_USE to 0).

First off, let's look at the roll the APM was reporting for the first of your logs above:

The part on the right shows a distinct negative roll. If this was correct you'd expect the aircraft to be turning left. Let's add the GPS course on the right axes to compare, looking just at the parts on the right of the graph:

There are some parts of the log there that should a fairly constant course, but a large negative roll. That is probably the effect you saw. OK, so what caused it?

Next let's look at a different way to estimate roll, directly from the accelerometers. APM normally integrates the gyroscope readings and drift corrects those with a combination of the accelerometers and the GPS velocity numbers. We can use a different algorithm which assumes no side-slip and calculates centripetal correction using the cross product of the velocity vector with the gyroscopes to get an alternative roll estimate. Let's first look at that for the early part of the flight when everything was working well:

you can see the two roll estimates agree pretty well for this part of the flight. Now lets look at the same thing for where it went wrong:

that doesn't look so good! The APM roll estimate is disagreeing with the alternative estimate by a large amount. To see why this happened we need to look at what goes into the APM estimate, and see what could have caused it to go wrong in your plane.

The inputs are:

  • gyroscope
  • accelerometers
  • GPS velocities
  • barometric climb rate if AHRS_BARO_USE is set to 1

The gyro and accels are also used by the alternative estimate, so that probably isn't it. The key then is the GPS velocities and the baro climb rate.

The APM only uses the baro climb rate if you have AHRS_BARO_USE set to 1. The default is zero, but checking through your log I see yours was set to 1, possibly as a result of loading an old config (the default was 1 for a release a while ago, before we noticed this sort of roll problem happening).

The reason we initially added support for baro climb rate in DCM is that the old MTK GPS doesn't report a vertical velocity, so we can't use the GPS for vertical velocity correction of the Z acceleration. So we used a derivative filter on the baro instead, if AHRS_BARO_USE is 1.

You seem to have a uBlox GPS, so that shouldn't have mattered for you, as the uBlox does report vertical velocity, so the AHRS DCM code should have used the uBlox velocity estimate to correct the Z accel. unfortunately due to a bug it didn't - if AHRS_BARO_USE was 1 then it always used the baro, and not the uBlox velocity. That is because we originally thought that the uBlox vz would be inaccurate, like GPS altitude often is, but later we discovered that the GPS vz is actually very good, even when the absolute altitude is poor. Unfortunately we didn't fix the code to prefer the uBlox velocity when AHRS_BARO_USE is 1.

So what impact did this have on you? Let's plot the baro climb rate (vertical velocity) and compare it to the vertical velocity your GPS was reporting:

the baro climb rate is in green, the uBlox climb rate in red. They seem to line up nicely .... unfortunately the DCM code uses the delta between values to do the estimate, so we really need to

plot the first derivative of the two:

there is the problem. The first derivative of the baro climb rate is extremely noisy. The derivative of the GPS vz is fine. So we were injecting a huge amount of noise into the DCM attitude solution. That is what caused your attitude to go bad!

To fix this for the next release I've removed the AHRS_BARO_USE option completely. It never worked well, and it caused this sort of problem far too often. I should have removed it previously rather than just disabling it by default.

I've also adjusted the gains a little in DCM to reduce the impact of this sort of noise, and I'm looking at trying to detect this sort of error and correcting. I'll have to see if I can make that work.

Meanwhile, please set AHRS_BARO_USE to 0, and I think you'll find it will work a lot better!

Cheers, Tridge

I'd like to know more about the new L1 controller. Is there a page devoted to it?

What is the official way to report a bug with a release?

Reply to Discussion


© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service