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
Hi all, i'm the "APM:Copter" lead tester.
In recent years the evolution of our code has made great strides, the implementation of new functions and the transition to 32-bit board has definitely increased the safety of our code, however that the nature of things can not be bugs free, is impossible, too many lines of code, it can not be perfect.
I believe that the order entered by Randy in the first post is the correct one, better to focus primarily on potential problems to try to solve them.
The important thing is not to endanger people and our aircraft, and I think in this direction we got excellent results.
An absolute priority: we must try to make more understandable the logs, that is another priority, since many have difficulty interpreting them, and are in my opinion the added value of APM: Copter.
An important fact: except for the famous "land detector" problem are more than two years that i haven't a crash during testing phase, so I think that unfortunately most of the problems that some have are tied to hardware faults or incorrect setup.
Hi Marco,
First of all let me thank you for all the effort you guys (+devs) are doing to get a safe as possible flying machine.
What I noticed in some of the replies here that they're talking about "incorrect setup".
Do you mean, setting up the parameters or setting up the copters hardware? If you crash so little, please share whatever setup you’re using. Even a small one can teach us a lot.
I personally learned from this, even if it’s so small: Specs of my "Kamikaze Hexa v2" ("DJI F550" clone) on YouTube: https://www.youtube.com/watch?v=sRhr1YdekbY
At my age (66 and English not being my native language) it’s sometimes rather difficult to find the right spot and explanations on why my copter crashed. My # 1 on Randy’s list is a safe and reliable copter!
So my suggestion/question is: Is it doable to make some kind of wiki? A place where you gather the cause of a crash explaining this on the basis of the log. Perhaps expanding this part: http://copter.ardupilot.com/wiki/common-downloading-and-analyzing-d... (or a separate chapter)
Best regards and keep up the excelent work you guys are doing on this.
Paul
Hi Paul, thanks for your comment.
What I meant is that the tuning and the search for potential problems is the hardest part.
I hope that Leonard consider my proposal to create a log more understandable to users, because it's the thing that really differs APM from other system like DJI.
Even "3DR Solo" i think that will have this possibility, but i don't know because i'm not in his group of development and testing, and i don't know this product.
Hi Marco,
I totally agree that the code has made huge strides.
I also agree that bugs free code is very unlikely with the huge quantity of it that we have.
And even if not a direct bug, misunderstandings on the part of the user can have a similar effect.
Our code at it's current point of evolution does a lot and provides an incredible number of capabilities and options.
And, as has been observed, marginal understanding of hardware combined with marginal hardware itself is probably more often the root of problems freely blamed on firmware.
I use first class hardware and have been flying crash free for over a year now and although I have an occasional "glitch", my skill level has permitted a rapid recovery.
In my opinion the most important thing is to teach people to actually learn to fly these things and to be able to stick them back in stabilize mode instantly to be able to recover from anything that might happen.
This is a lot like practicing approaches and landings in RC fixed wing, you really need to learn how to save your own A$$.
A lot better than watching your copter take off to some inadvertently entered GPS point on the other side of the planet while you stand there helplessly wondering what to do.
After learning how to actually fly the next thing you need to do is progress slowly and methodically to increasingly more complex automated and semi automated flight procedures.
This simple approach would save a lot of thousands of dollars (and quite possibly some really unpleasant communications from the FAA.)
From the current headlines, the lesson we should take is that it's a really, really bad idea to be in any GPS dependent flight modes when you are flying among tall buildings, almost none of these people have even heard of multipath let alone understand it's implications.
Basically the big problem isn't our code or the bugs, it's the idiot behind the wheel (or sticks in any case).
That said there are now and will continue to be occasional problems with the code that crop up from time to time.
They need to be addressed of course, but basically if the pilot is in control, and in line of sight (or even properly trained in FPV) there is no reason he can't switch to Stabilize and get home safely.
(BTW) I consider depending solely on RTL for bailing you out of a bad situation a really really bad idea, because it is easily your GPS that may have gotten you in trouble in the first place.
And most RTL just follows a straight line back to launch which can easily be straight through some other immovable object.
Best Regards,
Gary
Hi Marco,
I agree on the log issue. We seem to go through an expansion then optimisation of the logs. I think with the move to 32 bit we have had a lot of expansion. I hope on the next release we can redesign the logs to be much more concise and easy to understand!!
There is always a tradeoff between those changes and forcing people to relearn things and having to have different information in the wiki for different releases.
+1
Hi Leonard,
if the log could viewable as the tlog would already be a wonderful thing, many rely on a graphical interface, and it is nice to see our flying drones in the Planner shows all the sensors in real time.
I don't think it's impossible to convert log in tlog, or something still more simple to display, inside there are all the information to do so, don't understand why it has never been implemented this thing, asked several times by me and many others.
Hi Marco,
I personally never use tlogs. But I guess it should be possible. I can't answer that question myself.
Me too, but many users will, appreciate the graphical display than the "browse log", which i haven't yet figured out why continues to reside in "Terminal" in the Planner, would require a "dedicated log section" (download, clear, view, convert, etc.).
In some situations it's very comfortable "see the drone flying", while viewing such as RC-IN and other things, is much more intuitive to see what happened, if only for the reason that you see the drone on the map and the HUD with a lot of realtime information, more intuitive.
Most users don't know how how download the log... ;-)
For me (unexpert pilot) it's easier to know what happened during a fly watching the graphic logs where you can see the hole fligth in only one graph,I hope it's more noticeable when something went wrong for an untrained eye, It's very usefull for me the instructions sections where you show with graphics different common issues or when devs and others explain issues with graphics too and not only the comment, but, sometimes it's usefull the tlogs too or the klm graph to understand what happened, ej, the exact position were the things become wrong. Logs It's an impressive usefull tool to fly safe after a crash or sometimes to avoid the crash.. Perhaps more complete instructions about how to analize each param is going to be well apreciated but day to day we find more complete instructions, good job, Many thank's for that efford :)
Disclaimer: I have not read through this rapidly growing thread. So bear in mind that may already have been raised.
In my experience, starting off in the MultiWii world, then over into Baseflight and OpenPilot and spending a lot of time testing and flying various PID AHRS controller tweaks and versions on sports quads. I've spent many hours assisting with university projects with first APM 2.5, 2.6 and then Pixhawk 1. I've been dumbfounded with what appears to be extremely difficult PID tuning in APM:Copter or and poor performance even after multiple iterations of tuning, etc (autotuning never produced great results). There is a reason you don't really see sports flying with APM:Copter, it just doesn't easily get anywhere near the "locked in" results you get on these vastly simpler PID implementations right out of the box even with hard mounted PCBs.
I've heard on numerous occasions how APM:Copter PID implementation models the real world etc, and yet the results speak for themselves. It's difficult and the results for the effort are disappointing. I would like to see options to switch PID controllers introduced into APM:Copter/Rover/Plane.
-
3
-
4
-
5
-
6
-
7
of 18 Next