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
+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.
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?
Hi Paul,
That's value 31, I have it set on Channel 12 so CH12_OPT = 31
Tried this while landed, and assigned a springbased switch to the function..
Works great, but while I was thinking about it, suppose you'll need to drop out of the way fast, I.e. Down from 100m pull the switch for (0.5 sec), so no disarm yet, and it starts dropping fast...Will it recover after falling a 20 or 30 meters ?
Will EKF and all the other flight controlling functions remain active, so the copter can get out of the fall by adding a lot of throttle ?
Obviously the switch is not active any longer..
Just wondering...
-
14
-
15
-
16
-
17
-
18
of 18 Next