Developer

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

Views: 10439

▶ Reply to This

Replies to This Discussion

Permalink Reply by Paul Marsh on December 14, 2012 at 4:57pm

Hi Vince.  You should be able to control cruise, max and min airspeed with the throttle percentage settings while in HIL mode.  Those settings are working for me.  When I change the airspeed PIDs below the throttle section, there is no effect on the simulated plane even though control via airspeed is enabled.

Permalink Reply by Larry Grater on December 14, 2012 at 7:47pm

I've also been using FG but to test high altitude code changes.  The code does AS control and needs the pressure altitude relationship (IAS) to be correct. From what I've seen I can't tell if the problem with AS is in planner or Ardupilot.  The following are observations with the unmodified code: 

v2.65 Planner 1.1.99 - AS is IAS

v2.65 Planner 1.2.27 - AS is zero

v2.68 Planner 1.1.99 - AS is zero

v2.68 Planner 1.2.27 - AS is zero

I'm a little stuck and having problems tracing the issue.

Regards,

LG

 

 

Permalink Reply by Greg Fletcher on December 14, 2012 at 8:27pm

Try checking the enabled box in the MP under hardware options, that way it will use the simulated airspeed from the simulator. When running HIL the AHRS is not running and that's where the airspeed is now calculated.

If the airspeed sensor is not enabled it uses other methods to deduce the airspeed (in AP_AHRS which is not running in HIL) if you don't actually have an airspeed sensor.

Permalink Reply by Paul Marsh on December 14, 2012 at 8:50pm

Hi Greg.  I have checked and double-checked that the airspeed sensor is enabled and "use airspeed" is enabled as well.  I'm pretty sure it's broken.  I'm still curious about the two HIL modes: "sensor" and non-sensor when you load manually.  I wonder which one MP uses.  I always assumed with sensors enabled, and I assume airspeed would be one of those sensor, but I'm not sure about either.

Thanks,
Paul

Permalink Reply by VU2ATX on December 15, 2012 at 11:48am

Hi Djalma !

Nice videos ! It looks that you used Arduplane_2.66. Have you tested 2.68 also ?

Permalink Reply by Djalma C Jr on December 15, 2012 at 1:41pm

I have the solidworks ... then send me the files! djalma.cjr@hotmail.com

 

thanks!

Permalink Reply by Vince Hogg on December 15, 2012 at 1:42pm

Hi Paul.

Tried your settings and still the same 23m/s – nil wind.

Cant even slow it down by using max thr limit, it just decends. When it says GS it really means GS. I put a strong headwind in which slowed the GS right down.

Even on Mission Planner actions tab where it says ‘set speed’ – nothing, no change to Ch3 output.

 

Permalink Reply by Paul Marsh on December 16, 2012 at 11:24am

Hi Vince.  I am now seeing the same thing you are seeing in HIL mode.  The plane will only fly at 52-53 mph ground speed, which relates to about 75% max throttle setting.  If you go with a lower max throttle setting, the plane slowly drops altitude.  If you go with 100% max and 100% cruise, the plane still flies at 52-53 mph.  When you change throttle settings, the plane will momentarily respond, but then go back to 52-53 mph.  Oddly, when the plane is loitering around a waypoint the speed drops to 35 mph or so and it does not lose altitude.  if you change cruise %, the plane momentarily responds, then ignores the input.

I'm having a tough time understanding what's going on.  Hopefully, this only occurs in sim mode and maybe it has something to do with the data APM is getting from X-Plane.  However, I'm fairly sure that I have been able to control airspeed in HIL mode in the past.

Thanks,
Paul

Permalink Reply by Vince Hogg on December 16, 2012 at 1:48pm

OK Paul thanks for verifying that. Im using FlightGear sim so I guess it must be a problem with the HIL code, hopefully not the real code. As you say I slows down a bit when in turns but a steady 23 m/s in a straight line. Perhaps I will raise an issue.

Vince

 


ModeratorPermalink Reply by Graham Dyer on December 21, 2012 at 2:36am

I recently tried some long distance flights with FPV / APM and a couple of things regarding the failsafe protocol that I have discovered that I'm not entirely comfortable with.

I had a few failsafe occurances while in Stabilize, FBW-A and AUTO, (VTx interfering with RCRx). In all cases the failsafe worked correctly however some shortcomings in it's implementation became apparent.

First: after one second of lost signal the APM goes into circle mode, however in one instance I lost a fair bit of height, so I really think this should be changed to loiter so that height is maintained as well as position.

Second: After 20 secs the plane will RTL however 20 secs feels like a very long LONG time in that situation, 10 secs would be much more appropriate (although if the plane was in a loiter and not loosing height max 15 secs would be probably be OK).

It would be really great if one could choose the modes and duration of the recognition periods.

Permalink Reply by Djalma C Jr on December 21, 2012 at 3:58am

I do not use the APM failsafe, I use the RCRx, i setup a failsafe to trigger the switch corresponding to RTH, so when you lose the radio signal, the plane immediately return to the launch point, I think safer.


ModeratorPermalink Reply by Graham Dyer on December 21, 2012 at 6:08am

That is what I'm talking about, if you lose signal then the RCRx "triggers the switch corresponding to RTH", This is what is coded into the v2.68 firmware for APM (ArduPlane) - the default behaviour in the event of signal loss is to circle for 20 secs then RTH (or RTL as it's called in ArduPlane)

▶ Reply to Discussion

RSS

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service