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
Just on the last point, I also liked the comments at the bottom of the wiki. That was more of a technical issue when we moved to wordpress. I've ping'd Hamish, our new wiki master to see if he can find a way to support that. I'll bet we can.
Not all bugs are equal : once detected they could be classed as critical, high, medium low for example A bug that can crash the vehicle should be treated as critical and solved in priority.
Also it would be nice when a bug is solved, to solve it also in the last "key" previous versions if it was there. The idea is to be able to fly either with the very last version, or with an older, more stable "key" version which also received bug corrections.
I think the priority you have is right, and I think that's what we're doing. Where I think some misunderstanding occurs between the developers and the users, is on expectations. Many "bugs" are actually "the code didn't stop the user from making a mistake". Or users expecting the impossible. For example, a copter that "flies away" due to a GPS glitch. I hear people say things like "it should know it's glitching and just not fly away". Well, OK... that's a great idea... any idea on how to do that? We're all ears.
I just encountered today a user who had RTL_ALT set to 0 meters. In that case, the copter is likely to land, and then try flying home. We all know how that's going to go. Some people would consider it a "bug" that the program let the user set that parameter, or that the copter should know it was obviously going to crash into the ground. We can debate that. But calling this a "bug" is not really fair.
http://copter.ardupilot.com/wiki/configuration/arducopter-parameter...
The minimum altitude the model will move to before Returning to Launch. Set to zero to return at current altitude.
RTL-ALT 0 just means it will RTL at the current altitude not go to zero altitude. Maybe I didn't understand what you meant....
Nope, I had it wrong, a couple people pointed it out to me.
Hi Rob,
We can argue this viewpoint as many systems, for example in the automotive industry, do stop the users from doing critical mistakes. This does not necessarily mean users are "expecting the impossible". Some things might be impossible to stop, you're right, but some others might be possible to stop (I think everyone here on this forum is not dumb enough to expect the impossible and understand that human factor cannot be 100% under "control".)
On your question about fly away because of a GPS glitch: to give an example of a possible answer (that's certainly not the only one possible), i would think it would be possible to have some kind of algorithm that , based on IMUs and, why not, on visual processing, tries to immobilize the aircraft (by minimisation of pixel movements, minimisation of accel/gyro/whatever other sensor detecting movement) until it recovers its "GPS".
Hi Hugues,
I think your answer to the GPS glitch problem is a good example of what Rob is talking about.
" i would think it would be possible to have some kind of algorithm that , based on IMUs and, why not, on visual processing..."
IMU's are good for 5 seconds on their own, before we start to notice the copter moving off the point and it just gets faster and faster from their. At 10 seconds it is clearly moving away and at 15 seconds it could be out of sight. There is nothing more we can do with the quality of the IMU sensors we have.
If you have optical flow you don't need GPS at all and we already do this. (optical flow is the measure of pixel movement from a camera)
Your answer suggests that we should be able to do this for any copter but it isn't possible. Even with optical flow you will get a fly away if you are too high as optical flow stops working because the pixel movement is too small. Your suggestion is a perfect example of what Rob means by "expecting the impossible".
The most we can do is detect a GPS glitch and fall back to stabilize or do a land. And if the GPS glitch is such that we can't detect it, then you see the fly away.
Hi Leonard,
You give yourself the answer that something is possible : land. I do not expect a precise action as long as the fly away is avoided (any other action that would avoid a fly away...)
-
14
-
15
-
16
-
17
-
18
of 20 Next