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
My 2 cents,
Great thread Randy, an important issue for sure.
My basic though is that between main releases Betas, new features (including new safety features) should initially take priority through the first few RCs.
Then fixes for bugs created by the new features and finally thorough debugging through multiple RC's before the the next main release.
Further releases that are in Main not beta should focus on bug fixes not adding any new features or capabilities unless some bug is so bad it demands it.
I think this is pretty much what you are doing now and it seems to be working really well.
By the time you actually release it for general use, current experience is it is working really well.
But I know it isn't perfect, and perhaps a bit more effort "perfecting" each main release would result in a bit more solid product.
We are now graduating from hobby to pro and commercial use and glitches are less well tolerated.
Best regards,
Gary
One year ago as i went to my favorite hobby shop copter and drones were more exotic things, since then the market is grown so fast. Today newcomer and big brands are sitting face to face giving the enthusiast broad spectrum of products and feature,
I'm thinking you guys are doing things your way and that is what it's all about. All developers know that bugfree software will never be reality. It's all about how to handle and react on bugs.
There is simple too much potential in the new hardwares like Pixhawk which make Developers start dreaming like a child in the candy shop ;)
Since 3.x it seems to me that release changes and deployments are well structured and organized. I would simply go this way further without changes.
I think only, how long will it go well to have only one firmware for x applications. It would be easier if you could install a base firmware and then add features for Copter, Plan... almost like apps.
I'm using only the copter firmware but this on is getting better and better and seen this way i'm ok with it.
I also agree the priority list is correct. As long as it is not so focused on bug fixes or safety features that new features is totally ignored.
Currently if you look at the plethora of commercially available UAV's, the majority of them from small companies are running Ardupilot. I believe this is for a few reasons, but, reliability, cost, and features are clearly in the top of that priority list. As with any open source project, it is not as simple to operate as some of the closed source options, but, once the basics are understood APM is one of the best autopilot systems on the market available today. If you follow the code development on github, it is truly amazing the amount of work that goes into APM from the Devs and the development from the 130+ contributors. Almost daily there is new pull requests and hundreds of changes by the devs.
As commercial drones continue to open up, I see Ardupilot continuing to grow as the primary controller choice for commercial use, so, reliability will be absolutely critical.
With that being said, I agree with the previous commentator that there is room for improvement in the camera control and Geo-tagging and would love to see a major focus to perfect these features as so many are using ardupilot for 3D Mapping and agricultural use.
Randy,
Thanks for asking, I think that the order proposed is the right to have a reliable software.
Thanks to the whole team.
I've come across some issues with the way mapping is done when there is a hill in between the two 'end' waypoints of a strip, which leads to not enough overlap between images, and holes in the orthophoto. I plan my mapping missions with verify height checked, and this adjusts the height of the end waypoints as it should if they vary from the launch altitude, but doesn't take into account higher terrain in the middle of a leg of a mission, even though this elevation data is available via google earth/mission planner. Is this the sort of thing to raise here?
GlennM,
So we'd call that feature "Terrain Following" and it's pretty much guaranteed to be in AC3.4. The to-do item for it is here.
Actually, I don't know if Terrain Following will solve his problem if I understand what he's saying, and what I think TF does, is correct.
He's less concerned about smacking into the hill, and more concerned that the hill "stretches" the surface area of the ground, and therefore the mapping lines must actually be run tighter in order to guarantee full coverage.
I Bet that those values would have a great emphasis on reliability,then closely followed by advancements and upgrades.
Hi Randy,
I would say that your order is great, but its also a matter of balancing.
From my experience there is always priority tension between fixes and new deliverable's.
Recommend to define version cadence where balancing changes so will have:
Finally as eventually lot of the code can easily identified as safety risk, we might need to invest more in auto regression and testings.
I'll echo Andy's point.
My greatest frustrations have not been the crashes, repairs, costs, etc, but the sheer, hair-pulling frustration of not knowing what's wrong or what to do next.
The number of times I've been on the verge of (wrongly, wrongly) assuming I've 'fried the board' and need to replace it is a bit scary.
In the end, for me, it's always turned out to be a case of 'get out of the APM's way, and it does what it's supposed to' (I'm in growing awe, actually, of the little guy (2.0)).
But, then again, I have no hair left.
The project is a marvel - full kudos - but we're mostly not of developer capability. If it's obvious that something is bound to end badly (Rob's point), then should it be possible? As the project becomes more complex, the number of things we have to understand to avoid 'obvious user error' expands with it (?). Eventually, even smart, conscientious people (who didn't design the system) will struggle.
So, option # 4 - more diagnostic capabilities to help the user (or does this constitute an example of #2 - safety features?).
On a more specific note, I'm not a fan of removing the comments at the bottom of the pages of the manual. Why was that done? They were previously very helpful - sometimes more than the explanations in the manual - with alerting users about things to watch out for or things the manual didn't cover.
George
-
13
-
14
-
15
-
16
-
17
of 20 Next