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
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...
+1
In addition to the above comments I have only one thing to complain about Arduplane and that is the Failsafe behaviour. If you hit a tree and have a FS (set for RTL) the plane will start the propeller as soon as you move it. Therefore I prefer to use the radio for FS. Otherwise I have been flying Arduplane for years and love it. Don't know if Arducopter has the same behaviour.
With Arducopter for helis I have only little experience and although I never had a crash I am not so happy till now. The documentation and MP is lacking in my opinion. I think more people would use it if PID tuning would be easier.
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.
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.
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
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.
The only times I've damaged my gear is when I turn off the Pre-Arm Safety Check as I'm at the site and just want to fly... user error every time. ...one day I'll learn!
This is implemented in AC3.3, using one of the new Aux Switch functions E-stop or Motor Interlock. Both allow you to absolutely stop the motors.
I am sorry, I feel a bit retarded - how do I set it up? where are those modes listed? MP does not have them in the drop down. Should I put mode numbers directly into CH8_opt parameter? What is the option value for that new mode?
-
16
-
17
-
18
-
19
-
20
of 20 Next