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
It actually sets the home position both when it first gets 3D lock and then again when the vehicle is armed. The only change from AC3.2.1 to AC3.3 is that if the GCS sends a do-set-home command it will end up locking the home position at the location included in that message. As far as I know though none of the GCSs implement the do-set-home command yet so really, home should be where the vehicle was last armed.
I've tested it in SITL just now (using a slightly newer version of the firmware but the behaviour should be the same) and it correctly returned to the arming location (i.e. home was where it was armed).
One thing that could happen is that if you take-off before it has a good lock, it could end recording home while it's flying and it would use that location. This is more likely with AC3.3 because the EKF takes a little longer to settle than DCM+Inav and in fact, the home location is recorded once the EKF has settled (it's not directly taken from the GPS anymore).
So some guess work here, if you have a DF log we may be able to figure out what happened.
Home was always where it captures 3D lock....
Is battery F/S disabled during Auto Tune and/or in any of the 3.3 variants? It certainly didn't work yesterday. The copter was low to the ground so no big deal, but F/S never triggered a RTL.
Murphy's law in affect here. I bought a Frsky lipo sensor but didn't have a long enough cable so didn't hook it up figuring the battery F/S would warn giving have plenty of time to land. Nope, it sucked the battery dry and down the copter went. I think it's "safe" to say the battery is toast.
Link to log file
http://www.mediafire.com/download/qvpht36k6664lq6/2015-04-18_20-19-...
AT results on the quad using 3.3 rc1 dated 4/16 (Auto Tune fixes).
So, this release should also have improved landing on slopes?
I think landing on slopes detection is what is causing the problem I'm experiencing. My quad with Pixhawk would arm and take off normally, but after the first landing and disarm every other time I arm one of the motors would not spin until throttle hits 50%. Then on takeoff the quad would dip to that side I guess because the other motors were already spinning while that starts up from 0.
Does it sound like something that would be fixed with this release?
Cheers,
Ivan,
This sounds like the ESCs haven't been calibrated or the MOT_SPIN_ARMED value is too low. The ESCs should never stop spinning just because of the attitude of the vehicle or whether it thinks it's landed or not.
The copter just wont reach above the 85 if it doesn't need to. So it will log the PWM of the throttle around the 85% + 5% maybe?
I'm not sure, a dev will have to confirm it. From what i read the flight controller will almost never go to max PWM unless you change the parameter for it (that seems to be removed, was THR_MAX).
I think motors in all modes go only up to like 85% of throttle by default. I think there is a parameter for it somewhere.
You don't want the copter to be able to go to 100% during flight or else you have no more power in case of wind sheer or any other time the flight controller needs to do a sudden change.
How do I setup the aux channel for the retractable landing gear?
There are still just 27 entrys in RCX_FUNCTION - Parameter.
http://firmware.diydrones.com/
Yes I understand the risks and built this quad for just such experimentation, however do not have a death wish for it. The Auto Tune portion of 3.2.1 had major issues on my Spy 750 Y6 and 3.3 rc1 still does as many report, and apparently can be modified somewhat. I don't mind going in and changing parameters, but if there is a beta version with modded AT code, I'd try it on the quad.
Although I managed to change the PID's good enough to get the big bird flyable for AT, It would be honest to say I'm not much into manual PID tuning.
-
431
-
432
-
433
-
434
-
435
of 449 Next