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 hope this will make it into 3.3 also :)
we all hope so...maybe one day we will have complete stabile version and stop TESTING bcs. this way I have feeling we are doing only that.Dont get me wrong,i respect developers work but it would be nice to stop developing for a while...Thanks for great effort...P.S.third compass would be great :-)
Emin, as others have said, there are stable versions of flight code for copter and plane that you can use. The reason this project develops quickly is because there are lots of people writing code and lots of people testing.
We will never stop developing and never stop testing.
We have said it a thousand times, if you are not actively testing a new feature then please use the stable versions.
I did not meant to say to stop developing!Everybody here keep repeat like a parrot;use stable version than,use stable version...are you seriuous?what is stable version?3.2.1,i don't think so...it has all the problems bcs of witch we moved to 3.3;does SOLO have stable version inside,or we have to stop it with steping on it like Colin did it on presentation?
I wanted to say;once we get to what you call stable version you should keep "ironing" that until its perfect without adding new functions ..TO THAT VERSION...this way developers stop looking to older version leaving it with all problems it have...when you have 10K $ multi you do not want to experiment and risk some minor problem which can lead to disaster(yes I do have testing rig,in fact 2 of them,but each settings is different,so results as well)...did you ever ask yourselves why so few professional AP rigs using Pixhawk even tho it is most advanced controller out there? No mater how hard I try to convince people to use Pix with all its advantages,answer is always the same;oh no,we never know what might go wrong with that,is it stable now etc. and than they swear to DJI FC or some other(who often use solutions from Arducopter).Ok maybe you are concentrated on selling great numbers of small multis (why power module is for 4S only,why we don't have it for 6S,8S..12S..why don't you develop that if you are for developing,or GPS wich is 3 yrs old,or OSD,lidar etc,etc) why the hell you do not offer stable compact version of your hardware as well as a complete integrated solution??
Please do understand that if somebody criticize something,he is not an enemy of this great project..i would never fly anything else but Arducopter and I am here since APM 2.0..i just want when I recommend Pixhawk to somebody,and build him few thousand $ multi he don't call me every day and mumbling about problems whit this and that...
Please keep on with a good work and thank you all developers out there!
+1
I find this as a very constructive criticism. Emin is right in many points.
And I sadly see the same thing he does: Many people out there fly DJI stuff and swear on it. Just because it is more expensive, they classify DJI equipment as professional.
Arducopter can do things DJI stuff won't even get close to but somehow their smart marketing strategy blinds people out there and they sell their stuff at the price tag they want.
Recently a friend of mine wanted to get into AP and laid his eyes on the new DJI Inspire 1. I recommended the 3DR Iris+ (at the time SOLO wasn't out yet). No matter what I did, I couldn't convince him. There are a lot of people out there (mostly people that don't know much about these stuff); they believe in marketing hypes and go dump bunch of money on systems that aren't half as good and capable as Arducopter but look physically more charming.
So in my understanding when Emin said "Stop developing", he really meant "Stop adding new features till the current version becomes completely stable."
And I do understand one thing as well and that is sometimes fixing a current problem automatically introduces a new feature and this somehow keeps going. This is a dilemma and I understand the difficulty. But this is a problem for people flying thousands of dollars worth of equipment.
I hope developers and other members won't take me wrong. I just wanted to add my point to Emin's.
I really think that Arducopter project is the best thing out there and I am closely following it and waiting for the day it will be a great tool for everybody and bury other commercially super expensive systems into the ground...
I have some sympathy for this point of view. I think most people given the choice between features and stability would take stability given that without it you potentially incur thousands of dollars of cost. I have been mulling to offer the maintenance of a release branch (given that's a lot of what I do in my day job), but I'm not certain I have the time.
People need to understand something about software though - you can have stability or you can have features, but you can't have both. Ok I'm exaggerating a little, but any change has the potential to introduce further issues so generally in software "stable" branches do not add features, only bug fixes. I think doing this for 3.2.1 for instance makes a lot of sense, especially for all the APM users.
I also wonder whether the model is right. At the moment a line is drawn and everyone moves on to the next release. I think it might be better if the release branch was stabilized for a lot longer, with a greater degree of overlap (in time) with the dev branch. Obviously this takes some effort as someone has to identify fixes that need to be merged between branches, but I think its probably worth it.
I think also it might need a bit more formalism - i.e. have a bug list for the stable branch, identify commits that should be merged etc.
My $0.02
Alex O,thank you for express myself better,my English is not good enough for that.
Alex, Emin, Richard,
That's a very fair point of view and I've heard it before. Basically it's asking for the development effort to be spent more on finding and fixing bugs rather than adding new features.
Maybe as an olive branch each of you could give me the top item you'd like fixed and we will have a look? I wouldn't promise it for AC3.3 but maybe AC3.3.1? I don't want this thread to become a massive rehash of everything on the to-do list (there are nearly 500 items now!) so just the top items from these three people for now. Others can go onto the to-do list and put a "+1" or whatever on their top items.
Hi Randy,
May I suggest:
Smoother transition between Main & Second GPS while GPS_Glitch occur since currently it will go to the new location (from GPS_Glitch event) very fast..
-
462
-
463
-
464
-
465
-
466
of 558 Next