ACRO bug (fixed in 2.9.1b): while doing flips in ACRO mode, if you switch to Stabilize while inverted your throttle will go to minimum.  To regain throttle control you need to switch back to ACRO then back to Stabilize again (i.e. switch to stabilize twice).  You never lose control of roll/pitch/yaw.

Loiter/AltHold/Auto/RTL bug: if you switch into these modes with throttle at zero motors will go to minimum until you raise the throttle.

Auto mode altitude bug (fixed in 2.9.1b): setting a waypoint altitude greater than 320m over home altitude may wrap around and instead be interpreted as a low altitude.

ArduCopter 2.9 is now in the mission planner and the downloads area!

The major improvement is we use inertial navigation to improve altitude hold.  This increased reliance on the accelerometers means you must do some additional set-up before flying:

1. Perform the new accelerometer calibration in the mission planner (video).  The auto-trim metho has also changed (video).

2. Add vibration dampening foam between your frame and the APM.  Some suggested materials: DuBrogelhk foam.

 3. If upgrading from 2.8.1, modify the throttle and altitude PID values:

  • Increase your Throttle Rate P, reduce I to zero, increase D
  • Increase Altitude Hold P, reduce I to zero
  • Tune Throttle Accel P and I terms but try to keep P about 1/2 the size of I

 

Here is the list of major changes (a more detailed list can be found in the release notes):  

  • Alt hold using inertial navigation (Leonard, Randy, Jonathan)
    • AUTO_VELZ_MIN, AUTO_VELZ_MAX parameters control the max climb/descent rate for the autopilot (cm/s)
    • PILOT_VELZ_MAX controls max climb/descent rate for the pilot (in cm/s)
  • Landing improvements (Leonard/Randy).  Copter will descend to 10m or until an object is sensed with the sonar.  Then slows to 50cm/s descent (speed can be adjusted with LAND_SPEED parameter). (video).
  • Surface tracking with sonar (Randy/Leonard).  Copter will attempt to maintain current distance from objects in front of sonar regardless of altitude.  Only used in alt-hold and loiter, not used for missions.  Sonar can be enabled/disabled with CH7 switch. (video)
  • Failsafe improvements (Randy/Craig/John Arne Birkeland) including bug fixes, additional check for PPM encoder failure and implementation of battery failsafe.  Set-up instructions are here.
  • Mediatek gps driver accuracy improvements and use of SBAS [Craig].  Instructions on upgrading your mediatek to firmware 1.9 are here.
  • Traditional Heli improvements (Rob) including (a) bringing heli code back into the fold, (b) enabled rate controller (previously only used angle controllers). (c) fix to rotor speed controllers - now operates by switching off channel 8.  (d) allow wider collective pitch range in acro and alt hold modes vs stabilize mode  (e) bug fix to allow collective pitch to use the entire range of servos
  • Acro trainer (Leonard). Copter will return to be generally upright if you release the sticks in acro mode.
    • ACRO_TRAINER : set to 1 to enable the auto-bring-upright feature
    • ACRO_BAL_ROLL, ACRO_BAL_PITCH : controls rate at which roll returns to level
  • Camera control improvements (Randy/Sandro Benigno):  (a) AP_Relay enabled for APM2  (b) Trigger camera with CH7 or DO_DIGICAM_CONTROL command  (c) Allow pilot override of yaw during missions and fixed CONDITIONAL_YAW command.
  • PPM sum support for transmitters with as few as 5 channels (Randy/Tridge/John Arne Birkeland).
  • Performance and memory useage improvements (Tridge).

 

As per usual PIDs are optimised for the 3DR/jDrones quad with 850 motors and 10" props. If you're using more powerful motors/props and are seeing bad flight behaviour in stabilize, start by turning down Rate Roll P in 25% steps.

Special thanks to our testing team lead Marco and the dedicated bunch on the 2.8.1 release thread who put their copters at risk while testing the pre-release version.  Some of their videos are here: 1 2 3 4 5 6 7 8

Please feel free to report issues you find in the discussion below and/or add them to the issues list.

 

Views: 297769

Reply to This

Replies to This Discussion

Starting Arducopter without RC control seems to work out of the box when RC remote is not switched in. I am rather curious because everywhere in the forum, it says that apm2.5 NEEDS to be armed from the RC remote. I have done more than one bench test to see, that MAV ARM and DO work very well without any RC. Not tested on the field yet. Also, first tests show that when remote is turned on during automatic work, it gets control from first switch from flight modes, not before. 

Failsafe mode is set to enabled continue in auto mode. 

Arducopter is 2.9.1

RC reciever is connected and failsafe pwm output is enabled. 

And I would say, that I am rather surprised about it working this way. 

today got an hour of flying.. almost no wind..loiter was solid.. RTL on first attempt today (have flown RTL last week had the same issue), gain altitude then spun around (amazing takes getting use to) then heads home..but half way to home/launch area..it went straight up/gain more altitude at a fast rate..wait a second or two to see what happen but it was getting far, (sh*%Tin my undie)...felt like a runaway quad (as i have had in the past w/ kk board).. switch to stabilize.. and she started to come down and gain control...so i tried it again 2 times on the same battery without landing and flew RTL no problem ...

i'm puzzled.. i had the solid blue light- gps lock..

Well i had some success in getting rid of the pulsing motors by lowering:

Thr_Accel_P to 0.26

Thr_Accel_I to 0.52

Thats seems to have fixed the pulsing.

However it still either drops like a rock or fly off into the sky when the loiter, alt hold and return to lauch are enabled! This never happened when it was unweighted from camera gear.

Is the next thing to adjust the Thr_Mid like Sam suggested? hovering is about 60/65% throttle?

Thanks Tom

That sounds like a good idea to me.  With the hover throttle that high you'll always have some troubles getting a smooth transition because you'll be immediately out of the deadzone when you switch from manual -> alt hold.  So if hovering throttle is 60% you should make THR_MID 600.

dindong,

     Any logs either dataflash or tlogs?

I cannot find THR_MID?

I have THR_MIN and THR_MAX.

My TRIM_HOVER value estimate is 686 i assume this is the value to use in THR_MID even though i cannot find it?

Thanks Tom

hi randy thank for replyin.... still new at this.. sorry for a dumb question..

how do i get these logs..and post em here?

Mike,

    No good I'm afraid.  You can see the x,y and z vibes are all quite bad and you can also see the effect on the inertial nav estimate vs the baro estimate in the 2nd graph.  At times the estimate is 10m from the baro alt.  :-(

Tom,

    Maybe you're still back on 2.9 instead of 2.9.1?

    By the way, at 70% throttle you might want to think about increasing your motor size or upgrading your batter from 3S to 4S...

ah might be. Ill redo everything and let you know.

Thanks for that Randy.I'll have to use the excellent O ring method developed by one of the guys here.Mystery where the vibes are coming from though.

Ho hum, full strip down and rebuild coming up I think.

Many thanks to yourself & the rest of the devs for a stirling job on amazing software.

Regards, Mike P.

Hi, 

Well that explains a lot ahah :) was still on 2.9 not 2.9.1.

Do i replace the 500 with 686 then for THR_MID?

Thanks Tom

Reply to Discussion

RSS

Groups

Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service