This is a discussion related to the Copter development priority debate that popped on the Copter-3.3 beta testing thread. A quick categorization of the things we work on in each release include:
- bug fixes (i.e. fixes to existing features that have a defect)
- safety features (i.e. new features that improve reliability)
- other new features (i.e. non safety features like landing gear)
The basic question might be, "are we spending too much time on new features, time that should instead be spent on bug fixes or safety features?". Let the debate continue!
Replies
+1 reliability
it will be great to have acro mode and stable mode good than cc3d or naze 32
Copter reliability vs functionality?
Functionality = Reliability.
No reliability = crashes = incapacitated = functionality like a brick.
Maybe not everyone would consider it a bug but the problem of ppm channel mapping is still on the table and for some of us that is a real issue when it comes to Pixhawk. I've been playing the APM/Pixhawk game for a couple of years now and my APM 2.5 is as rock solid as it gets. Auto landings are beyond words, so smooth it boggles the mind. Loiter is absolutely beautiful as is auto mode. Pixhawk on the other hand has been a real challenge, so much so, it is no longer on my quad. That is mainly due to the ppm channel issue but there are other issues as well. Fortunately mine doesn't have the calibration issue some people are experiencing. I am planning on trying again when the ppm issue gets resolved (I read a post by Randy that assures it will be addressed before 3.3 is final). I had an interesting observation this past week and it was the Yuneec Q500+. That is an impressive machine for the money. Look at some of the videos on the tube and you will see a very impressive piece of equipment/camera platform. IMHO it is a very rock solid platform.
So my answer to the question is....please make these reliable. Make them safe. I could careless about lidar or optical flow. I don't really even know what they are. I care about safety and solid reliability. I wonder how many solo's 3dr will replace before they decide it's better to turnout a reliable product then to replace them.
DEVELOPING...
http://dev.dji.com/en/products/flying-platforms/matrice-100/features
http://dev.dji.com/en/products/devices/guidance
What's the point of this post? Hopefully you are not suggesting that DJI firmware is more stable and/or reliable than APM:Copter?
ofcourse not..just pointing it that competitors don't sleep and developing hardware too...about reliability;we will see,they have new N1 controller...also,when you only compare flight controllers there is no doubt Pixhawk is better....but could you say the same if you take average customer who is building his first multi and the one who bought finished product?
hi randy and all other devs,
firstly many thanks for all the hard work you do. the ardupilot development environment is imu on a absolute high end level. also a lot of software projects around ardupilot.
IMO the ardupilot release frequency is to high. i know all the main changes in the last 1,5 Years but with the current arducopter RELEASE concept developers become to much stress because they do bugfixing and developing new code inside one TREE.
I am voting for bugfix releases on a stable tree, currently for example 3.2, and new feature creation in experimental trees.
maybe called
an well tested example concept is the linux kernel tree. see https://www.kernel.org .
imo this give devs the possibilityto work more relaxed because there is less stress and the choice for each dev to develop more what he currently prefer. bugfixing or new feature creation.
the pro here is that also old releases (APM Boards) do not expire. example here is the Linux Kernel 2.6 Tree which also release 2.6 kernel bugfix releases in 2015. see change log here https://www.kernel.org/pub/linux/kernel/v2.6/longterm/v2.6.32/Chang... .
users can decide which version they prefer. they have the choice between stable or new features. this mean also less stress for developers because safety is guaranteed for users.
/g
wolke
The problem is, we don't have enough developers to do something like that.
I'm also waiting for somebody to point out a "bug" in 3.2 that needs fixing (as is Leonard). A lot of what people thinkg of as "bugs" are not bugs, but problems with expectations vs. reality, that are impossible to fix. ie: we cannot make an inertial guidance system work in the presence of high vibrations. We cannot make the system impossible to mis-configure when people don't read the Wiki. We cannot solve hardware problems with software. Etc.
Most of the changes in 3.3 are stability and quality improvements on 3.3. There really is not much new stuff in it.
There are a few new features, for example, Landing Gear. But that feature in no way jeapordizes the stability of the rest of the code. At worst, it will have it's own bugs which mean it doesn't operate properly. Perhaps what needs to be done, is tracking what is new, and what is stable, feature by feature? So people who want 100% reliable firmware, shouldn't use the LG function in 3.3, but wait some period of time.
One of the few really new, really big things in AC3.3, is the inclusion of EKF by default. Maybe somebody is concerned about it's reliability. But the EKF is the fix for many of the problems with DCM. DCM cannot be fixed in any other way. The best solution is to replace it with EKF. So that's what we've done. EKF may not be perfect, but it's better than DCM. So avoiding this "new" feature by staying with AC3.2, is really not doing yourself any favors.
RE: "I'm also waiting for somebody to point out a "bug" in 3.2 that needs fixing"
yes, yes and yes, IMHO it is not the AC code that needs to changed much, but rather the way how AC information (Wiki) is presented. I think of the things which would help people is to integrate wiki into MP -> hover mouse on-top of a parameter name and you get the necessary message along with a link to an example or a wiki article.
You gotta admit, that a lot of the newer AC crowd comes from photo and video crowd who by definition are ARTISTS and not engineers, their though process is totally different from engineers. Many people I tried to sway into using a pixhawk were scared to death of all the available options in MP and the lack of readily available explanation of the functions/settings/parameters inside the program. Many of the full parameters list explanations are not clear to the newcomers who come from dumb Naza.
And another point: get away from using word Wiki.... unfortunately most of the crowd coming from AP is totally convinced that open source = amateur (mostly thanks to own ignorance). I think it is better to be "tolerant" to them and call the wiki something like "AC manual". And of course, try to think why in the wide-stream mentality about Apple = "It just works", while being essentially the same hardware as other manufacturers.
p.s. please fix the Alt Hold drop.... you know even NAZA is able to do it just fine (on any frame)
-
1
-
2
-
3
-
4
-
5
of 20 Next