ArduPlane 2.68 released
I've just released ArduPlane 2.68
This key features of this release are changed in the MPU6000 filtering, and several bug fixes (including HIL fixes).
The changes are:
- allow for remote reboot on APM1
- fixed secondary aileron and manual servos in failsafe mode (so if the APM software dies, you still have secondary aileron control in manual)
- added new THR_PASS_STAB option. This is for fuel planes, so you have direct throttle pass through when in stabilisation modes (STABILIZE and FBWA). This is useful if you have a throttle cut switch that drops the throttle below RC3_MIN
- fixed THR_SLEWRATE option, which had previously not been functioning correctly. Also improved docs for this option.
- internal changes to new AP_InertialSensor code from Randy
- fixed HIL support for both attitude and sensors HIL.
- fixed dataflash logging in HIL mode
- added new INS_MPU6K_FILTER option, defaulting to 20Hz. This controls the filtering frequency of the gyros and accels and should help reduce the effects of vibration on attitude estimation. It made a huge difference on my HotDog, which has the most vibration I've ever seen in a plane.
- fixed the build of a lot of the library example sketches
- fixed reset of I and D terms in PID library, ensuring it doesn't cause problems during auto takeoff
The MPU6000 filtering changes are perhaps the most significant. We previously samples the MPU6000 at 200Hz and set an internal filter of 98Hz. The ArduPlane code then averaged over 4 samples to get a 50Hz update to DCM. Here is a graph of the accelerometer readings on my HotDog with the old code:
this is rather extreme, as I've setup my HotDog with the APM2 directly touching the fuselage close to the nitro engine. I wanted it to vibrate a lot to test the filtering, and it sure does! A value of 1000 on that graph is 1g, so we're seeing vibrational noise of about 6g in this plane.
I now fly my HotDog with INS_MPU6K_FILTER set to 10, which applies a 10Hz filter inside the MPU6000. We also run the MPU6000 at a sample rate of 50Hz, which means no averaging needed in the APM code. Here is a graph of the accelerometer readings now:
quite a difference! The deviations are now real (from me flying loops and rolls) and not just dominated by noise.
It actually flew OK with the previous code, as the DCM code is quite noise robust these days, but I do prefer making DCM work less hard, and it will help it to reduce aliasing and recover from attitude errors faster.
You can see graphs of other filter settings and also of the gyros for the same plane here. I think the default of 20Hz will be the best for most planes, but if you have a lot of vibration you can try 10Hz, like I now use for the HotDog.
Happy flying!
Cheers, Tridge
Replies to This Discussion
-
3D RoboticsPermalink Reply by Chris Anderson on -
Woohoo! Good news in particular for HIL users, since that was broken in 2.67.
-
DeveloperPermalink Reply by Mark Colwell on -
Many thanks for your massive work!
-
Permalink Reply by Alexey Kozin on -
Thank you very much!
sounds impressive
InertialSensor is enabled now?
could you add the option for g.alt_control_algorithm for only trottle control from airspeed sensor?
otherwise, instead of landing my plane flies much higher above the runway, and I have every new firmware code change
-
Permalink Reply by Alexey Kozin on
-
additonal algoritm
defines.h:
// altitude control algorithms
enum {
ALT_CONTROL_DEFAULT=0,
ALT_CONTROL_NON_AIRSPEED=1,
ALT_CONTROL_THR_ONLY_AIRSPEED=2 //only throttle controlled by airspeed/ fine altitude control used pitch PIDs
};altitude.pde:
static void calc_nav_pitch()
{
// Calculate the Pitch of the plane
// --------------------------------
if (alt_control_airspeed() && g.alt_control_algorithm < ALT_CONTROL_THR_ONLY_AIRSPEED) {
nav_pitch_cd = -g.pidNavPitchAirspeed.get_pid(airspeed_error_cm);
} else {
nav_pitch_cd = g.pidNavPitchAltitude.get_pid(altitude_error_cm);
}
nav_pitch_cd = constrain(nav_pitch_cd, g.pitch_limit_min_cd.get(), g.pitch_limit_max_cd.get());
}parameters.pde:
// @Param: ALT_CTRL_ALG
// @DisplayName: Altitude control algorithm
// @Description: This sets what algorithm will be used for altitude control. The default is to select the algorithm based on whether airspeed is enabled. If you set it to 1, then the airspeed based algorithm won't be used for altitude control, but airspeed can be used for other flight control functions
// @Values: 0:Default Method,1:non-airspeed,2:airspeedThrottleControlOnly
// @User: Advanced
GSCALAR(alt_control_algorithm, "ALT_CTRL_ALG", ALT_CONTROL_DEFAULT),
-
Permalink Reply by Gábor Zoltán on -
This is great!
Thx!
-
Permalink Reply by Djalma C Jr on
-
Hi Andrew
I have APM 2.5, and everything works correctly with a Generic ESC 30A, but when I use the ESC TowerPro H40A (purple) my APM not arm!
http://www.hobbyking.com/hobbyking/store/__9299__TowerPro_H40A_Brus...
I like the ESC TowerPro H40A because with the engine i use, closes an awesome wedding.
What can be done to fix it?Thanks!!
-
Permalink Reply by Rana on -
Tridge, hats off for your wonderful work ! I am loving it ;)
@Djalma, have you measured the +ve supply voltage output from the BEC of your purple ESC ?
If it is 5V then there should be no issue. Also you need to check if there is any programming issue with the ESC.
For example some times ESC is programmed for 3S Lipo and if you connect 2S Lipo then it may not arm.
-
Permalink Reply by Djalma C Jr on
-
hi Rana
voltage output is 4.95v, and I use 3S, is set to 3S =)
this is my ESC:
http://www.gobrushless.com/shop/index.php?app=ccp0&ns=prodshow&...
-
Permalink Reply by Francois Sabourin on -
In Mission Planner, is the "Level" command button under the Configuration tab the same thing as remote reboot? I haven't found a separate reboot function anywhere else.
-
Permalink Reply by Rana on
-
Francois, it is not the same and you can find it in the "Actions" tab of the "Flight Data" window.
There is option PREFLIGHT_REBOOT, select it and press "Do Action" button.
@Djalma, sorry for the delay. If your ESC is working very well with receiver in standalone then there no doubt that it will not work with APM. I insist, pls check user programming of the ESC. You also need to check pwm pulse width range of your ESC, generally most of the ESC's accept 1milli sec to 2milli sec pulse width for normal operation.
Did you do the radio calibration ? If yes what are the minimum and maximum limits (pwm pulse width values) of Ch3 ?
If you are unable to resolve then I can try remotely by taking you on Team viewer.
-
Permalink Reply by Lloyd Breckenridge on
-
There ARE known issues with some ESC's they either initialize too quickly or to slowly to suit the APM.
It has been reported before in the Arduplane forum.
Also a 1.5 A BEC is not enough I suspect for the APM, your receiver and servos.
You may get brownout situations if you do get it to Initialize properly.
-
Permalink Reply by Francois Sabourin on
-
Thank you Rana, very useful feature once you know where to find it.
Social Networking
Top Content
Contests
Season Two of the Trust Time Trial (T3) Contest has now begun. The fourth round is an accuracy round for multicopters, which requires contestants to fly a cube. The deadline is April 14th.A list of all T3 contests is here.
Groups
-
Moderators
24 members
-
ArduCopter User Group
1289 members
-
Telemetry over cellular …
248 members
-
South African DIY Drones…
57 members
-
ArduCopter Italian Group
87 members
Advertisement
© 2013 Created by Chris Anderson.
Powered by
