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

Reply to This

Replies to This Discussion

RAW Data?

If I want to look at accelerometer vibration data do I set SR0_RAW_SENS to 1 or SR3_RAW_SENS to 1? What’s the difference?

.

Randy,

In your last graph, the altitude loss looks about right for what it looked like in person.  The battery is a zippy, 3S, 5800 mah (I think I said 5200 earlier).  It was fully charged at launch.  It only has 30 charge cycles on it.  Every fifth cycle I do a balance charge.  The APM is powered from the BEC in the ESC.  The ESC is an Hobbywing Flyfun 18A.  The BEC is 5v@2A. My tx is a spektrum DX7s.  The receiver is an AR7010 with satellite.  I also have an TM1000 telemetry module to monitor the battery.  I have the tx set to warn (vibrate and tone) if the battery reaches 10.5v.  The tx never warned of low voltage, even when the motors seemed to be spinning full throttle.  I believe, but can't prove yet, that the log end abruptly when the quad crashes.  From the KMZ file, the last stabilize (red section) ends approximately where the crash happened.  Again, the location on google earth is off. but if I measure and move the path, it is pretty close.  I'm going to use an image editor to move the the launch end to the actual launch location and see where the final stab ends.  I'll post that when finished. My theory is that something happened to cause the APM to not know where it was in alt, lat and long.  I'm not saying your brown out suggestion is wrong, I just don't think it likely because of the state of the battery as I described and no low voltage warning from the tx.  I also realize that the rx could have browned out as well and not sent the warning.  I've never checked to see what the tx does if the rx losses power.  I'll test that too. 

For the record, I'm not upset that I crashed.  Crashing is part of the RC sport. I'm not trying to blame the APM or code, I just don't want this to happen to others.  I'm a pretty good pilot now but nowhere near an expert so I accept that it could be me.  I only have to replace about $60 to $80 in parts.  That's only about 10% of what I have in the quad so it's really not a big deal.

Last Sunday I had another "event" with an auto mode in 2.9.1 :(

RTL failed to hold position during the initial climb. I was hovering in loiter ~80' from launch, turned the tx off, and it drifted with the wind as it climbed up. I let it continue for a while to see if it would eventually correct itself. I decided to switch to stab mode and stop the climb after it drifted passed the launch point nearly 100' from the position where I engaged RTL. Wind was strong at 15-20mph, and the quad appeared to stay flat, letting the wind blow it as it climbed. Upon reviewing my logs... it looks like something weird happened with Nav Roll:

Pitch looks normal. Nav is commanding a strong roll, but roll appears unresponsive until I switched to stab mode and stopped the quad manually. I made several flights later in the day and loiter worked awesome in the strong winds; in fact in this case I was in a solid loiter hover when I switched to RTL. Can someone please explain how/why this might have happened? It scares me to think what may have happened if it reached RTL altitude and started to head home. Log attached...

Attachments:
Tony you say your BEC is only 2Amp, seems a bit small. Are you powering anything else beside the APM with it?

Sorry for the DP, but I just noticed the brief loiter mode after switching on the tx, before flipping the stab mode switch. It appears when loiter was engaged for that moment, roll finally "hooked up" with the nav control and the quad rolled hard to the right. Then I switched to stab and resumed manual control for landing. Perhaps the Nav input somehow was disconnected in RTL mode? Bug?

COMPASS_LEARN: 0


Set that to 1.

Also, I think there may be something causing this to flip to 0, it happened to me and I know I had never set it to 0. For me it happened migrating from 2.7.3 to 2.8.1

In my case the result was an increasing (and alarming) drift off in one direction. Not sure if it's directly related to your issue though..

Richard,

The BEC powers the APM and the APM powers the rx so the APM and the rx are the only things being powered by BEC. 

I've flown this setup for quite some time.  I fly really aggressively in stabilize and I've never had a problem with power.  I have the warning voltage set at 10.5 so that the possibility of brownouts is minimized.

Randy,

Today I plugged the battery into the charger to recharge it.  It was at 11.3 volts.

Well, I am using 2.9.1... was tuning PIDs flying in my basement trying to get it right for rctimer 4215(3507) 650KV motors on 4S 12x3.8 props on Y6.  After like 20 minutes of tuning (i use 433Mhz telemetry/radio) disaster happened.  When hoovering 4 feet off the ground Y6 hit the basement ceiling in the blink of the eye. Broke props when touched beams, flipped upside down and dropped to the floor. I was not able to disarm it ... approached carefully and unplugged battery.  Review of the flight log shows it turned on RTL on it's own.  Why?  Was it supposed to be addressed?  Why it went wrong and how to prevent this from happening? 

I put two screens together - first is normal flying just a second before disaster and the second one a second after it started RTL.

Thanks!  

Attachments:

Forgot to mention - this is on APM 2.5.  CH5 used for mode control remains the same - in "STABILIZE" mode. 1798 PWM.

post the tlog, and log

Wish I could get 10 satellites in the basement.

Here is the log.  It is big - I was flying for 20 minutes or more before it happened.

uBlox GPS is amazing.  MTK3329 was getting 3-4 sats only and only 2D fix.  I am surprised.

Attachments:

Randy,

I've included a image with the path moved to actual location.  I've marked launch, loss of control and crash location.  The path looks pretty accurate except for the final stabilize path.  The visual path from loss of control to crash point was a straight line.  As you can see, the logged path does not match.  Even though I know the battery was fully charged and I'm confident in it. I'm leaning more toward your brownout theory.  I'm not totally convinced though.  I would think in a brown out that shuts down the APM, the motors would have just shut off instead of going full  power.  I guess it would depend on the ESCs at that point.   However, I would think if they all reacted the same, they would have caused the quad to climb.  I guess they could just maintain the settings at time of loss of signal and continued on the same path.  If that is the case, I would say the brownout is most likely the cause of the crash.

Attachments:

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