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:
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.
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.
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.
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?
The get_servo_out() function is only called if APM_CONTROL != DISABLED, like this:
#if APM_CONTROL == DISABLED
// 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);
#else // APM_CONTROL == ENABLED
// 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!
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 :)
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:
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:
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:
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!
I'd like to know more about the new L1 controller. Is there a page devoted to it?