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 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
What is the default setting and wich to choose for Tarot FY690S ?
Any help on this are welcome ;-)
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.
Dont know if this belong here....i have this hex with rc5. Almost tried all 3.3 rc's, but hasnt done much flying. Just waiting for release.
Anyway, today i was trying to calibrate a attopilot and locked the hex down to prevent lift. In stabilize mode the pixhawk throttled up ALOT by itself after i gave just around 5-10%, like if i have raised throttle slowly to nearly full. Throttling down again was possible. Tried several times and it was the same. In alt hold the throttling was normal. Thought of trying to fly in stab mode to see if it happened then, but found it to risky.
Is there a parameter that can cause this? Have weighted it down before many times and it wasnt like this, throttle was normal.
All is calibrated. transmitter in missionplanner, esc's, compass, accel..
Bjoern
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.
eh, maybe if it had a plan to go somewhere on its own :) dont think it knew i put rocks on its feet, haha
Maybe if there was a mission and it should reach a certain height, but not in stab mode, i cant imagine...
You mean you couldnt take off?
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.
and you also weighted it down or flipped prop when it was like that? but i flew fine anyway?
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.
-
407
-
408
-
409
-
410
-
411
of 558 Next