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)

Views: 305720

Reply to This

Replies to This Discussion

Randy, thank you for swift response.

 By quick trial,It becomes better that ESC seems to be initialized, but not to become completion.

So, I will go Pixhawk that is the best scenario.



Data format compatibility issue or maybe map datum mismatch. Can't think of anything else...

You you mean you made a mistake that's already in a PR?

I'm not sure of any clean way that can be done.

I would probably create a new branch from up-to-date trunk.  Then cherry-pick the good commits from your old PR branch.  Fix the bad one.  Then do a new PR.

I've not yet found a clean way to fix a bad commit.  Reverts end up being ugly, probably don't want them in trunk generally.

I do wonder if you could revert the bad commit, then make a new commit with the fix.  Then merge all 3 commits into one (the bad, the revert, and the good) so only the good would show up.  You then have the option of making a nice commit message.  Then you can push to a branch on GitHub and force it to over-write the history.  

>I do wonder if you could revert the bad commit, then make a new commit with the fix.  

>Then merge all 3 commits into one (the bad, the revert, and the good) so only the good

>would show up.  You then have the option of making a nice commit message.

>Then you can push to a branch on GitHub and force it to over-write the history.

1) remove (revert) bad commit

git rebase -i HEAD~10 (shows you the last 10 commits)

delete the commit you don't want in the list. it will be as if those lines have never been entered

2) merge the last 3 commits

git rebase -i HEAD~3 (select the squash command, follow on screen instructions)

then edit the list to squash the newer commits into the older commit

3) making a nice commit message

git rebase -i HEAD~3 

follow the on screen instructions to mark commits to be reworded. then save, and you will be presented with each of these commits to reword to enter the new wording.

If you only want to fix the last commit use git commit --amend

git rebase with the squash feature allows you to rewrite your git history, it just gets difficult if you have pushed to master. In this case you just need to accept the mistake and push a commit to avoid everybody needing to do a forced pull.

Thank you for the howto !

I tried --amend.After synching with the github GUI 3 commits showed up (the old, the new and a merge), hence I returned to the original branch, copied my changes and made a new PR.. just in case .. now it's eye candy again  ;-)

I've been testing my quadcopter with the latest beta release of 3.2. I uploaded a simple mission where the copter was supposed to fly to 10 m an loiter. (I had put a small Canon point-n-shoot camera on it as well.)  For some reason the copter decided to fly to nearly 120-130 m (~400 ft) after I attempted to Land. Then it oscillated from 120 m to 25 m a few times then finally got close enough to the ground to cut power to land. I didn't see any obvious error conditions. It kept centered over the original takeoff coordinates and kept the same yaw orientation thoughout the flight. 

Has anybody seen this problem?  (I attached logs and the altitude profile.)

Also, the wpalt values seems to be missing from the logs.  


Was this the first time with the camera?  Is the camera equipped with Wi-Fi?  I only ask as I've read that GoPro cameras with Wi-Fi can interfer with radio reception.  Just curious to help identify your problem.  When you fly without it, did the multicopter repeat the flight characteristics you observed?   

I was using a little Nikon CoolPix S8200 camera zip tied to the frame as a poor man's video platform. It doesn't have any wireless communication capabilities. It may have something to do with the additional weight. The copter seemed to pull it fine and level out without a problem. It worked fine before without the camera.


Does someone know how to control two landing gear retract servo from Pixhawk...I know I have to power servos from bec, but where signal goes...Aux out does not seams to work ..

I am a bit lost in all this connections...

can I use some of MNT_MODE parameter ?


I just ran another test and it flies fine without the camera. I had also noticed that the HDOP was a little higher than normal. (I usually like it below 2, but it was above 3 for some reason. I flew in the early evening so maybe the satellite geometry was non-optimal as well.)

this suggestion from support forum somehow does not work for me:

" @dmurray14.....The pixhawk (IIRC) doesn't support RC passthru, but you can "hack" it to work with the camera gimbal screen assuming you aren't using that already. Plug your leg servo into RC9 on the Pixhawk (labeled AUX1) and go into the camera gimbal config screen and set RC9 to be tilt, for instance. Make sure to uncheck stabilize and then set the limits as required and set the input channel to whatever you want the trigger to be on your TX

3DR Support

Joined: Wed Sep 25, 2013 11:06 am
Posts: 321

I think you can try to follow @dmurray14 suggestion but instead of tilt, use the roll, Iris is preconfigured only to control the tilt so roll could be used for the retractable landing gear

The red wire of the gimbal connection is connected to Pixhawk's AUX OUT 2 (RC10) so you could take this red wire and split the ground (brown wire)."...????

heres what I did. as I also have lights hooked up to the gear switch. make sure you change servo limit to 1900 in mission planner under gimbal


Reply to Discussion


© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service