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: 10434

Reply to This

Replies to This Discussion

Hi Guys,

In this version as in previous, Condition_Change_Alt not working.  I make param 1 15 cm/sec,

and param 2 an altitude (say 600 ft) which is supposed to be the end condition.  I write the WPs.

When I read the WPs back, it keeps the 15 but loses the 600 (it says 0 instead).

I'm using ArduPlane HIL for simming in Xplane 10.

Is there a way to clear the memory of the Ardu chip, and then re-load everything fresh?

Or is there another fix?

Thanks!

--David

Hi Graham,

Is there any way to turn off the failsafe entirely?  Your suggestions are super for regular flight, but in my app (dropping an RC from a weather balloon) there will be no radio signal.  But I still want it to continue in Auto flying the waypoints programmed.

Thanks.

--David

If you uncheck the two failsafes in the Mission Planner then I think there will be no response to signal loss, so e.g. Auto will stay Auto, but check first on the ground obviously.

Well, in my case, when I want my plane execute the mission, even losing the radio signal, I change the flight mode on the APM configurations of RTH to AUTO, which even RCrx entering failsafe will be in AUTO mode.

Ahh, yes I understand now, sorry. That is a good option if you want the plane to continue flying the mission no matter what, not so good if you're not doing a mission but are in FBW-A or Stab mode.

Maybe with the new version there will be more control over what does what, otherwise I think I'll change it myself in the code.

I confirm this is working. The plane will continue to fly way point regardless signal loss or not.

That is what I had planned to do as well.  I have failsafe on my TX/RX, not using the APM failsafe, and normally have it set to RTL.. However, I am planning a mission that may go outside my radio signal and if I do, I have to reset my failsafe to auto.. 

But , I was wondering what will really happen?  Will the mission just continue? with no interruption  Or will the Auto actually assume the mission is complete and head home anyway...

Have you tried this?

thanks

Mack

This version of ArduPlane still has a feature, left over I think from the old legacy versions and that is it applies full aileron and elevator deflections for 1 second on boot-up.

This can be catastrophic if, at low level, the APM reboots in flight for whatever reason as the plane will, for that one second, roll and pitch violently. I had this happen recently after replacing a faulty elevator servo with a better, different type but the new one drew more current causing a brownout after the BEC voltage dipped too low, thankfully I had enough height and was able to regain control before hitting the ground.

Yes, I now have a separate UBEC but is this potentailly dangerous aileron/elevator behaviour on bootup really neccessary?

Perhaps we could make that behavior optional?

Regards,

Nathaniel ~KD2DEY

Hi Graham,

Maybe using a buzzer instead of a servo signal could be the solution. The servo_test(); function is included in the system_ini(); so replacing this function with a buzzer function and defining it through an analog port can do the trick.

Same for led light flags: gps fix, armed, disarmed,...

Happy new year! Dario.

 

Thanks Dario, to you too.

I'd like to see this behaviour taken out completely as a default rather than have to modify code and add buzzers, LED's etc. I have those on my quad but don't feel the need for them in ArduPlane.

Even having it as a user selectable option is better than what we have now but that would require an extra parameter and we already have enough of those.

Hi Guys,

I'd like to see the LED status lights broken out like the ArduCopter code through the MP in ArduPlane as the APM board is often buried inside the fuselage in a fixed wing plane. I think perhaps replacing the current wagging of the control surfaces to indicate ready status would be OK if there were a ready made way of bringing the ready status to the operator. I think your idea of a buzzer or the like would be a good idea, but I still think that if that wasn't a standard hardware feature shipped with the APM that you would still need some means of communicating the ready status for those who don't want to add any other hardware. That's why the current behavior of wagging the control surface works so well, because it makes use of what you inherently already have. I think an option that was configurable through the MP for all Arduxxx platforms would be the best solution. You already have from what I understand remote LED behavior configured in ArduCopter code and in the MP for basic LED behavior. It would be nice to see this migrated to the other Ardu code. Once that is done adding the option to disable the control surface wagging and enable a buzzer if required would be good too.

Regards,

Nathaniel ~KD2DEY

Reply to Discussion

RSS

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service