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!

Views: 374147

Reply to This

Replies to This Discussion

Dear Reader

I don't really know where to post this question and if wrongly posted I hope a civilized moderator will transfer it to its correct place. Thank you. Now to my question:

As impressed as most people are by fascinating radio-controlled flying sauces, I am equally surprised over the design capabilities of some individuals. Taking a passed away dog used for hunting many years and making a set of gloves out of its skin in memory of it is one thing, but to turn a dead cat into a drone... Is that ethical?

Frankly, what do you think?

The cat forums are raving about it, so left is to know what the drone community thinks. After all, where is the moral in this if God created us? Shouldn't also a cat deserve a nice funeral the same way as us humans.

This is what I found:

https://www.youtube.com/watch?v=S8QWMatuiWw

/Kalle

People (governments) are using drones to slaughter entire villages, so the cat thing is really nothing..  God and Drones have nothing to do w/ each other.  (I wouldn't do that to my dead pet, but there are all sorts of people in this world!)

(And, this is more of a technical info forum.. Go to rcgroups drone section for random chit-chat)

2+ years ago when we first saw a dude turn his dead cat into a quad most of us were appalled, but it started a whole genra of frames and frame conversions. Whilst I find it in poor taste I don't find it any more odd then someone taking their dead pet to a taxidermist.

Artem,

I think it would be nice if you give us a brief summary of the conversation in english.

As I (maybe false) understood there are two versions of Pixhack, one seems to be good an the other one has the vibes?

Yes, the original CUAV pixhack has aluminum shell and the silicon padding inside was specifically designed to dampen high frequency vibes. The plastic case version appears to be not made as good as the aluminum and the silicon pad is harder and is of the different shape. 

I have used the original CUAV pixhack for one of my clients. It is indeed a quality made piece of hardware with great IMU dampening especially effective against high frequency vibes. After a positive experience with the "real" thing I have erroneously purchased one in a plastic case (didn't pay enough attention) that one went right back to the seller for a full refund. 

Hello,

Is this negative baro readings are ok in flight?

@Paul 

I'm sure you know about these very economical LDO: http://www.linear.com/product/LT1085-Fixed

They are superior in many ways to any switchers and the famous 7805.

They'll give you excellent line (0.015%)  and load (0.1%) regulation.

I like them as they are so economical that you can afford to have one for your M8T or M8N another one for your Pixhawk from a 2S battery. Incredible results.. Anyway some prefer a single noisy switcher reg.

Henri

Igor, yes exist original Pixhack and fake. I use original with aluminium case. But I think original whatever need external anti-vibration platform on big frame.

Artem, у меня точно оригинальный, во-первых в аллюминиевом корпусе и фирменной коробке, во-вторых купленный напрямую от продавца с некоторыми доп. шнурками. Я бы тоже летал на 3.2.1, но мне очень нужны фишки от 3.3, в частности снятие текущих углов с подвеса на Шторм32. Программер сказал, что вырезать этот кусок кода из 3.3 и вставить в 3.2.1 очень трудоемко, приходится пилить 3.3, хотя она конечно мягко говоря сыровата.

Yes, that just means that the baro thinks it's below the home altitude.  The baro suffers from drift (a natural consequence of the type of sensor) so it's possible to see negative numbers even when it's not below the home altitude.

This looks like a very sudden drop, I can't see the logs but I'd guess that it's an aerodynamic effect caused by the vehicle moving.

Dear, thanks for your answer. I have tested the px4 stack, but I prefer the apm:copter ;) All works perfect on it, but the hott protocol will be nice to have for fly without pc radio.
Is there an option to load the hott-module on-the-fly to firmware as example by sd-card?
Or can I add this module to firmware and recompile it simply?
I have some experience with microprocessor programming on C/C++.
Thanks for your time and support.

Thanks for the answer, logs also have disarmed logs. During the flight one prop sliced receiver antenna so i landed for check. But still althold mode altitude drift. My copter still lost altitude but giving more throttle overrides. On previous versions full throttle doesnt any effect and copter lose altitude until it lands.

If you still review the logs its here:

https://www.dropbox.com/s/rxd5rpucu2av5iv/7.BIN?dl=0

Obliviously its not that bad then. Then it would be nice to see a radio controlled parrot designed with some gyro  and counter rotating propellers so it can run on 1 propeller ax from its head.

Reply to Discussion

RSS

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service