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
Henri,
I believe this controls how many of the auxiliary outputs on the back of the pixhawk are PWM (the rest become relays). Yet another undocumented feature! I'll add it to the wiki somewhere, maybe on the Relay or Servo pages.
I flashed rc7 back onto my TBS Disco. I wanted to try the auto tune again. I took off in stabilize and flew a little bit. Checked alt hold and loiter modes were working good. Flipped it back to alt hold and proceeded with auto tune. It finished the auto tune with no issues what so ever. I decided to land in alt hold with the auto tune switch still on so I could disarm and save the settings.
This is where it got a little strange. I landed and with the throttle all the way down the props spooled down and all but stopped they all of a sudden spooled back up with the throttle still all the way down. I tried to disarm it and it was floating on the ground doing 360 degree rotations. I flipped it to stabilize and it all settled and disarmed.
Maybe I am doing it wrong by landing in alt hold with auto tune switch still on or if it may be a bug. I have the log attached if anyone would like to take a look at it. I believe it was around the 3 to 4 minute mark where I landed after the auto tune. I did rearm and flew around and it flies great. Current roll pitch rates are at 8.625. I may have to tone it down once I get the gimbal back on.
2014-09-09 19-27-13.log
Hugo, Andrei,
So what happens normally (I haven't seen your exact log of course so I'm extrapolating a bit) is the impact of hitting the ground slightly upsets the inertial navigation system and it thinks it's falling at a higher speed than it really is. It takes a while for it to get over it and realise it's actual descent speed. The landing detector won't accept that it's landing unless that descent speed is between +- 30cm/s. So the faster-than-reality descent speed it thinks it sees after the impact stops the landing detector from recognizing the landing for a bit. We tried to make it a little more relaxed with the slightly disastrous results we saw with -rc6.
Yes, to rework a popular cliche: Better to be on the ground thinking you're in the air, than in the air thinking you're on the ground.
;)
Yes, I agree with Marco that it's not a bug.
The "Alt disparity" is a check that the inertial navigation and barometer are in sync. They can take a while to sync up after starting the vehicle and it'll probably take longer if the vehicle is flipped over. I suspect that waving the vehicle didn't help but rather it was just the time spent waving it that allowed the two to converge. I'll update the pre-arm checks wiki page with the new checks added in AC3.2.
I don't think it's a bug, you should never connect the battery with the drone in that position, in general it's a rule.
During the initial phase the drone must remain motionless, and not upside down, for a few seconds after you connect the battery connector.
Are you using version AC3.2 or AC3.1.5? AC3.2 does a better job of holding position when rotated like this.
The reason that it doesn't hold position perfectly is because there are multiple things that make it drift that work on different axis of the vehicle. This includes wind, the vehicle's COG can also be slightly off causing a drift in one direction, there are also accelerometer biases that can make it think it's moving in another direction. When the vehicle is still and not turning, we build up a single set of 3D corrections that account for all these disturbances but when the vehicle is turned, some of the disturbances rotate with the vehicle (like accel biases) but some do not (like wind). It takes a short amount of time for the corrections to build up again (using the GPS) to counter the new combination of wind, cog, biases.
ReM,
Ah, it's designed to work that way. If it's heading is yanked more than 10degrees from the target it drags the target around. I think we thought it would be safer this way because it won't whip back around to it's previous heading once yaw control is restored.
P.S. Your english is totally fine.
Sander,
Maybe there's a couple of problems. The first one is the compass-dev-id2. That should be 13xxxx. the "-1" should only be reported if you're using an older firmware (like -rc5 or -rc6) or maybe the board hasn't been power cycled since the firmware update?
Next I suspect the old version of the mission planner is being used for the compass calibration. If there are two working compasses then it should show two globes when calibrating. I run the beta version of the mission planner (Mission Planner 1.3.9.2 build 1.1.5360.31789) although it's a bit like running beta versions of arducopter in that there can be issues.
I've got the same, but much much worse problem on one of my helicopters. The Pixhawk is about 1cm from the motor. So the internal compass offsets are >5000. It's completely useless. The compass pre-arm check fails, and I can't do anything to fix that. Therefore, I have to turn off the compass pre-arm check to even be able to arm. This is not great, as I lose the benefit of the compass pre-arm completely (ie: if the remote compass fails or has another problem, I won't know).
I think something will have to be done about this as I'm sure you and I will not be the only ones with this problem.
-
141
-
142
-
143
-
144
-
145
of 262 Next