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
I got an Octocopter off the ground with 3 motors disabled. But barely. With 2 disable, it flew well, of course, the two motors were strategically selected. :)
With only a single motor disabled, you would be hard-pressed to know anything was wrong. This was a moderately loaded copter, however, hover throttle around 50%.
Randy, you already know what my answer would be: safety + bug fixes...and they go hand-in-hand hence our weird hybrid that has some things dating back to v2.6). Can't do one vs. the other if you want consistency and predictability when something unexpectedly happens in the air.
I think the team's current 3.2+ feature set is future proofed for the coming year from my point of view. One thing to keep in mind is if you proceed with bug fixes as top priority--APM2.x support will likely be impossible--assuming that typical optimization (usually a result of bug fixes) typically creates even tighter coupling to the hardware [e.g. the newer 32-bit boards].
Another question you can ask is how big of a monolith do you want the APM core (not necessarily ./libraries) to grow? Same challenge the linux kernel, mozilla, and other F/OSS projects...
It would be great to have some new people come forward and offer to carry on supporting the APM series of boards.
I'd much prefer to see bug fixes and safety features to take priority over new features. I'd be happier still if there was just a copter build, ideally with all bloat removed, even possibly waypoints that can be run with pure reliability and safety in mind, an Arducopter Light if you like...
Do you know what the "flip of death" means ?
Ask some DJI Wookong and A2 users they will tell you and they spend a lot of money and probably still waiting for update.
As all new technologies they have to grow, probably in 2 or 3 years drones will be much reliable then today.
The guys here are doing a lot of very good things and this all in her spare time. The quality in organisation and deployment is very good,
For those people want reliable Software simple stay on the released version and do not update to beta. As simple as that it is.
After some years of experience with ArduCopter, I would characterize the reliability aspect of ArduCopter as good, while the functionality aspect is outstanding (IMHO).
When looking at my past crashes caused by ArduPilot (about 10 or so in about 200h of flying, not including any pilot-induced stuff), these fall into two categories:
1. Failure of components, especially drives
A nice long term safety goal would be to detect faulty drives or other components and to do the best to achieve a safe (or at least as soft as possible) landing. ArduPilot is here far from the point that is theoretically possible with a given number/layout of drives. That would require that ArduPilot is able to detect drive failures reliably, which probably needs real two way communication between ESC and ArduPilot (we already have that with UAVCAN). The next step would be to give up control functions in a prioritized manner, e.g. when necessary to reduce the sink rate. Currently even an X8 crashes rather hard when a single drive has failed, due to the fact that ArduCopter seems to prevent uncontrolled yawing at any cost and therefore reduces throttle way to far instead of allowing a certain amount of yawing.
2. GCS-related crashes, e.g. due to a GCS that had trouble with number format handling and sent a P, I or D value that was 1000 times to large.
Unfortunately, these crashes seem to be a thing that is repeating again and again, with different GCSes involved. Of course it is primarily a fault of the GCS used that allow bogous user input, but I think ArduPilot could do more parameter range checking and/or cross-parameter checking than it currently does. Rejecting obviously wrong parameter values would be a huge safety/reliability improvement IMHO.
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 tried to make a venn diagram but it didn't turn out to well.
anywhoo i think the focus should be, in this order:
safety features
bug fixes
new functionalilty
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.
Rob,
I never said the platform was unreliable. I just made a remark to Thomas Butlers reply. I think the PH/Ardu platform is way more reliable than I would have ever expected. My main purpose in the hobby is finding the most reliable combination of equipment/code I can find and I have found it. I have no aspirations to be a commercial drone operator. It's just something I like to do besides my day job, golf, gun range and fishing. I don't sit in front of Televisions very often:)
That's why I don't rush to try every single release. Once I see what I perceive to be a reliable combination I stick with the status quo and just keep flying over and over to see if it's as reliable as I perceive. Just something I like to do.
That being said I really should start testing the latest release candidates and contribute more to the developers. I will install the latest RC this week and start testing and providing feedback to Randy.
thanx
mp
-
7
-
8
-
9
-
10
-
11
of 20 Next