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
Thanks Nathaniel,
I will watch the video
BTW, The compassmot ran and it looks like my vibs are acceptable, which surprises me, when I hod the arm while running it up, It feels pretty extreme. Maybe the AP is happy now, but I still want to get my motors running smooth so all the screws don't fall out while flying!
Thanks, I've attached the Compassmot result
compassmot.jpg
Richard,
I'm sorry if I'm not reading the meaning in your comments correctly, but I just want to be sure you understand. The CompasMot is used to determine the amount of electromagnetic interference caused when you apply increasing amounts of throttle. it doesn't have anything to do with measuring vibration levels.
If you can feel "Extreme" vibration then you definitely have a problem. You mentioned having one motor with bad vibration. If you can't eliminate the source of the vibration, replace the motor. I would break the vibration reduction into four steps. First ensure that your frame is as rigid as possible and that your flight controller is isolated from any part of the frame, also ensure that all cables connected to the FC are secure but not taut. Second step is to ensure that the props are all properly balanced. Third balance your motors following the method provided in the youtube video linked above. Finally install the props and dynamically balance the prop/motor combination one at a time while the frame is weighted down at 50% throttle using the same method you used to balance the motors themselves. It's a lot of work, but it pays big dividends. A smooth running vehicle flies better.
You might ask why not skip the motor balance and just balance the prop/motor together, don't, it's better isolating each source of vibration and reducing the vibration at each step. Then in the last step adding the smallest correction possible.
Once you have completed the vibration reduction steps, follow the instructions here to measure your vibration levels.
Best Regards,
Nathaniel ~KD2DEY
Richard: another consideration, Why don't you use a switch to trigger RTL? It's looks more safe than turn off the radio
Richard,
Something else I notice in your parameters is that you have RTL_ALT = 0. If your vehicle happens to be at a lower altitude than the tallest obstacle between it and home, it will likely crash. You might want to consider setting this to an altitude that would safely return at an altitude above the tallest obstacle in your area of flight.
Finally the only fail-safe you have enabled is GCS. This may be a conscious choice on your part, but I would at least recommend that you enable throttle fail-safe.
Regards,
Nathaniel ~KD2DEY
Hi Richard,
A couple of things I notice when taking a quick look at your log. First an auto analysis shows that you have a large shift in magnetic field. Probably due to the increase in current when you apply throttle. If you haven't done so already you should do a compasmot.
The second thing I notice is that you have a really bad source of vibration. Right before your RTL there is a huge spike in vibration levels that undoubtedly contributed to your loss of control. I would look first at the mounting for your flight controller and then at other sources of mechanical vibration, props, motors, frame etc.
Next you have a number of spikes and dips in your board voltage that are troubling, one that dips as low as 3.45v! Check your connectors and PM for any signs of weak solder joints and or bad connections in general.
I think you got real lucky that RTL was able to recover given the amount of vibration you were experiencing.
While you're at it upgrade to 3.3 rc5.
Regards,
Nathaniel ~KD2DEY
**NOTE With earlier 3.3 release candidates there was an issue involving "whiskers" in the accelerometer values. I believe that some of the spikes we see in your log are related to that timing issue, however there still is a large amount of vibration especially in your z-axis.
Thanks Nathaniel That gives me a good list of things to work on..
RE
KD5ZZL
Hi Arni,
What ESC's are you using SimonK, BLHeli or other?
Hi,
I've been assembling my new Tarot 650 Sport quad for some time now and finally decided to give AutoTune a try.
Stabilize worked well, although a little sluggish for my taste, as other flight modes as AltHold, Loiter, PosHold, RTL.
I am very pleased with the RC5, thanks guys for the great work.
But yesterday Murphy kicked in.
First I had problems with my compass (variance error) which I thought I had sorted out.
This M8N + compass combo was unreliable from day one, so I ordered another one from a different manufacturer which arrived a day before, but has a slightly different mount which doesn't fit on my quad without modification, so I didn't put it on.
And so I first did some hover to test my vibrations and after that I started AutoTune.
At about 7-8 minutes of AutoTune, I heard MP on my notebook screaming about errors...
If I recall right the first one was low batery, but I am not sure.
It throw at me all sort of errors, while the copter leaned on the left side and started drifting away from high grass and crashed on solid ground resulting in a broken prop.
I am almost sure I had a black out and wanted to check it in the logs, but my dataflash logs stop at 1 min 30 sec.
It seems to me that I have a good tlog on my notebook, but as I was always relying on dataflash logs I have little experence in reading the tlog files.
What should I check in the tlog to found out what happened?
When I recharged my 8000mAh battery, it was at 3.8V per cell, but it charged only about 2300mAh.
Is the battery culprit for my crash? It's a brand new Multistar used for the first time.
Thanks.
The Multistar are extremely weak under higher loads.
My MC occasionally went into battery failsafe after just a couple of minutes flight time when I performed a fully speed climb in stabilize mode.
Battery was still at ~70%. Swap batteries and try again.
Stephan, I think you are right.
I couldn't check the log for Amps pull, as I lost them, but checking with eCalc, max draw is 72 Amps.
It could be that MS simply can't handle it.