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
Randy, now that 3.2 is nearing release (at least closer than it was in July LOL) the one request I have for 3.2.1 or 3.3 is the implementation of a failure recovery (failsafe) algorithm. I'm sure you are aware of the one developed in Germany ( http://youtu.be/bsHryqnvyYA ) and it sure would be nice to see it or something similar implemented in Arducopter. To have the efficiency of a quad and the flyhome safety of a hex or octa would be a dream come true. I have a cheap 450 that I'd be willing to put a Pixhawk in and do testing and filming.
+1
I've been wondering when something like that would make its way to Arducopter. After losing a frame, prop and motor to a flip in auto tune due to what I believe was a sync issue, it would have been an amazing feature!
I'm sure it would be a revolution for the majority of us with quads and hexes.
Seems to me it can be improved on. After all it is a tri-copter after losing one prop. Use the three forces to keep it level. Vary alternative rotating props to correct yaw. Reduce the speed to lower it down.
That's a great idea but the problem is the quad then becomes a grossly off balance tricopter and there is little likelihood that the remaining motors would have the power to compensate.
not only that but a tricopter uses mechanical roll of the tail motor to correct yaw - this cant be done on a 3 motor quad.
but i agree main issue is balance, and the motor opposing the "dead" motor is correcting only 1 way on its legs' axis, so it cant be done (not my best explanation really).
Is there a better place to discuss this? Like to hear your thinking and explain mine.
Terry,
Yes, that would be a very cool one to do. I'll put the equivalent for the hexacopter on the to-do list for AC3.3 but I can't make any promises. The truth is that I can't do it on my own because I've already got too much on my plate. Some other developer will need to do the heavy lifting.
Randy,
I finally had time to check out the list. Is this the list of things for you to do, or is it a general list? If it's general it would be great if you could add the quad fail-safe too.
I believe the same or slightly adjusted algorithm would work for both quads and hex's. I think both will require spinning for stability, only the quad will have to spin faster because it would be farther out of balance. The feedback loop for this may even automatically compensate for the difference. There is even some suggestion that a quad could survive two motors out although it sure would have to spin fast and the remaining power may only be enough lessen the decent rate. I suspect the coding would not be all that difficult and this sure would improve the safety of quads.
Does it mean, that a Hexa or Octro Copter based on Arducopter is not able to fly with one Motor failed?
That is the only reason to fly more than with a quad, to have a failsafe if one Motor cuts!
http://www.mikrokopter.de/ has this failsafe from the beginnig of providing hexa or okto Kopter.
Andre,
An octacopter and Y6 will fly without skipping a beat even with one motor failed. A hexacopter may survive but as a minimum it will lose yaw control and it might flip and crash to it's death. There's some discussion in my links above about why a hexacopter cannot revert to being a quad and keep flying.
-
176
-
177
-
178
-
179
-
180
of 373 Next