Warning #1: an issue has been found with Tower's Pause button which can cause the vehicle to fly to an old position if the vehicle has not sent a position update to Tower in some time.
Warning #2: Copter-3.3.2 fixes a bug found in Copter-3.3.1's desired climb rate initialisation which could lead to a sudden momentary drop when switching from Stabilize or Acro to AltHold, Loiter or PosHold.
Warning #3: Copter-3.3.2 fixes an issue found in Copter-3.3.1 which could lead to hard landings in RTL or AUTO if the WPNAV_SPEED_DN was set too high (i.e. >400 or 4m/s) and/or the WPNAV_ACCEL_Z was set too low (i.e. <100 or 1m/s/s).
Warning #4: a bug was found in Copter-3.3 which could cause a sudden crash if you abort a Take-off initiated from a ground station. Video description is here. The bug is fixed in Copter-3.3.1 so we recommend upgrading.
Note #1: AC3.3-rc8 corrected a long standing bug in the HDOP reporting. HDOP values will appear about 40% lower than previously but this does not actually mean the GPS position is better than before.
Note #2: if upgrading from AC3.2.1 the vehicle's accelerometer calibration needs to be done again.
Note #3: set SERIAL2_PROTOCOL to "3" and reboot the board to enable FrSky telemetry like in previous versions.
Note #4: the wiki will be updated over the next few weeks to explain how to use the new features
Copter-3.3.1 is available through the mission planner. The full list of changes vs AC3.2.1 can be see in the ReleaseNotes and below are the most recent changes since AC3.3.
Sadly this version (and all future versions) will not run on the APM2.x boards due to CPU speed, flash and RAM restrictions.
Changes from 3.3:
1) Bug fix to prevent potential crash if Follow-Me is used after an aborted takeoff
2) compiler upgraded to 4.9.3 (runs slightly faster than 4.7.2 which was used previously)
Changes from 3.3-rc11:
1) EKF recovers from pre-arm "Compass variance" failure if compasses are consistent
Changes from 3.3-rc10:
1) PreArm "Need 3D Fix" message replaced with detailed reason from EKF
Changes from 3.3-rc9
1) EKF improvements:
a) simpler optical flow takeoff check
2) Bug Fixes/Minor enhancements:
a) fix INS3_USE parameter eeprom location
b) fix SToRM32 serial protocol driver to work with recent versions
c) increase motor pwm->thrust conversion (aka MOT_THST_EXPO) to 0.65 (was 0.50)
d) Firmware version sent to GCS in AUTOPILOT_VERSION message
3) Safety:
a) pre-arm check of compass variance if arming in Loiter, PosHold, Guided
b) always check GPS before arming in Loiter (previously could be disabled if ARMING_CHECK=0)
c) sanity check locations received from GCS for follow-me, do-set-home, do-set-ROI
d) fix optical flow failsafe (was not always triggering LAND when optical flow failed)
e) failsafe RTL vs LAND decision based on hardcoded 5m from home check (previously used WPNAV_RADIUS parameter)
Thanks for your testing!
Replies
So, I have to wonder, if there is a general hardware issue, why isn't every pixhawk user seeing this? There would be an awful lot if chatter in the forums if this was the case, so I can't help thinking that it's just isolated to certain hardware.
So far I have seen IMU issues with: RTF Hawk purchased in August 2014, HK Hawk purchased in February 2015, ***** Hawk 2.6 purchased in May 2015. This is my exposure to the clone hawks through friends and people I've built copters for. I guess their manufacturers just changed the silkmask on the board and nothing else :) . regarding crazy amount of chatter : it was noisy back in December-January and 3DR got involved and figured out that there are 2 causes IMU1 was their problem and IMU2 was cloner's, so they swapped real 3DR pixhawk boards and sent all others to the manucturers of the clones. If you red RCG thread about rtfhawk and the HKhawk as well as the HK Hawk discussion page on the item's website you will see a lot of people are having this issue.
Hi Paul,
First up it is a bit hard to see what is going on. If you could use the log mask of 419837 that would be great.
So what has happens is the copter thinks you are flying aggressively so it doesn't think you have landed. But because you haven't flipped on your back it hasn't detected a crash.
Randy and I have been talking about this and will fix this issue tomorrow.
Thanks for your help!!!!
And sorry for the dangerous situation!!!!
Leonard, always appreciate your input and great efforts in developing this awesome project. Thanks for getting back. Best wishes, Paul
It won't disarm in AltHold if it thinks its flying - I believe this only works in stabilize. Rob has suggested (or maybe it was me and he agreed, I forget) that perhaps it should allow disarm if throttle is at zero in AltHold type modes, it would mean that yaw would be ignored if you were descending but I personally think that's better than the status quo. Right now if you want to be sure to disarm you must switch to stabilize first.
I'm almost certain I have disarmed after landing in AltHold mode before (and definitely have in PosHold many times. It seems to be an omission if this is specifically designed not to allow disarm in AltHold once the copter is on the ground. I'm a little confused by your comment - Just wondering why it would think its still flying (you said it won't disarm in AltHold "if it thinks its flying"). Cheers, Paul
RIght it works if the copter thinks it has landed. If it doesn't think it has landed then it will interpret right yaw at zero throttle as right yaw descending rather than as disarm.
OK, so if this is not an obvious question - why did my copter think it hadn't landed? Maybe this is the real issue which needs understanding.
I believe its a difficult problem. For me 3.2.1 was a lot worse than 3.3 in this respect. 3.3 is still not perfect but I find it to be pretty accurate.
I think yest, vortex can distort baro reading, but I am using rangefinder and when rangefinder reading is 0, throttle 0 no movement (gyro) I would expect that status interpreted as landed...
-
433
-
434
-
435
-
436
-
437
of 558 Next