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
Mark, my response here was really directed at Thomas not you.
Understood. No offense taken. Craig got pretty upset too. I hope I explained myself properly.
If you are going to say my dev team does not understand Mission Critical software you're going to get an ear full from me because these guys go above and beyond to make this system robust and capable. Every person here is doing their best and their best creates excellence!
It's always a delicate balance of need verses, want. At the end of the day no decision made, is going to satisfy everyone. I think the current system, where both are developed at the same time best serves the masses, however, perhaps something along the lines of dual releases, such as, a current stable release, that deals only with known bug fixes and stability issues, and then a user chosen, upgrade, to added features. There has been many times that I have been happy with my tuning and over all performance, and been encoraged, to update, due to real safety concerns under the version I was flying. However, I have no choice, in the new package, so I'm left with a decision to take a risk under my current "stable" release, and stay with it. Or , take on new features, many that may not pertain to my flight style or need. I don't know what that would entail, or even if it's at all possible. Safety always should come first. But innovation is what draws people to open source and arducopter. Thanks for the excellent job you all do.
Gentlemen, I spent 26 years designing mission critical software for robots before I started working on the ArduPilot project. This is not a group of amateurs. There are many other professional involved in this project beside me.
Despite the vast experience you claim, you sound like you are unfamiliar with this other open source project that is used for Mission Critical systems called Linux. It runs something like 95% of the computers on the planet and it might be worth spending a bit of time to learn about it before making some silly statement about open source not being reliable.
You are correct thought, we have no liability in the use of our software http://firmware.diydrones.com/
This program is distributed in the hope that it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
or FITNESS FOR A PARTICULAR PURPOSE.
But liability is not what motivates us.
I'm curious about your statement:
>>>it's almost impossible to get to the 99.9x reliability rating unless there is a variant of the codes designed for a specific air frame.
You're really off base with that statement. How did you become so misinformed?
If either one of you is actually a developer then you would be doing us and yourselves a big favor to put your time where your mouth is and have a look at our issues list:
https://github.com/diydrones/ardupilot/issues
and start tackling some of the items that are posted there.
Right now when I look on github, I don't see a single pull request from either one of you so come on and jump in. You might want to try and be part of the solution.
When I look around, I don't see a single pull request from either one of you so I suggest you have a thing or two to learn about development.
I sincerely apologize If I offended anyone. I'll explain the statement below and bow out. I will also take you up on the getting involved in solutions. I too have been involved in software development since the 80's( for industrial real time applications). Your chastisement was obviously in frustration and I apologize for driving you to that. I have nothing but respect for what you guys do.
>>>it's almost impossible to get to the 99.9x reliability rating unless there is a variant of the codes designed for a specific air frame.
One example would be a turbine control and protection system (GE, Siemens, Woodward, etc) running a specific version of firmware with a specific version of hardware in order to get what we call a 99.9x reliability rating which usually involves TMR (trip modular redundant) systems with triple redundant processors, I/O modules and instrumentation. Some system are even rated at 99.99% reliability factor meaning that it's virtually impossible to lose control and protection integrity due to a system failure or hiccup.
That 99.9x reliability rating can only be achieved with specific versions of firmware and hardware. If the code changes or any of the hardware in any way then you no longer have the 99.9x rating until you complete many months of rigorous testing to prove that the reliability factor has been achieved with the new combination of code and hardware.
My point was that you could probably never get there (99.9x) when code like arducopter has to work with so many different airframes and instrumentation (sensors like GPS, baro, ESC's, etc.)
I personally find it utterly amazing that you guys have gotten where you are. I have an IRIS/IRIS+ with over 200 event free flights and many of those (>50%) are auto flights with pre-programmed missions. On top of that you have to deal with all the users who really have no clue how the FC system works and try to create traps and recoveries for their mistakes.
Compared to DJI I think you are an order of magnitude ahead of them since they can control their environment and have code and hardware designed and tested for only one airframe and instrument set.
That is the explanation of my remark. Again, I apologize for the way it came across.
mp
Apology accepted!
Mark, I think what you need to understand is that wa are already at that 99.9999% success rate and you are mistaken about needing specific firmware for specific hardware.
>>>That 99.9x reliability rating can only be achieved with specific versions of firmware and hardware.
>>>My point was that you could probably never get there (99.9x) when code like arducopter has to work with so many different airframes and instrumentation (sensors like GPS, baro, ESC's, etc.)
At a code level, ArduPilot is tested and demonstrated to work with all of the possible hardware options that we support http://autotest.diydrones.com/
If a frame has issues or the wiring is bad or the system noise is bad those no amount of code is going to fix those issues. ie.e they are not code related issues.
Agreed Craig. Same with the systems I deal with. If the turbine starts throwing blades and killing people from mechanical stress, it's not a control system issue. All the control system can do is shut the machine down(i.e. remove the horsepower).
You guys are truly awesome. Please keep up the good work.
mp
re->>>it's almost impossible to get to the 99.9x reliability rating unless there is a variant of the codes designed for a specific air frame.
-
8
-
9
-
10
-
11
-
12
of 20 Next