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
Installed 3.3 rc5 and, so far, all works well. I made two attempts to run Autotune. Both successfully completed pitch and roll but battery ran out before yaw completed. May be because we had a bit of wind both times and I had to do frequent repositioning.
I note that Autotune_Axes is set at 7 in MP. Not sure what other options, if any, may be available. Can those be shared at this point in development? Is there an option to autotune yaw only?
Thank you. All of you on the development team are just remarkable with the great job and product you are delivering. Many thanks.
Hi Michael,
If you just want to tune roll and Pitch by themselves, set Autotune_Axis_Bitmask = 3. A value of 7 = All Axis in one tune. A value of 4 will do only the yaw.
Regards,
Nathaniel ~KD2DEY
Thank you Nathaniel. I assume that Autotune_Axis is Autotune_Axis_Bitmask that you refer to.
Michael,
Yes, Autotune_Axis_Bitmask is the parameter you are looking for. The chart I linked to will show you the correct setting for that parameter to perform an Autotune on any combination of Axes you wish from one to all.
Regards,
Nathaniel ~KD2DEY
Crashed my F550 hexa directly after take-off tonight in PosHold mode (at least I thought I was in PosHold but maybe just AltHold). I have flown it a few times since installing 3.3-rc5 and it has flown generally quite well, until tonight! I have attached log.
I powered up the craft, left it to get a 3D lock - had 6 satellites locked in and 4.1m accuracy according to telemetry. I initially armed in Stabilise mode then switched my 6 pos switch through AltHold, onto PosHold. I noticed when throttling up to the half way mark that the motors span up, then slowed down, so I increased throttle just a little (just past half way), and the motors span up really quick and it lurched airborne - very strange behaviour which I haven't seen before. I only went up to about 4-5 metres, and next thing, it started rolling to left, so I tried to correct, then it went crazy, not responding to stick input and dove off to the right into the ground, bouncing off its landing gear (smashing that), pushing the Gimbal mount off its rubbers, and snapping the USB plug in the side of the GoPro ((fortunately GoPro wasn't damaged, but I wasn't filming either unfortunately). It then bounced onto its back, smashing the GPS post through the canopy, but fortunately, not a single prop broken or any serious damage other than that. I would really appreciate any help or advice you guys would be willing to offer, as I'd really rather get to the bottom of this issue rather than flying and hoping for the best next time.
Just checked the lattached log, and it seems to have gone into AltHold - and not PosHold, and then some EKF errors. Apart from recognising that, I can't figure much else out unfortunately (sorry, I'm a relative newby to Pixhawk)
Thanks, Paul
crash.BIN
Hi Paul,
Your controllers are working very hard to lift your front left motor. This looks like a prop/motor/esc problem. The controllers are doing all the right things to attempt to stop the roll but are not getting any response from the air-frame. It looks like the problem was only a partial loss initially then turned into a full loss. You don't have output logging turned on and that would have confirmed things further but it looks pretty conclusive.
Sorry to hear about your crash.
Leonard, Just got the hexacopter back together. Have re-routed and double checked twists in all power lines. Have re-routed motor servo connectors also to keep them away from power as much as possible. Re did the compass and accel calibrations. I did my first short test flight which ended up with an issue, which I haven't experienced before. First I took off in Stabilize mode - just a few meters altitude, then switched to AltHold - this seemed to work fine. Then switched to PosHold - this wasn't perfect - the copter moved a good few metres, so switched back to AltHold. My issue was when I came to land in AltHold. On touchdown (fairly gentle landing) the copter pitched forward and over balanced on its retracts, so the front motors/props went down into the grass (and these two stopped - no breakages), but the copter would not disarm (the remaining props still spinning)! I tried (mode 2) left stick bottom-left to disarm, but the props actually sped up. I ended up having to pull the battery to stop the props spinning. I have attached the log (bitmask was 54054 - I will amend to your recommendation now), so hoping it can offer some explanation to the cause of the issue. Thanks again for your continued support. Best wishes, Paul
214.BIN
Hi Paul
I was just wondering about your log. I see that there is a few EKF warnings and that it prevented you switching to POSHOLD. (From what I can see and the Flight Mode Error 16) Probably why it drifted as it was stil in ALTHOLD.
Have you managed to fix this?
I have an intermittent fault on the front left ESC. Noticed it this weekend when the esc wouldn't initialise at copter power up. I tugged on the cable tie holding this esc to the arm, and heard it suddenly initialise. Have ordered a replacement esc. The EKF warnings I think are due to a hardware error. IMU2 issues most likely. They seem to rear their heads when I connect batteries for a second flight. Something to do with the voltage regulator feeding the IMU2 chip. There is a work around to short the power cable pos/neg after disconnection of the batteries - to discharge capacitors apparently., and this resolves the IMU2 issues when the batteries are connected. I have ordered a new Pixhawk clone which potentially has a hardware fox for this (built to 3dr latest hardware spec). So until this kit arrives I can't say if this is resolved. Thanks for the continued support though - much appreciated.
Still does it on my 2.4.6 so there is no hardware fix for it. .
-
432
-
433
-
434
-
435
-
436
of 558 Next