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!
Artem, Sorry, I know this is a little off-topic for this post, but I saw mention in another post from you about a possible resolution to the IMU2 Vcc issue - something about soldering a 10k resistor to the pixhawk board. Could you possibly send me details of this mod? Thanks, Paul
talks about the resistor and the reason. This has been going on since December
Leonard, I totally understand what you are saying here. I am very grateful, as we all are for the efforts of all the devs on this project - you provide an awesome service to all us enthusiasts, and we wouldn't be able to practise our hobby/profession(in some cases) without the awesome efforts you selflessly provide. I also appreciate the situation with beta code - I just raised the post here purely to ascertain if my issue was down to my own hardware setup or if it was something code related. As regards returning hardware - I wasn't considering doing this because of the EKF issues, but for the IMU2 Vcc filtering issue which is purely hardware related (just bought a second HK copy based on pixhawk and this also has the Vcc issue causing bad accel/mag health reports unless I first short the power cables before connecting battery).
Can I ask though - in order to take 3.3 and switch off EKF, returning it to the filtering methods of 3.2.1 - is it simply a case of setting EKF_CHECK_THRESH to zero?
Are there some modifications around for this "IMU2 Vcc filtering issue" to be solved?
Can someone direct me to the schematic and point me to the problem area?
No problems and thanks for the kind words.
I am sorry but I am not sure if that would turn the EKF off.
Don't worry Alex,
I don't think anybody is complaining. All I am saying is this code is still a work in progress.
The Devs rely on all the feedback people are giving here to make sure the eventual release is as good as we can make it.
I just don't want people to get too stressed if they see a problem they didn't see with 3.2.1.
If you look about 7 posts up, Craig answered this with the following:
talks about the resistor and the reason. This has been going on since December
The article basically suggests the simplest workaround being to connect a 4k7 resistor on the back of the power module between the 5v vdd output and ground. I will maybe try this when I have the chance to pull my hexa apart (power module is a bit buried on my hexa!)
Sorry for the slow reply. I have tried a couple times but couldn't do it as I only had my phone.
This is the process I use when starting tuning a large copter. First up set these parameters
MOT_THST_BAT_MAX,number of cells x 4.2
MOT_THST_BAT_MIN, number of cells x 3.5
Then set the control loop parameters to their defaults.
In stabilize slowly increase your throttle until the copter starts to lift of the ground. Listen for any sign of oscillation and if you hear it be ready to shut down the throttle immediately.
One of the things I find is if you are hovering lower than 30% then you will tend to have trouble with autotune. If you are hovering at a very low throttle position then add weight to get your copter up into the 30% to 40% range. If you are above that then no problems.
Once you can take off safely then you can start testing small roll and pitch inputs. Keep the copter low so you don't do too much damage if you need to shut it down. I will tend to do this at around 0.5 m.
If you find the copter reasonably safe then you can increase height to say 5m and increase the roll and pitch inputs.
If you find the copter is a little wobbly (slow wobbles about as fast as you can say wobble wobble wobble) then increase the Rate D terms (you can use the slider set to go from 0.004 to 0.008). Just make sure you don't increase it to the point you get oscillations.
If you get oscillations then you may have a flexible frame or something like a gimbal that can move. If you are lucky you will be able to just reduce Rate D. I haven't seen anything that oscillates on the stock PID settings.
This should get you flying. Then you can build up your roll and pitch inputs (30 degrees) to the point where you feel comfortable running auto tune. If you don't feel comfortable you may need to do a manual tune before you can run Autotune.
Hope that helps and sorry for the delay!!!!
I just took 3.5rc out and did some flying. Overall, works great, except that when I launch in Stabilize and switch to Alt Hold, the copter drops fast toward the ground until I throttle up. It's recoverable, but it falls fast enough to potentially break an arm. After I've done it once, switching between Stabilize and Alt Hold (really, any altitude-assisted mode) it doesn't do it. Is that just a parameter adjustment I need to do? I would say it is, except that this weird drop only happens once between arming/disarming.
hmm, it does not happen to me. it sometimes drops down from alt hold into stabilize if you did not have throttle leveled up to where it needs to be, but I just flew in both alt hold, loter, stabilize - did not drop down once.
Sounds like you need to adjust your THR_MID value. You set this so that in stabilise mode you get a hover with your throttle in mid position, then when you switch to an assisted mode the same mid position holds the altitude.
Guys. I really need help...
I'm really struggling to understand a recent problem my hexa developed. It has been flying with no problems until yesterday.
It developed a sudden lean to front/right and I cannot understand what the problem is. You can see the problem around the 3 min mark on the log. Plotting channel 5 vs channel 6 shows you the problem.
It was running 3.2.1 beautifully and in last resort I installed 3.3 rc5, made a full default restore and started fresh. Unfortunately it did not solve it..
I need some guidance please.