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
They're too expensive is why, probably.
I think they do. It's just that there is only so much they can do with countless airframe configs and most likely they are all doing this in their spare time. I think they are awesome. We are just talking about where we need to be a few years from now.
mp
Hi Thomas and Mark,
The first point I would like to make is that I designed most of the flight control and navigation side of Arducopter. As such I feel every crash caused by bugs or poor control performance very personally. I don't need to be financially liable to be motivated to remove all bugs.
The second point is that while this thread is now seven pages long there have not been any bugs or reliability issues highlighted. Can you provide examples of bugs you think we should be fixing?
One of the main reasons Randy and I started this thread was because we were getting many people cluttering up the 3.3 rc thread with "you shouldn't be adding so many features, you should be fixing bugs". However, we have very few issues on the issue list that could be considered bugs and none of them are remotely serious. We wanted to give people a chance to really tell us what bugs need to be fixed. So far all we have got is "you should fix bugs", but no bugs.
To address a couple of points:
Forking and no enhancements. To do this you need fixed hardware and we pretty much have that for APM 2.X. I am not seeing any interest from people to make commits to fix any bugs or take responsibility for the massive amount of testing required before each release.
Copter only, no plane or rover: We share some features like the EKF, similar structure and run on the same hardware interface code. But I don't have to think about rover or plane when working on Arducopter unless we are using a shared library (like logging). Even then things have generally been designed well enough that we can do whatever we need to without consideration of plane or rover.
Countless airframe configs: Actually this doesn't pose an issue at all. Each airframe for copter is a few numbers changed in a matrix. We haven't had to fix anything in that code for years.
Thomas and Mark, I would really appreciate it if you could each give me your top 3 bugs you think we should fix.
Thanks!!
>Forking and no enhancements. To do this you need fixed hardware and we pretty much
>have that for APM 2.X. I am not seeing any interest from people to make commits to fix any
> bugs or take responsibility for the massive amount of testing required before each release.
Do you suggest any APM based build should be operating on 2.x firmware only?
It is really a sore topic. It is understood that new features and functionality may not be available on the older platform, but when we talk about safety features, an ability to do a kill switch and shutdown for motors and all this is coming to 3.3 _only_ and 3.3 is not going to run on APM - what all the people who have APM powered builds are expected to do?
It is directly the topic related to safety and reliability as it is. If it is a general statement - any APM build will never be reliable and safe as it will never have an updated firmware to address any existing issues - then it is has to be formalized and stated as it is.
As of an example of 'bug' - inability to shut down craft`s props when it crashes and destroys property around itself is a bug. How am I expected to fix it on my APM powered build?
By removing APM and installing PX4 with 3.3 only? Is that an official position?
Hi Paul Atkin,
I realise that pilots that only fly in Alt Hold and Loiter may not know this but you can shut down the motors using Stabilize and zero throttle if you set mot-spin-when-armed off.
So if you believe this is an important issue then you have all you need to fix your problem. That combined with a buzzer to warn of motor start up and you are as safe as you ever were.
As for you question: "How am I expected to fix it on my APM powered build?"
This is easy. You add kill switch code to the APM code base. You either do it very efficiently or go through the code to save enough memory to make it fit. You then spend a few weeks flight testing your code. Then you get 20 or 30 other APM users to flight test your code. You fix any problems you find then we can do a new release with the features added.
This is time consuming but I can see you think it is important.
And just to clarify. A bug is when the code doesn't work as it is intended to do. Fixing a bug is when you make the code work the way it is intended. Adding a feature is when you make the code do something new that it didn't do before.
that is exactly how we treat code on boiler and turbine control systems in power plants. The failure of a boiler or turbine due to the protections provided by the code can cost human lives and hundreds of millions of dollars.
I know we're just talking about drones but just commenting on Mr. Butler's comments. I would love to see APM code take over the commercial market but it won't until we get to that type of reliability. The hard part is what someone above posted. APM code has to be compatible with so many different types of bird configurations that 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.
Just some food for thought.
mp
Safety: Total flight time counter of the system and maintenence threshold with warning message. The total flight time accumulated should be displayed via MAV like any other parameter.
Perhaps this is something that follows cycles. For instance the move to 3.2 was a big one and involved many new features and improvments. And these are necesary, to compete, to provide long required safety features, stability etc.
But once a major move has been made, time should be taken out to clean up all the details. For instance, poshold was a great new feature, but other than making life "somewhat easier for newbies", it's practically useless for serious photographers. It's twitchy. Well that's just one. We are all content with the new features so we "get used" to slight defects. It's understandable that things are "never?" going to be perfect. But while it's fine to brush over the slight imperfections initially to move ahead, we shouldn´t leave them there forever, carrying them over into each new release.
If we use poshold as an example, as I said its not the only one, we kind of shoot ourselves in the foot. This was a feature that went directly at the competition. Loiter didn't compete for photography. So now we have it. But I know at least one professional in arial photography that won't use 3DR because of the poshold / loiter issue.
I of course agree with most here, that the developers are doing an incredible job. But since the question was raised, I understand that you see this as an opportunity to "see" a larger vision of what is needed in terms of development.
Right now is a good time to put a slight hold on advancement and clean up the great work that we've got to this point. It's really not a lot, but it would make a lot of difference... to have a good clean, solid unbeatable product.
Thanks for the question!
+1
Maybe one thing to consider is alternate releases - features vs bugfix/stability
++
yes, that would be a great improvement.
Bugfixing and increasing the reliability of AC 3.2 (For APM and PX4)
New Features for PX4-Platforms with a split to AC 4.0.
@Jason,
yes, thats wright! But in the past there were some major problems with the official releases too!
So a rock-solid release for all current platforms which is maintained during the development of AC 4.X would be very nice.
-
10
-
11
-
12
-
13
-
14
of 20 Next