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

    • Thanks for sharing your feedback here, we've all noticed this behaviour and I personally think aerodynamics is the problem.

      Maybe Naza has a kind of barovel (analog to compassmot) that evaluates the baro disturbance in flight related to velocity by relying on accelerometers/GPS for example... but they won't tell us how they do for sure!

      Anyways, I've seen pple are working on special barometer designs to avoid the issue you're describing... I hope they'll manage to get something good

      I've tryed to increase the TC_Z param with CH6 to minimize the weight of barometer to evaluate altitude and I really noticed a nice improvement in altitude stability during braking phasis. So it shows at least barometer and its disturbance can explain some altitude issues. In the other hand, we could not rely only on accelerometers as the cumulated errors would fake the altitude so we have to deal with baro and try to compensate its weaknesses.

      • Can the alt control loop be more dependent on the acc/gyro/mag combination of data when the baro changes are +/- a foot? Pixhawk must have the resources needed for this. Sample control imho should be as follows: read throttle channel if no changes -> analyze acc/gyro/mag any change in vertical velocity -> compensate. I understand apm has very limited processing power and memory, but pixhawk has heaps of reserves atm.
  • Randy it looks like Trappy seems to like the new spline waypoints, I mentioned it over at fpvlabs so hopefully we can get more people off the TBS/NAZA and on to the TBS/APM :)

    http://fpvlab.com/forums/showthread.php?32155-TBS-Disco-Pro-with-Sp...

    • Edgar this is a little off topic but your disco seems supoer smooth and the 2 discos we tried here with APM cant get a stable loiter - after auto tune (and before it) in loiter the machine keeps wobbling in what appears to be quad arm (X config) axis - any tips? 

      how did you manage to get yours so smooth?

      • Lior,

        Add me as friend and I can send you my PID info...also my dampener colors.  Note I also added the optional TBS stabilizer arm for the gimbal.  Or we can start a TBS thread so we can share with others.

        Here is how good I got it with some PID info...but since this thread is about 3.2 beta we can chat offline...this one has not been ran thru any stabilization software at all...its a raw video.

  • With AC3.2rc2-3 At hight speed fly in AltHold mode there is too mach breaking reaction when the rc roll/pitch stick goes to 0. In a windy condition it is possible to flip the copter. How can I turn the AltHold breaking Off or turn it softer ?
    AC3.1.5 do not have this problem. The AltHold breaking is soft.

    • Randy - I am seeing the same issue with 3.2rc3 Slowing down from speed has become way too abrupt.  Im not sure the issue is limited ALT HOLD I've had similar undesirable behavior from POSITION HOLD and DRIFT today.   Id think we would want the decelleration to be proprtional to the crafts speed.    It seems to hit a brick wall as soon as I begin to reduce pressure on the stick.  

      When I say "high speed" I mean 25 to 45 MPH on the GPS with no wind.  

      Real slow speeds dont have a pronounced problem... Im assuming that whatever code works out breaking is not expecting speeds this high.

      (550 size H quad 4s -  850kv 3dr motors, 10x4.5 inch APC props, simonk 30A ESC's, 3DR pixhawk, 3DR compass GPS unit)

      • Developer

        There's no breaking in AltHold mode, it just tries to level off.  So if the vehicle is leaning back then I think it's more likely a tuning issue.  Can you attach a log?  I suspect we will see the DesRoll vs Roll and DesPitch vs Pitch aren't tracking all that well.

        Have you tried using AutoTune?

        • Sorry, but I will can attach log only in a 2 weeks.

          I am not using autotune but my PID setup works fine at AC3.1.5 and AC3.2rc3 at all condition except breaking. Breaking looks like some overshoot while leveling horizont. Overshoot is soft at low speed and very sharp at hight speed. Same PIDs but AC3.2rc3 have breaking bur AC3.1.5  have not.

          What PIDs should I set ?

This reply was deleted.

Activity