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
Hi leonardthall.
Thank you very much for your help. Ecalc software "said" that hovering should be around 45 to 48% throttle. (8S 10A) giving a possible 4 to 6 minutes flight. So hopefully should go ok. I'll follow your directions.
On a different subject:
Still with 3.3 RC5:
Following a successful autotune on a 1 meter (axis to axis) hexacopter, storing values after completion of auto tune indicated on mission planner (one axis at a time). everything looked great. Did first roll then pitch and finally yaw. This last one took really a long time..
Anyway few days later wanted to take off and aircraft was really jerky, short wobbles, and it was really hard to see if it was in the pitch or roll axis. Diminishing the D value a bit at a time did sort of "calm down" the beast but I couldn't work out why it did change so much. (From a fantastically stable aircraft in the air just at the end of auto tune to a nervous wild jerky beast)!
Just thought I let you know as something changed in between without clear reason.
Cheers
Henri
The default PID's are normally pretty acceptable to get you in the air on your maiden. Have you experienced any problems with the settings?
I guess PID are very different depending upon weight motors prop size and shapes etc...
So I would have like to get some "possibly working PID" for the model I did mentioned. (Heavy H shape aircraft).
models.jpg
You shouldn't need to touch those when starting out.
The tunable parameters for flight are on the "Extended Tuning" tab. Their default value should get you a reasonably stable take off. You may need to slightly tweak to keep it stable, but it shouldn't be far off
The challenge with sharing PID's is they're based on a myriad of factors which don't typically replicate when DIY'ing a model. In your case, you are flying a very large and heavy craft with an indeterminant frame, motor, ESC and weight balance combination. If I don't have all of those the same as yours, my PID's -- particularly having been tuned and therefore very specific to my craft -- are likely to be a risky proposition.
TBH, this quad is a significant investment and I'd caution against running beta firmware before you've tested with a stable release.
I think I had same and I concluded that program feeds input to motors, does not see response from a barometers and feeds even more input to motors to increase lift. Is it a logical assumption?
I tried to fly mine in stabilize mode and it did not get anywhere, if that matters.
sorry, bad choice of words. did not get anywhere = it means it did fly fine and did not fly away from me.
stabilize mode worked fine. no issues. I have different problems - failsafe RTL, controls invert in super simple mode, etc.
I posted logs here about them.
Here is an another log, from other session that had an oddity.
radio was not turned off, really. yet I see failsafe for Err Radio in there - but may be I walked too close to the drone, but from other perspective in same timeframe with this red banner for 'Err Radio' and 'failsafe radio' you can see how I tried to switch flying modes - so radio link was on and working. Odd.
What was peculiar - it was a third session, and I unplugged battery, plugged it back on, saw 12 sats on the minimOSD screen, tried to arm drone but it responded - 'need 3d fix' and refused to arm. it continued like that for a while and then finally it decided to arm.
as it flew before for 5 min or so and GPS was in lock with blue led on - I am not sure what is the deal about that.
In GPS glitch I see green line with sats count to begin kinda late, what is that about? How can it be different with what minimOSD shows on the screen? I saw 3D lock status icon on taranis telemetry as well at same time.
PS. So, a first GPS data shows in line 1188, at 10:13:54.
log starts at 10:13.04. as it can be seen I was able to arm it at 10:14:19. Was it a mandatory delay? Why it was saying me it has no 3D fix al that time ?
2.BIN
Leonardo,
It's hard to be sure but unlike for super simple mode, I'm pretty confident that simple mode is ok because it gets so much use. Maybe the friend didn't know that the heading of the copter at the moment it was armed is important? That's a guess, I'll need a log for sure... we've changed a lot of anything is possible.
Randy,
in addition to the log I provided - could you pls explain how exactly logic for super simple mode even works?
How does it know where I am located with the transmitter? Why does it go crazy like that when it gets close to the operator?
PS. on the response with a log I said - 'RTL did not do anything', I am not sure about it actually, but I think it actually drove drone right into my neighbor's flower patch, in the opposite direction from a proper startup spot, and it may correlate with same wrong directional inputs from the remote. but I am not sure. it all happened very quickly and as it started killing flowers with props I killed its motors.
Paul,
Sorry for the slow reply. Super simple mode assumes the pilot is at the vehicle's home location. I guess in practice the user is a few meters away from the home position but normally it's close enough.
-
332
-
333
-
334
-
335
-
336
of 449 Next