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!

Views: 9573

Reply to This

Replies to This Discussion

I'm going to answer the basic question with a 'yes'. But realistically only you and the other developers can answer that question as we don't know how many resources are available or what the goals are. 

You have the order correct. You  and the other Developers have done a stellar job with the code,  for which I am very grateful.

 Bug fixes is absolutely number 1. We need solid code that insures that only a major component, mechanical failure, or pilot failure will be the cause of a crash.  I have never had a software failure on my Futaba radio gear- that should be the goal of APM code as well.  I know that with all the new electronics constantly becoming available this is a difficult goal.

 Safety goes hand-in-hand with that.  Pre flight warnings or GCS warnings go a long way to prevent or minimize crashes.  These devices are reaching a point that even with a minor IMU component failure; a fall-back, or safe mode should kick in to prevent injury from a falling out-of-control machine.  Let's expand on that.

 New features are nice, but we cannot have everything for all potential users. I would like to see all the gear that 3DR sell work as reliably as a servo, plug and play. New features are great, but new features coming once or twice a year is enough.  

 As a Open Source project, users are free to develop their own specialized code, but I don't wish to loose reliability to accommodate a small user group who want the Developers to be their (free) software engineers.  Commercial use is a "horse of a different color". I can't imagine that future commercial use won't require a closed system at some point to be compliant with the regulators and rules that will follow.  For now lets try to insure the hobbyist can fly safely. Dumb thumbs not withstanding!

 Thanks again for all the amazing work.

 Joe

I feel that the DEVS have worked extremely hard to develop innovative code for the Pixhawk which requires more and more work to keep stable.  I worry that there could be burn out with them and wonder if it's a good idea to halt for the interim new ideas in order to iron out the existing code?  I know there are many folks out there who have projects and products depending on the next generation of code to support their product but at what point have the DIY community placed so much responsibility that we are possibly seeing more and more little issues with the code? 

 

Randy,  I think your priorities are good, and would recommend stopping all new ideas that have yet to be implemented in order to finish what's on your DEV's plate and to ensure a rock solid code for safety sake.  You guys have made huge strides thus far, and a break to clean things up (in my opinion) would be a good idea. 

Actually, Randy and I have both been very happy with the Bugs and Safety features side of things. We did a big rewrite called the Onion that made it much easier to implement new ideas without compromising the existing flight code.

I would say our biggest job on our todo list is to clean up some of the code that has been a part of arducopter since the beginning. There are things like the stability patch that are much more complicated than they need to be, making it hard to make small improvements without having to spend a long time getting the code clear in our head again.

The main motivation of this thread is to find out from people where they think there are reliability issues. Over the last issue the general attitude of the community when from "I crashed, what bug caused it" to "I crashed, what did I do wrong" or "I crashed, what broke on my copter to cause it". 

So this thread isn't to get the community to understand that we have reliability and safety work to do. It is more, we are running out of reliability and safety work to do, have you got any suggestions?

A nice place to be!!!

Randy,

I think you have the order of priorities proper. 

() bug fixes

() Safety features

() other new features

My professional background for the last 25 years causes me to never upgrade firmware that is stable unless it has a "new" feature that I absolutely have to have and then the testing that goes on to implement is arduous. My perspective comes from working with turbine and boiler control systems in power plants where safety and reliability trump any "feature". These highly complex control system are no different than the Pixhawk. Inputs and outputs with oodles of high speed, deterministic algorithms in between.

My #1 priority in this hobby is "how many successful, uneventful consecutive flights do I have on a bird" except for pilot errors:) I have an Iris/Iris+ that has gone past the 200 count right now. Most of those flights were on 3.1.4 and the last 25% were on 3.2. I haven been fortunate to not have hardware failures. IMO reliability trumps all.

Every time I fly your code I am amazed at what the group has done not just in code but in the Pixhawk design as well. I understand that new features have to keep up with the competition. i think you guys have found the balance.

mp

For me reliability is far more important than new features. For a multirotor doing real work, reliability is prime.

Here is another vote for reliability. I am a victim of the Fly-away syndrome and would very much like to prevent these types of occurrences in the future.

Many many thanks for all who have added to the development. Great work.

Reliability Bug - Shutdown.  The only times I have ever damaged any of my gear is when I couldn't shut the props down once the MR was already on the ground.

Hi Randy,

I also would like to see the priority on bug fixes, safety features, and after that adding new features.. And if I see how many updates you guys do make on the code I am getting more impressed every day about you guys managing this code set.

Maybe a list of potential idea's you guys have per specialty, for instance I know Leonard has some great ideas on tuning, I.e not only on the roll, pitch and yaw but also on climb, and reducing altitude which I do share on the safety side...

Repositioning during the tune with a controllable radius and (height) and auto reposition would be excellent, and I know Marco requested this already...

I don't think we should stop innovation, because some of the idea's I see on DiYdrones are brilliant and it will keep the PixHawk platform the most innovative.

On the safety and flyaway side of things I would say that the fences are default on, (500m radius, 120m height or something like that) when new firmware will be released, obviously the more expirenced should be able to switch that off on large Auto trips, but this way you'll prevent flyaways, and thus make everything more reliable.

Something like automatically setting the fence radius just a little bit further away than the largest distance you have set in your mission plan when enabling Auto trajects.

Monitoring the battery cells individually as well as the total, so the controller will be able to detect a bad cell before the copter drops out of the sky...

Preset the voltage max and min settings based on the number of cells, and read that from the connected and fully charged battery, so people can't make the mistake to set the low voltage too low. Again tune able by the more experienced, but default during new firmware installs.
And I do know you need a new power module for that...

Also in some cases a better explanation on the Copter parameters might be very useful, and I mean a more in depth explanation (or a link where we can find that) because most of this excellent stuff is in the heads of you and the rest of the developers.

And at last thanks to all developers for making this codebase such an success!

Erik

No. I think too much focus on bugs can hamper the program.  

I don't know of a complex system that is without bugs.  The quest to eliminate all the bugs might starve other avenues of development and might make Copter a very robust yet obsolete system.  

Balance reliability and functionality.   I think that is a good approach.

You need all three and IMO this can't be achieved with a caravan approach to releases - you need to overlap releases more so that further bug fixes can be incorporated into released versions.

One of the issues here is that everone's rig is different so it needs a lot of group testing to iron out all possible issues - this takes time and everytime you do a new release you need to do it all over again.

I would add a 4th option after bug fixes - in-flight problem diagnosis. Anything that allows you to easily determine whether some is a bug or not helps with all the others.

Very interesting question but challenging to conclude on a route to follow afterwards, because you 'll get as many different opinions than there are number of people, with such an open question. For information, I worked once in a joint project with a sociological team in a Belgian University specialised in enquiries about high tech topics. They showed that it was impossible to analyze answers to open questions for more than 100 people... So I'd better be also answering in the first 100 people in this thread lol.

Ok back to the topic.

All I read in forums, hear from my customers and analyze by myself lead to a more complex answer than just a priority classification between these three aspects : bug, safety, new features. I believe that sub-topics in each of these three categories can be pointed out as priorities. So I cut the cake in the other direction.

I would thus propose to reformulate the question as follows : What would be the sub-topics that are the most out-of-balance (i.e. that need the most attention from the DEVs for correction and improvement) in each of the three themes ?

(and I would add they the answers should ideally be fixable in software for the DEVs to be able to do something about it. Unfortunately there are , in my opnion, more points to adress at hardware level of the autopilot than points that should be adressed in software)

Real quick now what's my answer :

-In the bug fix theme: for me all points are autopilot hardware issues : barometer drift, I2C unstability, non working CAN bus, powering weaknesses/lack of reliability, DF13 connectors, lack of remote camera triggering chip & interfaces, IMU vibrations, Processing/processor autopilot redundancy in case of "hanging" hardware or hardware crash, etc...

-In the safety theme : fly-away total avoidance when we can assume there is no mechanical failure.

-In the "new feature" theme : so far APM software has really focused on "flying it right". As a consequence APM software (also in comparison to other autopilots than APM) is really backward and late on a basic core functionality for a drone : triggering and controlling cameras reliably (with programming/scripting/intelligent functions). With timestamps, positionning and attitude data. Today we have to fart and fiddle around just to geotag images, and that is only if we succeed to trigger photos at the right moment, at the right place, every time, reliably and for thousands of waypoints. Also current camera triggering setup does  not allow to test on the bench to ensure it is working before going on the field.

On the same subject to support the main camera triggering interfaces of the main brands (Sony, Canon, ...) would be nice : Multiport, LANC, PtP, etc...

Reply to Discussion

RSS

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service