Developer

Copter reliability vs functionality

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!

You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –

Replies

    • Developer

      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.

    • That's an excellent comment. The work you and the other developers have done is amazing and unbelievable. I solve things using passive safety such as low weight and parachute. One thing that would be great is if some one with knowledge added support for smarter esc such as the ones from Andreas Baier. I think that if any of the developers contacted him there would be very exciting solutions in place in very little time.
    • Developer

      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.

    • MR60

      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".

      • Developer

        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.

        • MR60

          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...)

This reply was deleted.

Activity

DIY Robocars via Twitter
RT @DanielChiaJH: Great racing against @a1k0n today at @diyrobocars! Pretty cool to both break sun-9s at the track today I think I got very…
6 hours ago
DIY Robocars via Twitter
Broadcasting the @circuitlaunch race live now at https://m.twitch.tv/diyrobocars Races begin around 2:00pm PT
11 hours ago
DIY Robocars via Twitter
RT @a1k0n: ran a huge number of hyperparameter tuning experiments yesterday; now I can train a new policy, far with better quality, in 15 m…
11 hours ago
DIY Robocars via Twitter
RT @a1k0n: Did I get rid of hand-tuned parameters? Yes. Am I still hand-tuning more parameters? Also yes. I have a few knobs to address the…
Monday
DIY Robocars via Twitter
RT @a1k0n: I'm not going to spoil it, but (after charging the battery) this works way better than it has any right to. The car is now faste…
Monday
DIY Robocars via Twitter
RT @a1k0n: Decided to just see what happens if I run the sim-trained neural net on the car, with some safety rails around max throttle slew…
Monday
DIY Robocars via Twitter
Sep 24
DIY Robocars via Twitter
RT @SmallpixelCar: @a1k0n @diyrobocars I learned from this. This is my speed profile. Looks like I am too conservative on the right side of…
Sep 24
DIY Robocars via Twitter
RT @a1k0n: @SmallpixelCar @diyrobocars Dot color is speed; brighter is faster. Yeah, it has less room to explore in the tighter part, and t…
Sep 24
DIY Robocars via Twitter
RT @a1k0n: I'm gonna try to do proper offline reinforcement learning for @diyrobocars and throw away all my manual parameter tuning for the…
Sep 23
DIY Robocars via Twitter
RT @circuitlaunch: DIY Robocars & Brazilian BBQ - Sat 10/1. Our track combines hairpin curves with an intersection for max danger. Take tha…
Sep 22
DIY Robocars via Twitter
RT @SmallpixelCar: Had an great test today on @RAMS_RC_Club track. However the car starts to drift at 40mph. Some experts recommended to ch…
Sep 11
DIY Robocars via Twitter
RT @gclue_akira: 世界最速 チームtamiyaのaiカー https://t.co/1Qq2zOeftG
Sep 10
DIY Robocars via Twitter
RT @DanielChiaJH: Always a good time working on my @diyrobocars car at @circuitlaunch. Still got some work to do if I’m to beat @a1k0n howe…
Sep 10
DIY Robocars via Twitter
RT @SmallpixelCar: My new speed profile for @RAMS_RC_Club track https://t.co/RtLb7TcgIJ
Sep 10
DIY Robocars via Twitter
RT @SmallpixelCar: Practiced at @RAMS_RC_Club today with my new @ARRMARC car https://t.co/AEu2hCx89T
Aug 28
More…