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
I really never crash my copters for a firm bug, always for a silly user bug ;) ; I only have firm problems with the false positive Land but I was advertise for Randy comments so test near the floor and attend to switch to stab (now solved) but sometimes we are desoriented and many of us only can find answers in this forum, perhaps I coudn't fly my copter like now if I didn't have this forum and all the comments, good, regular and bad ones. It's a great help for gliches the Tower, yesterday I fly my plane and the tablet advertise me GPS glitches so I abort to fly missions, It's a great tool for that things, Don't worry Rob we apreciate your invaluable work :D........and patience .
I'm not the most authorized to give opinion but I like the way that dev go, I think's that order is the priority but, we know that sometimes is not easy to find easily a bug so we value a lot when the bug is recognized and list in red to be carefully; my little cents to make this better is, perhaps when harware is going to update, there stop a little with new features ej a month, only fixes bugs from that board and help people to have it working well; I suffer specially with my plane, 3 years and two crashes trying to fly well and one day I read that my board, that never works well, was out, it's really frustrating :( , finally Tridge and a friend Lere helps me to tune better and I'm happy now; with copter I had the pulsates problem in one copter, a lot of hardware problems but can resolve too. Sorry my bad english, not shure if the idea is understanded.
Maybe project should define one milestone, that will have limited (not expandable) set of features, that will be debugged and _well documented_.
I mean, assembling copter and flashing firmware IS fun, but I guess a lot of people want to fly after all...
Why won't create set of software that just works?!
I mean, set: Mission planner v.1.4 final, ArduCopter v.3.4 final. Software that will not grow "wider" but become a platform for future success.
Right now, the only stable platform is APM. Yes, you have to go through headache in the beginning, but when you set it up, it just works.
Hi Marco,
What part of Arducopter doesn't "Just work". I find it all the problems happen with the mechanical setup. Then I go to mission planner and move top to bottom through the initial setup, test flight to set hover throttle, then I do an auto tune. I rarely have anything other than a perfectly flying copter after that.
Where do you find you get headaches?
Ok, it's dire offtopic, but:
I want ArduCopter on PX4 hardware, plus I want to use MK i2c ESCs and PX4FLOW sensor.
All the functionality is supported by ArduCopter (AC), but when you try to put it together you get headache.
But I have to mention, that Mission planner + AC firmware work MUCH more stable than native PX4 stack + Qgroundcontrol.
Marco I am the lead control dev on arducopter and I don't know what you mean by the Alt Hold problem. Exactly what problem are you talking about?
And just a polite heads up, telling someone how to do a keyword search is very condescending.
I am sorry if that sound offensive, please accept my apologizes. I just meant that there are several themes on topic of AltHold and loiter in 3.2.1 firmware.
This one topic here that I participated and there are several with same subject.
In my case I had to downgrade to 3.2 to have stable flight.
Thanks Marco, I will have a look.
It is pleasure to meet you.
If you will need extra information or tests made, feel free to contact me. I will be glad to help.
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...
-
14
-
15
-
16
-
17
-
18
of 18 Next