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: 305628

Reply to This

Replies to This Discussion

Run faster!
Or set the Way point nav speed higher.

Haha, I bet the legs will be the limit!!

Thanks, I was thinking that was the issue and I will recalibrate the ESC's and see if that helps.  Otherwise I will replace the motor 6 ESC.

I did do A LOT of testing with motors but either without props or under take off speed.  I think I will try flipping props so that I can test the ESC/Motors with will load and without being in the air.

This is where I wish I had ESC's with data feedback!!!

Thanks for you help Julien, much appreciated!!

I have a Hexacopter with a Pixhawk and have the released version of Ardupilot 3.2 firmware loaded. I performed the accelerometer, compass and R/C calibrations out in the field. My goal was to test a simple mission of a few waypoints spaced at just a few yards apart with the copter tethered with a 100 foot line to avoid a runaway. 

The first flight went great. The copter performed perfectly.  I moved the Hexacopter back to the center of my course, cycled the power and tried another mission. This time though, the copter went into this wild oscillation right after launching and ended up crashing. After the crash, I noticed that the Pixhawk had came loose from the double stick mounting pads that came with the Pixhawk. I'm not sure if it came loose due to the crash or was in the process of coming loose, which may have contributed to the behavior. 

Here is a video:

http://youtu.be/Hl93Gt90KFM

I didn't notice anything obviously wrong in the logs except for the wildly oscillating pitch, roll and yaw. I've attached the logs from the crash in case anybody can see an apparent problem.

(I'll try it again with the Pixhawk more secured, once I fix the broken mounting points in the frame. )

Thanks for any feedback!

Rob

Attachments:

Run faster!

Yep.. I lol'd

Just checked on the video. Wow!.. That was wild. I could say people in the background felt the same way:))))

I am glad it wasn't a runaway; nothing can be worse than that.

As for what happened, I am pretty sure a copter acting like that could demount the controller. However, I am not sure if the controller became undone due to this or not because it started as soon as it lifted off.

I could remount the controller, redo all the calibrations and test hover it (tethered:)))) and see what happens...

 

I also noticed that the internal and external compass offsets were quite different. The external compass is mounted on the standard 3DR mount assembly, but the shaft has a tension fit with the mounting platform. Its possible that the compass was rotated a bit and I didn't notice it. I may superglue the shaft into the mounting platform to ensure that the compass doesn't rotate inadvertently.

Seriously doubt the compass could have caused that. When you lifted off were you in Stablized?  If so the compass does nothing for the copter other than provide magnetic heading.  It''s more than likely you flight controller came loose and it tried to compensate it's inputs from X,Y & Z axis which was receiving wild readings due to it becoming unstable and flopping around.  Alex's suggestion to remount controller and perform a complete recalibration would be a prudent move.

Hi Rob,

I've been thinking about what you've described, and by the way, I think we're all glad you had a moment of ESP when you decided to tether you're Hexacopter; what is your WPNAV_RADIUS set to? I ask this because you describe the mission as "a few waypoints spaced at just a few yards apart". Thinking about this, if the waypoints were set apart less than twice (at least) the distance described by WPNAV_RADIUS, you would create a series of waypoints whose radius create circles with intersecting sections. This creates a unique circumstance where you could possibly create a zone where all waypoints could be "reached" at the same time. In theory this could result in some pretty wild oscillations.

Consider the following examples:

In Figure 1 we have a box described by 4 waypoints that form a square; the waypoint radius in this example creates 3 distinct overlapping zones. The black circles indicate the circular zone created by the WPNAV_RADIUS around each WP indicated by the small red circles. In the Blue zone all four waypoints would be considered by the FC to have been reached. In the green zones 3 of four waypoints would be considered to have been reached, and in the yellow zones 2 waypoints would be considered to have been reached. Only in the white zones would the waypoints by individually described, and this would only be true if we overshot the waypoint.

In Figure 2 the waypoint location has remained the same, but we have reduced the WPNAV_RADIUS shown in black. There are no overlapping zones so the FC would not oscillate.

Lastly in Figure 3 we have moved the WP locations further apart and kept the same WPNAV_RADIUS as in Figure 1. Again we have no overlap, so the FC would not oscillate.

Your WPNAV_RADIUS = 200, or 2 meters; so if your waypoints are spaced closer than 4 meters apart you are going to have at least some overlap as in Figure 1. The mroe your waypoints overlap, the greater the likelihood you might see some strange behaviors.

Can you post a copy of you mission file, or a tlog from your flight?

This is all just a theory, and I welcome the opportunity to either confirm or deny it.

Regards,

Nathaniel ~KD2DEY

I think he was in Auto mode Doug since he was running a mission. In auto mode, compass is used. However, I too doubt that it was caused by the compass. Loose controller seems the best explanation at the moment but how it came loose is unanswered. It must have been attached with a really weak double-sided tape for this to happen in my opinion...

Could've been the controller...like I mentioned it was loose after the crash, but its hard to know. I used the double stick pads that came with the Pixhawk to mount it, but they are small pads and the adhesive isn't all that strong. I may mount it with a double stick pad as big as the Pixhawk and professional grade adhesion next time to prevent unmounting (like I did with my APM in the past.)

Its odd to me that the copter performed the mission so nicely before hand and landed without any trouble. I just moved the copter a few feet and cycled the power on it before starting the next mission. I guess its possible that the Pixhawk was hanging on by "a thread" and when I tilted the copter to move it, the Pixhawk came fully loose without rotating enough to trigger the inconsistent compass readings pre-arm test.

I'm inclined to think that the radical maneuvers caused the tape to come loose not the other way around.

By the way DON'T use one large piece of double sided foam tape to mount the FC to your airframe. Vibrations will be far worse than with a small piece of tape in each corner. It won't come loose, but you won't be happy with the erratic behavior of the FC!

Regards,

Nathaniel ~KD2DEY

Reply to Discussion

RSS

Groups

Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service