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)
Replies
Hattori-san,
We don't officially support the px4-fmu only configuration although we think it should work. By the way, you can disable the need for the safety switch by setting the BRD_SAFETYENABLE parameter to 0.
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.
Regards,
i tried the Neo-7 GPS and compass module from hobbyking. it is giving a position error of 500meters. i really do not know why. although i get satellite count as 9.
Data format compatibility issue or maybe map datum mismatch. Can't think of anything else...
I tried the new 3.2 code on my traditional heli last time. Stabilize works, however ..
Is it an intended feature that the tail rotor does not react in acro mode, when i move the yaw stick of my RC?
I only tried it with a unplugged motor. Unfortunately, there are no logs because for some reason the code with enabled logs is to big for my APM2. With AC 2.9 the tail rotor reacted immediately on yaw commands though the code and behavior has changed a lot since.
Matthias, AC3.2 rc2 is completely untested on tradheli, so I'm not sure what is going on with your yaw. I had to do a number of fixes before I try flying it. I've got a Pull Request in for those fixes but I don't know if they'll make rc3.
I put a warning out not to fly AC3.2 on Tradheli yet.
Ohh... this is indeed an interesting fact ;-)
Thank you for your reply.
By the way: How do you make changes to an already sent pull request? Creating a new commit in your branch stashing the old commit (or reverting it?) and then just synchronizing, or creating a complete new pull request?
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 ;-)
-
307
-
308
-
309
-
310
-
311
of 373 Next