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
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!
Thanks for taking a look Cala.
It also could be #4 right ? and 3 tries to compensate ?
It is for sure the motor or could be the ESC ?
coincidence or not the ESC #3 got pretty damaged upon hitting a wall (some capacitors and a few other components were gone), it could also be the case that it was this one that caused the fall and coincidentally the one that hit the wall, right ?
I've bench test all the motors / and the three esc's remaining and everything works. 55m fall and not even a single propeller broken (damn APC propellers are made of steel ahah)
For me motor 3 is the problem, I'm not an expert but if I'm incorrect anyone else shure correct me watching the graphs. esc can be the problem too but a pitty that you can't test it. If you can't find nothing, repair it, test near the floor and then read log if you notice any ERR message, check connections and wires too, looking for any little damage.
I have a 2nd 3DR Pixhawk which I test from time to time using the GPS on serial port 2 as the original gps port got ripped off on a flip over. I tried a few flights on v3.2 and it worked, but didn't feel comfortable enough to fly it that way so took it off.
I've put this crippled Pixhawk on a quad for some more testing this weekend. I put the latest beta on from today. I notice my status says no gps but if I look at the detailed status in Mission Planner, I see the # of sats and hdop data.
Is there anything new in any of the versions that might be relative to what I'm trying to do to help make this somewhat reliable using the sat connection into the serial port? Will tower show the # of sats and hdop?
Sorry for the simple questions, but have been away while and have decided to put my good Pixhawk on an 20 lb x8 if I can get over some of my calibration problems.... Just thought I'd reacquaint myself with the lastest firmware and a less expensive lighter quad first.
Thanks in advance for any advice. Hope it's ok to post this here.
I have a photo quad with 390 kV and 15x5 props, and I'm loaded with a 10.000 mAh 6S for 34% hover. And that's with only four motors !
For your hexa, a 16.000 mAh pack would be fine, probably even a 20.000 mAh.
Hey guys, I got a horrible Altitude Hold control/estimation and I can't fix it. I have been flying the very same system with the 3.2.1 (Pixhawk), but as soon as I updated to the new release (and calibrated) the altitude is horrible. Please, check out my detailed post HERE
My opinion in your post
Nice flying field!!!! I wish!!!!!
Can someone please advise the CH8_OPT value for Brake mode (flight mode 17)? Doesn't seem to be any mention of it in latest mission planner (either in the Extended Tuning page Ch8 Options drop-down, or on the Full Parameter list against CH8_OPT) or even what theCH8_OPT value is on the Arducopter manual page. Thanks, Paul
Been wondering if it I have a problem, or there's a bug in the ESC calibration mode.
Been running a pixfalcon for a while since 3.3.0 and recently came to do a rebuild / update to tidy some wiring and software updates to arducopter, OSD and crossfire. Went all ok, upgraded the BEC to a 20A CC PRO (set to 5.1v), and decided to do all the calibrations again, just for maintenance. Everything went ok...except for ESC calibration.
My normal process is the "all at once, two power cycles at full throttle" method, and indeed, all 4 Flame 80's signalled the end points had been set. Now normally, I blip the throttle a few times, just to make sure the ESC"s are indeed firing up at the same time. Worked before after all.
But not this time. Powered up, and all motors started at the same time...then after a split second, refused to respond to throttle commands. Worse still - after about 10 seconds, all motors wind up to what looks like full power. Only way to break in is the safety switch or the batter unplug.
Thinking this was a fault or an issue with the ESC's (the pixfalcon only has signal on the motor out ports, and since the Flame 80's need 5V & GND I needed to plug these into the 5V BEC), I plugged in a spare Pixhawk, since there would be 5V on the servo rail. Same issue - enter ESC calibration mode, do the end points successfully, spools the motors, and...locked out again. The motors seem to be working normally in normal mode though?
Just to be doubly sure, I connected the 4 ESC"s direct to the Crossfire cutting out the pixhawk completely, and did the end point calibrations...and it worked perfectly.
Did the ESC calibration mode get changed in 3.3.2? Why am I lose motor control in ESC calibration mode I'm kinda scared to put it back in the air, in case there's a sudden full throttle lock out incident.
Found an answer to my question above - installed the beta release of Mission planner and Brake mode is configurable in this version (126.96.36.199 build 1.1.5855.1835). The CH8_OPT value for Brake mode is 33. Also selectable on Extended tuning tab on MP Beta version.