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

Reply to This

Replies to This Discussion

Sorry about your mux, I fried mine on my APM2. It was caused (I think) when I caused a momentary short on the power supply resulting in a spark. I don't know why this caused the mux to let go but I can only guess that this chip can be a bit sensitive somehow. But I am not sure if I wired up my osd wrong or something and the timing of the short was just a coincidence.

Sucks when stuff like this happens!

Thats what i dont get 

no shorts not osd just had usb and 900mhz plugged in at the same time.....

surely that should not fry the chip.

would it be best to maybe route 900mhz to uart2 permanently to avoid this in future.....

oh well i guess thats it then....rs electronics thankfully have 

TS5A23157

in stock and i have access to a smd rework station at work will replace it and see failing that i may even go far-out and remove the mux and  bridge the pins for usb only .....at least it will be usable....kinda.....might then work with 900mhz on uart 2....will have to have a close look at the eagle files....and see

and for heavens sake can someone please make a bold note in the manual so that no one else gets these plug in at the same time.......and fry their hard earned cash on something thats not explicitly documented.

this is all that is said

Important note: You cannot connect via the radios when your APM 2.x is also connected via USB (they share the same port). Make sure you disconnect your USB cable from the APM 2 board before attempting a wireless connection.

maybe something like to connect usb and wireless telemetry YOU WILL FRY YOUR MUX IS MORE APPROPRIATE

Theo, I have had some stuff fried due to power spikes. I'm now going to use a

http://www.pololu.com/catalog/product/750 for the FPV gear and

http://www.pololu.com/catalog/product/751 for APM and related equipment.

However: I have NOT flown with this yet and YES it adds another level of complexity. 

Last time this happened, it fried the APM2.5, uBlox and MinimOSD all at the same time. All connected to the 3DR provided power module.

But, I have down to 2.8.1 is Altitude value normal.

I routinely have both my 3dr 900mhz plugged in at the same time I am using the usb port and so far I haven't had any problems. I know you can't use the port for both at the same time but I haven't seen adverse effects on the apm. As Leonard said, all it takes is a micro second of bad connection and you may not even notice an arc etc. If the 3dr radio can cause this problem it should indeed be noted somewhere.

I could be wrong, but when you are in loiter mode the apm does all of your leveling etc to maintain position, so I would think you would see pitch and roll inputs that the apm is providing to maintain position etc.

Tim, I had this reply from Randy a few weeks ago

-----------------

Vince,

    You can graph Roll-In vs Roll and Pitch-in vs Pitch in the dataflash logs.  The Roll-In and Pitch-In is actually a mix of the pilot input and autopilot-input so it can always be compared to the Roll and Pitch columns that appear next to it in order to see the actual roll/pitch vs desired roll/pitch.

     the downside of us mixing pilot and autopilot roll/pitch into Roll-In and Pitch-In is that we then need to subtract the nav_roll and nav_pitch from the roll-in/pitch-in to see what the pilot was doing during rtl, loiter, missions, etc...but ... that's the way it is at the moment.

Tim, pitch and roll in logs are the sum of pilot and nav controller inputs. The current 'sum of inputs' logging is useful for tuning (that is what the control loop sees). However without isolated pilot and/or nav input logs, depending on the circumstances, it can be impossible to differentiate a GPS failure from a control tx/rx failure. I discussed a similar 'ambiguous failure' I had several weeks ago with Randy. He mentioned the possibility of adding an isolated input log, but it didn't appear to gain much traction for 2.9.2.

maybeThe Free Dictionary: An uncertainty: There are so many maybes involved in playing the stock market.

What compass offset values are acceptable?  I'm just getting initial tuning done on my first quad...it's built with aluminum arms but does have steel machine bolts.  The APM and GPS are about 2 cm above the power distribution board and ESCs.  The compass offsets from one of the first flights are as follows.

COMPASS_OFS_X: 152.637080
COMPASS_OFS_Y: -10.288330
COMPASS_OFS_Z: -370.408260 - the Z looks quite high.

Log file is below...

Attachments:

One of final tests... Waypoints, Loiter, Guided mode, one of the most impressing Circle auto WP with ROI. Great job guys!

http://www.youtube.com/watch?feature=player_embedded&v=eKJVjMlc6R0

OK - Attached is a picture of the APM mounting on the quad.  I also did the live calibration - and - tada - no large swings of the compass at full throtte!  That was with no changes to the physical configuration of the quad itself...

So - that's pretty strange.

I attached a screenshot of me manually orienting the quad in four directions and going full throttle on each direction.  Each of the positions shows a nice flat yaw angle...

Rich

Attachments:

Good news Rich.

 

I would however also suggest that your APM is still quite close to the power lines, could you rearrange your standoffs so that the APM was a cm or two further away from the PCB, that would ensure your improved results. Or an external mag on a top plate above your reciever. Or some mu-metal just above the PDB, if you've been following that thread.

 

Also, with any luck, in 2.9.2 we will be able to compensate for the fields generated by motors current draw with a very nifty little calibration proceedure that Randy, Jonathan and others have come up with. As always, watch this space :)

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