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
You guys are doing great job! I would simply say if while developing the next beta and you fix a known issue no matter how minor please take the time to go back to the last stable version and implement the fix with a note in red [ like I have seen you do sometimes ] to indicate people flying that version might want to re-flash for an even more stable version. Maybe even have a place to enter your email if you wish to get updated info if there has been a change to that FW.
Might want to have a larger section in the wiki [ but it's WAY better these days! ] about troubleshooting that could go hand in hand with error messages saying things like, " Please see compass troubleshooting" or "Please check esc low voltage troubleshooting " Instead of a more technical description of the error that might not be as clear to the user what the issue is. That might reduce the amount of posts looking for answers. If you haven't noticed it can get a little cluttered :]
But I salute you all developing this my quad flies amazingly SMOOTH yet aggressive when wanted. Very very good flight control FW!
I still contend that reliability is everything becuase a system with wonderful state of the art bells and whistles that crashes all the time is not useful but...
I have been pondering this question further and reading the responses. One of the major problems is that of separating software bugs, hardware bugs and operator error. In monitoring the forums this takes up a lot of time and effort. Unfortunately most of us are not in the market for mil-spec equipment. That leaves us with lowest cost competition with probably a lot of cost cutting and seconds. Just the reality. So it is hard to have a discussion about reliability of software without dealing with the hardware problems. 3DR is in the position of influencing the hardware. The whole of the opensource apm/pix hardware world is not controllable but if 3DR were to consider making an equavalent of a "Tuned propulsion system" where the FC, Rec, ESC's were all designed to go and work together. Then maybe the third party folks would be copying it. Users would certainly be attracted if it improved their chances of a successful build. Think about eliminating as much of the hardware problem from the equation to make it easier to separate the issues. Lets get rid of Dupont connectors in favor of a connector that can't be installed upside down! Lets get rid of bullet connectors in favor of a locking connector. Define the system and it's connectors from one end to the other.
Work in everyway to limit the operator error by having levels. DJI gets by because they don't offer options. But instead offer basic, advanced, expert views to reduce the bad setups.
What about a blackbox to record flight data and off-load this from the fc proc. Full logging all the time with all the memory needed and any user that buys it and plugs it in can have his build troubleshot without having to go throught the time and efffort to explain how to turn on the logging, how to download it and analyse it. No cards to install, self-contained. Plug it into the FC, after flight plug it onto the PC an APP gets the logs, transfers them into a database for query and analysis. User doesn't have to know anything about it. But if they want help they need to buy it an plug it in. Dev's can go look at the historical data, captured the same way every time.
Thanks for making this project available to common folks like myself. A few brilliant people dedicated to this open source project are changing peoples lives all over the world. Sure it is not world peace but it is very important to me and I am grateful to the dev team.
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
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.
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
-
11
-
12
-
13
-
14
-
15
of 18 Next