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
shouldn't it tolerate a motor failure without catastrophic loss of attitude control? That is the whole point of running a Hex or greater set-up isn't it? Redundancy...
If you want redundancy, you might have to go to the octos.. I have seen FW that will keep quads and hexes airborne with rapid pirouettes and slow descent in event of a single motor failure..
It looks like a mechanical failure and it starts to go bad about 5.5seconds before it completely loses control. I can't be 100% sure because so much has changed with AC3.2 vs AC3.1 that nearly anything is possible but it looks like a mechanical issue.
Looks a lot like my crashes on RTL earlier - any idea how to unpack the bin log to a dataflash type of log so I can have a look?
http://diydrones.com/forum/topics/loiter-and-rtl-crashing-bug
It may not be the same, but it doesn't hurt checking - mine also occurred in auto mode.
Mihai
Hi Randy,
Where could I officially request features for 3.2 or any other firmware version? There are two that I think would be easy to put in (that being said, I'm not a programmer) which I would like to suggest for 3.2 or another FW revision and they are:
1) Fixed Orientation Auto Flights: At this point in time, the WP_YAW_EFFECT does not allow for you to specify a specific heading for the copter to maintain during the course of the entire waypoint mission that the copter will automatically assume. We have to set WP_YAW_EFFECT to do nothing and then manually adjust the yaw on the ground or on the way to the first waypoint in flight. It would be nice to have the ability to specify copter orientation for the auto flight and have it automatically go to it when the WP program is activated.
2) AUTO MISSION: When a waypoint program is designed that is larger than what the platform can handle, it would be great to have the ability for either a) Mission Planner to automatically "slice" the mission into individual flights based on flight time and/or distance, b) APM/Pixhawk to store the whole mission and as it finishes flight lines/waypoints, delete them from memory so that after battery swap, the platform continues to fly from where it left off without the need to re-design/program/upload missions. After all, a "Mission" can be composed of many flights but up until now, the flights/flight lines have to be separated from their neighbors if the mission is too long.
Please let me know if there is a better place to post these ideas where they may be implemented!
Great work so far on all the firmware updates! I love my APMs and Pixhawks! :)
Olivier,
Feel free to add enhancement requests to the issues list.
For #1 you should be able to set the WP_YAW_BEHAVIOR to 0 and then use a condition-yaw command to point the vehicle in the direction you want.
For #2, we don't have exactly what you're looking for but with the introduction of the AP_Mission library copter has far better control of the active waypoint. I've created a mission planner enhancement request to take advantage of that ability. This could include setting the active waypoint before you enter auto mode. So if you'd already done half the mission on a previous flight you could just remember where you left off and then start from the next one. Personally I'm a little reluctant to try and carry over the memory of the mission status between reboots because I'm worried it will lead to support requests like, "why did my mission start half way through on my 2nd flight?".
Hi Randy,
Thank you for that information! That's great to hear. I normally would adjust the orientation of the copter as it flies to WP1 so your solution for #1 above is going to save me a lot of trouble! :)
I understand that for number 2 you may be concerned about the support requests. Is it possible to have this feature as an "option" (ie, selectable in Full Parameters or somewhere)? With an appropriate description, that should eliminate the support concerns.
Is your AP_Mission Library "ACTIVE WAYPOINT" feature already available? I'm assuming it would work such that prior to take-off, the operator would specify which is the 1st waypoint of the flight in the mission (I assume that this is going to be called the "active waypoint") and the copter will then fly to that waypoint and continue the mission? If possible, it would be great to also add a "active final waypoint" so that the operator can control how long the flights within the mission are in place of having to bite fingernails until the voltage shows that it's time to come home and have to abandon the flight, not knowing what the last WP reached was.
thoughts?
Oliver,
For the 2nd part, the mission planner includes the ability to set the active waypoint. It's on the FlightData screen in the Action tab on the bottom left. I'd totally forgotten about this when I replied above. It works like you say, the pilot can set the command that the mission should start from before they engage Auto. It can actually be set at any point in the mission. This is available in AC3.2 (but not AC3.1.5).
I've heard some people using do-jump commands to control which section of a mission should be run. So if only the 1st half of the mission should be run, add a do-jump in the middle and make it jump to the final RTL at the end of the mission. That do-jump command would need to be added before take-off though.
Randy,
Regarding the first part of your response, will this feature work prior to engaging auto with AC3.1.5 or not at all? I'm a bit hesitant to switch to AC3.2 until it has been released as I'm very happy with the current firmware.
With regard to "Do Jump" , if the mission is 3 flights long, adding a DO JUMP at the beginning to set the first waypoint, then at the end DO JUMP to the "RTL" at the end of the mission should work or am I mistaken?
Once again, thanks for the response and for all the help and development!
Hi just installed v3.2 rc2 all went well but when i connect to the terminal so a can do a erase and clear
calibrating barometer appears and then a whole bunch of code keeps on going. How do i stop this so a can gain access the the commands to clear and erase like i always do after a new firmware install.
Thanks for the help
-
334
-
335
-
336
-
337
-
338
of 373 Next