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
Hi Holger,
The X8 doesn't come down because it has prioritised yaw over throttle response. The problem is that as soon as an X8 looses a motor it must fly on the lift of only 4 props. This means that if you load the copter up such that it can't hover on half it's motors then it will come down. This is because it does prioritise roll and pitch over throttle and this is why it doesn't flip (and come down much faster).
I also take offence to the statement. As a former automotive engineer, I fully understand liability. Probably to the degree that boiler engineers would have nightmares about.
Until you've been involved in a lawsuit because a prison van that's been a stable design for 20 years, with 200,000 miles on the odometer, which is inadequately maintained by it's owner, has a driveshaft fail, causing a crash where the prisoners who are shackled to their seats cannot escape and burn to death... and have to defend that case in court as the OEM... you have no idea how far liability can extend.
The very simple fact is this. It's not that we aren't concerned about safety, reliability, and liability. The problem is that there are harsh economic realities at play.
You obviously are not willing to pay the $50,000+ per unit that it would cost to purchase a system that (maybe) delivers the safety and reliability you want. If you were... then you would, as there are several systems out there advertising that.
The same goes for APM software. Nobody makes any money on APM-class hardware anymore. The Chinese cloners ate the bottom out of that market. They certainly aren't helping to write the code. So who's going to? You certainly aren't! We'd like nothing more than for somebody to fork the the APM code, and keep it going. Those of us who put food on the table working on this, have to concentrate on work that people are interested in paying for.
So, our efforts are currently dedicated to developing the code for modern processors. And we do so with an absolute focus on safety and reliability. But at the same time as there are economic constraints, we also have time constraints. If we stuck to the NASA timescale, we'd still be working with the original ArduPilot hardware, not even Mega. And I daresay, we'd still be less reliable anyway, as that processor is not capable of doing kalman filtering, which leads to a much more reliable navigation system than the old DCM.
Fact is again, if you really wanted what you say you want, you'd be using MultiWii or something, very simple code, running on an old 8-bit processor. But you don't.
You have 3 choices basically. Cheap, and very basic, and reportedly reliable MultiWii code. Or, full-featured, commercial autopilot, supposedly very reliable (never proven though as not sold in enough numbers), at $50k+. Or, you choose us, affordable and full-featured. But then complain that we're not reliable... although you have done *nothing* to either improve liability, or even prove your claim that we're *less* reliable than anything else.
Frankly, I do not accept the proposition that Arducopter is not reliable. I think it is very reliable. We never have control lock-outs like DJI. And the closed source guys don't sell enough units for anybody to rationally claim they have a lower failure rate. And then compared to Naze32, MultiWii, etc. of course nobody could claim that the features they DON'T HAVE are more more reliable than ours.
Mark, my response here was really directed at Thomas not you.
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.
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.
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.
Hi Richard,
It isn't the GPS that needs to be elevated, it is the magnetic compass. The Phantom gets around this by mounting the magnetic compass at the bottom of the landing gear.
I've put an ext compass with APM, my gps was on an arm working well but when I put the compass on a mast, the gps stop fixing sats (0 sats) , I moved the gps upper the compass and get sats again, test some times and always the same results ¿It's possible that the compass disturbs the gps like that?
-
7
-
8
-
9
-
10
-
11
of 18 Next