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
I think you shouldn't try to get identical values in the ATC or PID values as the HEX is for sure no symmetrical in weight, deoending how you battery is mounted.
Mine is mounted in the flight direction, which means the roll is easier to move, then the pitch because there is more mass to move up down if you know what I mean.
If you have good PID values and the RC feel at 20 removes the aggressive over correction, then I think you should further tune with the ATC value.
If pitch is sluggish then may need to move it up on just the pitch value, and leave the roll like determined by the Autotune...
Just my thoughts..., obviously to be adjusted by The specialists...
Thank you. I think I now understand. It makes perfect sense. I put back the Stabilize Roll P value from autotune but maintained my ATC_ACCEL of 55000 on both axis. It is bellow autotune value and with RC_FEEL at 20 it feels just like what I was searching for.
Now when testing this, my heart "RATE" ( get it ? )almost stopped ! RTL did not engage ? S*iT? I'm 100% sure It went to RTL, my taranis confirmed it. Also does the log. 2 times and it just stayed there, stationary. Second time it did yaw towards me ( my lua script has a arrow that shows were the front is)
What went wrong? What did I do wrong ?
Thank you !
RTL did not work log
Hi Adolfo,
Spot on.
Adolfo,
I responded on drones-discuss as well but in any case, it looks like the WPNAV_SPEED was somehow set to "0". My guess is that it was done through one of the GCSs.
Hi all,
this might not be related to 3.3 but it is the first time I came across it:
When playing with my logs to find some relation between EKF data and GPS noise/interference (just out of curiosity) I saw some spikes in the EKF3 IPN and IPE data:
The trigger for the change in intensity seems to be the change from GPS status 3 (3D lock) to 4 (3D + DGPS). This seems comprehensible to some degree. But the spikes are visible throughout the log with lower intensity but the same frequency.
Any idea where they come from?
Best regards,
Thorsten
Hi Leonard,
OK loaded V3.30 RC7 last weekend, and entered all values as specified earlier
MOT_THST_BAT_MAX,16.8
MOT_THST_BAT_MIN,13.5
MOT_THST_EXPO,0.7 (12 Inch Props)
RC_FEEL to 50
And started off with the Tune results of RC5.(Autotune_Aggr = 0.10)
But changed STB_RLL_P from 18 to 9, and STB_PIT from 8.85 to 6 to reduce the twitching (Overcorrecting) which was still occuring around centerstick movements in RC5, and is very noticable in the sound of the motors as well. (even with the RC_Feel at 50....)
On RC7 after takeoff just before activating a new Autotune with Autotune_Aggr - 0.05) most of the overcorrecting seems to be gone, so I started the new Autotune...
After the tune which took 4.17 minutes on Roll & Pitch, I saved the Autotune settings and got the Hex up again.
This time any action on Pitch from center stick generated a small overshoot which is apparent in sound of the motors.
Roll seemed to be better, and was pretty smooth,
Overall the Hex acted very locked in with these settings so I started to move the drone much faster as before just to see how it corrected itself hitting the brakes in fast forward and backward movements.
So the Tune is for sure better as before which is apparent in the PID settings STB_RLL_P & STB_PIT as well, as these didn't go over the 10 any longer.
In the over 140 flights I have done I never before had this aggressive / nervous behavior around the centrestick position, so something has changed (i know a lot of the code was changed)..;-).
I guess i should reduce STB_PIT a little to get it smoother again, but I would be way more happy if the Autotune would squeeze out the maximum of this frame (around 2.6 Kg) , like it did before with v3.21 on my heavy drone, (15 Inch props around 5.5Kg) which don't have this nervous behavior at all..This one is smooth as silk around center stick movements after the Autotune, so for some reason it seems to do better on heavier frames ?
Can I tune with Aggr at 0.04 to get it even better, or would that be dangerous territory ?
Onboard video here (Gimbal) : https://youtu.be/1AZLnRknYOQ
Log here : https://drive.google.com/file/d/0BwKkz56PHqS0RFdIYzVIbWdGTDA/view?u...
Hi Erik,
Don't drop the Stab terms until you have reduced RC_Feel to 25.
What has changed is you are now using feed forward in the control loops. This results in MUCH faster and direct response to pilot input. People not using Feed forward before use RC_feel of 100 and are still slower than people using RC_Feel set to 50.
By reducing the Stab_P terms you are making the copter less stable and more prone to external disturbances.
The reason we have done it this way is to let the pilot tune the copter for maximum stability then set the input shaping parameters to get the feeling they like. So now you only change Rate_XXXX and Stab_XXX to fix stability issues. Then you set the RC_Feel and ATC_XXXXX parameters to setup the flying feel you like.
OK thanks Leonard,
Will give that a try and leave the RLL_P & PIT_P where they are,
I did find however another interesting point in the Log's around 1194961....
Clipping on the VIBE, probably due to the fast forward flying, and a sudden breake action, where all RCOUT Channels drop bigtime, but drone kept flying...?
The EKF can handle a fair few clipping incidences, especially when it happens during extreme maneuvers only (provided you aren't doing continuous extreme maneuvers).
And then it only tends to mess up your navigation for a bit.
-
343
-
344
-
345
-
346
-
347
of 558 Next