Developer

ArduCopter-3.2 beta testing

Warning #1: PX4/Pixhawk users upgrading from AC3.1.5 (or earlier) may need to re-do their compass and accelerometer calibration because AC3.2 also uses the backup compass and accels.  Pre-arm checks have been added to ensure this has been done.

Warning #2: on the APM2.x the logs must be downloaded using MAVlink instead of the terminal.

AC3.2-rc14 is now available for BetaTesters through the mission planner’s Beta Firmwares link.  The full release notes can be found in ReleaseNotes.txt and changes from -rc13 can be seen below.

     Feel free to raise issues found during testing on this discussion or in the new support section in the APM Forum.

     It’s a big release with “the onion” restructure and a bunch of new features (including these 57 closed items) so we need to re-test almost everything including all flight modes, all mission commands and all the new features.  Marco and I will be maintaining (and adding to) this testing list.  Issues reported will first be checked by Jonathan, Marco and I and then confirmed bugs/issues will be put on the github issues list (and then hopefully fixed).

     Thanks especially to the beta testers who put their copters at risk testing each release.  Enjoy!

Changes from 3.2-rc13
1) Safety Features:
     a) fail to arm if second gyro calibration fails (can be disabled with ARMING_CHECK)
2) Bug fixes:
    a) DCM-check to require one continuous second of bad heading before triggering LAND
    b) I2C bug that could lead to Pixhawk freezing up if I2C bus is noisy
    c) reset DCM and EKF gyro bias estimates after gyro calibration (DCM heading could drift after takeoff due to sudden change in gyro values)
    d) use primary GPS for LED status (instead of always using first GPS)

You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –

Replies

  • H1 all

    I have a problem with POSHOLD.

    I have set the quad up as best I can. It flies very stable in Stabilize mode. and is very responsive.

    When switching to POSHOD it starts to bounce up and down. Motors quick accelerate and decelerate. moving copter about 100mm in either direction. I have set mid throttle as per log.

    Log attached.

    Cheers John H

    3691173134?profile=original

    2015-01-18 19-18-09.bin

    • Another suggestion, check your vibrations level, I had some issue in one copter and that was the problem

    • Hi John,

      your HDOP was not that good but it's not the only issue.

      Your baro seems to be disturbed,  try to protect it with foam or a case.

      To identify the issue, it would be great to:

      - first: fly in alt_hold and check if the z_oscillation persist the same way you've seen them. If so, that means your problem is related to baro and copter a bit too nervous to maintain its desired_alt.

      - second: if not, try loiter and check oscillations

      I think you could lower your THR_ACCEL params to default values and compare behaviours.

      THR_ACCEL_P = 0.75

      THR_ACCEL_I = 1.5

      THR_ACCEL_IMAX = 500

      About POSHOLD, I suggest you to use these values to begin

      PHLD_BRAKE_RATE = 8

      PHLD_BRAKE_ANGLE = 3000

      • I second John. It will most likely be the baro issue. No problem in Stabilize mode because the baro sensor isn't in use. It starts bouncing in loiter because loiter mode has the alt-hold. You will see the same behavior whenever the baro sensor is in use like (Alt-hold, loiter etc.)

        One other thing to look at might be INS_MPU6K_FILTER parameter. If it is high, you may try to reduce it (try 20 or 10). This especially helps if your z-axis vibration is high.

  • 3701915334?profile=originalBased on the logs it looks like motor 1 and 3 where trying to keep the copters nose up.  This could have been caused by wind or the front of the copter is heavier.  When you selected Loiter the copter which was coming down would now try to level off which will cause the motors to change.  At that point the copter was starting to pitch over on its right side badly as motor 2 was told to idle with no effect as the copter flipped several times.

    It did recover when you put it into Stabilize mode but then motor 1 went to idle and then to max?

    This is where if we had motor feed back we could see what the motors did.

     

    Mike

     

    • Hi Mike. We actually replaced the #1 motor, due to it not keeping up sync, and.....

      We found few wires broken, and the entire center support shaft was destroyed. It must have gotten an hairline crack during one of our hard landing on previous flights and went missed, and reared its ugly head during that fateful flight.

      We have since replaced the problem motor, and will be testing it again tomorrow. 

      Your intuition was correct. #1 motor was working harder the entire time, due to added stress. you can see where the iron core was rubbing against the bell housing, and grease marks where the crack was.

      It was impossible to spot the damage on the motor, as preflight test (grab and shake) didn't show anything out of ordinary, and first initial hover showed nothing wrong.

      Lesson learned. Next time, any hardlanding/crash, we will do a through dissection of each components before using them again. 

    • Thanks much, there was some cross wind, ~5-8mph, which the two front motors, were facing.

      I will perform the sync test as its the only explanation on what could've happened.

      Thanks for your insight.

    • Hello, I have a couple of problems to report both of them intermittant:

      1) A few times in the past month when I power up my Vtx (on a separate battery) the GPS will suddenly lose connectivity with some or all satellites.  Could this be an issue with a loose wire to power the Vtx?  I found one and fixed it and haven't had the problem since, but it has been an intermittant problem, so I'm not sure what to think.

      2) I've had two crashes now where the copter suddenly loses power and drops from the sky.  Investigation of the logs suggests to me that there was no loss of power, but that it was commanded by Throttle In. However, it was not me that did it!  So I'm not sure if this is a problem onboard the aircraft or something with my transmitter?  Logs from these two incidents are attached.  A second set of more experienced eyes on them would be much appreciated. 

      Oh, and what is with the Baro error?

      For reference here is my setup:

      Tricopter (about 500mm size)

      3DR APM 2.5 with data radio, PMU, and individual external mag and GPS (UBLOX)

      Dragon Link MicroRx is connected for PPM to APM.  Also 3 Flytron strobe LEDs are powered off a MicroRx channel.

      Video Tx system is 1.3Ghz (800watt) with GoPro Black 3+(WifFi NOT on).

      FlySky TH9X with OpenTX (and Dragon Link of course)

      I'm also simultaneously running DroidPlanner on a GalaxyNote3 with USB data radio

      2015-01-17 13-08-57.bin

      2015-01-10 15-35-00.bin

      https://storage.ning.com/topology/rest/1.0/file/get/3702542424?profile=original
      • Rob, maybe nothing to see with your problem but be carefull with DroidPlanner - I love this program but I guess that TX + Droidplanner + APM could be an explosive cocktail. I get some very bad experience...

        • Thanks Max.  I've been using DP for monitoring only.  But I can see that with all the capability it has will have there is potential for confusion and catastrophe.

This reply was deleted.

Activity