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

        • Yes, we could do that, but at the cost of cutting the total pace of development in half roughly.

      • I think this is kind of what beta firmwares are for. New features that may have bugs/stability issues, but, allow users to test them knowing there is a risk. While stable versions have the features that have been out for a while but have been well tested by beta users.

    • Developer

      Hey David,

      Thanks for the feedback. I think this is one of the only real bug/fix issues that have been raised here.

      I have two questions I would like you to explain to me if you don't mind.

      1. You said that Loiter didn't compete for photography. What do you mean by this? Loiter is very smooth and predictable and you can make very fine adjustments in position. It would be great if you could explain further.

      2. Can you go into a little more detail about your issues with PosHold.

      PosHold is one of the few parts of the control code that I didn't design and I don't think it has evolved since it was first introduced. I have a plan to improve it (twitch free shouldn't be a problem), however I am not a fan of this mode concept so I don't use it myself. Any help you can give me to get a better idea what people really expect from this mode would be helpfull.

      • Hi Leonard,

        I seem to remember that among the claims of poshold, was it's abibility to close the gap between Loiter, and the parallel funtionality the DJI offered. I'd really have to go back and search the files to get the details, but the main drawback to Loiter was that it was too slow in re-positioning. If you wanted to get from one shot to another you had to switch to some other mode, reposition and then back to Loiter.

        I had Loiter out of my switch combinations until just recently. I decided to put it back to re-familiarize myself with it. As you say, I think it's much better for taking shots, it allows a smooth run from beginning to end of a sweep, much smoother than poshold anyways, although now that we're discussing it, perhaps I should give the two a real hard test.

        I'm not a photographer though, but the problem with Poshold seems to be around the "hover envelope". For instance, I think it's fine "on the run", works like alt hold and seemingly without twitches. But from the breaking phase on there are problems. Transitions seem to twitch. Where this is really obvious and complicated is close to hover. As external forces tend to move it around, there are audible clicks and twitchy movements as it reacts.

        I haven't looked at it, but my impression is that these twitches occur as it transitions from sub-mode to sub-mode, and the transition point is quite close to "hover".

        I thought for instance that the autotune and/or feedforward settings were at fault, but I removed or softened those down to where the machine is overly "sluggish" and the twitches still show through.

        As you suggest, I really think that it should be easy to fix, one or two hours and it would be ready. I was even thinking about giving it a go, but just haven't been able to get the time. (I did see a couple of "switching times" in the software, some of which seem a bit short, but I didn't get much deeper than that.)

        I think that most of the little things, that could make a big difference in the overall stability and confiability are small and could be managed "fairly quickly". There's just a lot of them I know!

        The photographer I mentioned has taken a turn to 3DR in the last little while. He has a little help on this end from a few of us, and I think he generally likes the Pixhawk and where it is going. But he commented about poshold the other day, and refered to his DJI in the process. I think the clicks/twitches were scary for him. It's those small things that influence those snap decisions on someone who has a long and hard day in the field and needs something that just works, now.

        Priorities up to now have put many of these small things on the back burner. Perhaps now is the time to turn up the back burners for a bit.

        I'm a really big fan of 3DR, and it's painful to see someone even looking sideways at something else.

        Thanks for all your excellent work BTW.

        • I just came back from another test with my X8 and 3.2.1. I started by taming down the gains, they were at autotune values from a 3.2 autotune.

          This test was with standard X8 gains plus ATC_ACCEL:RP_MAX at 72000, ATC_RATE_RP_MAX at 18000 and ATC_RATE_Y_MAX at 9000, which are all fairly tamed down as well.

          The twitching was negligible, but unlike the IRIS, I could see it pitching and rolling (as you would expect) as it tried to keep itself over the hover-point. These were the points where it used to "twitch".

          After the initial autotune, the X8 was quite crisp, and while I liked it, it was like too much honey, so I tamed it down, mostly with the ATC values. Then for this test, I tamed it down quite a bit more with the PID gains.

          What it seems like, is that when the gain is like I like it (for feel and responsiveness) it twitches in poshold. The twitches seem like transients, getting through, even being amplified at the fairly fast transitions to maintain position.

          When I turned off feed forward during tests before this test it improved, but the twitches were still quite pronounced. FF was off as well for this test.

          I feel as though these transients could be softened without overly affecting the solid response that poshold has to maintaining position.

          Being that I was working with standard PID configurations and settings, the loiter response was extrememly sluggish. The speed is turned down. I'll next do some tests in an effort to try to improve it beyond the previous IRIS loiter response.

          Once I've got it tuned in a best possible I'll load 3.3-rcx

          Again, zero wind for today. Why is it that when you want wind you can't find it?

        • Developer

          Hi David, 

          Thanks for the feedback. I will be interested to hear your thoughts as you continue to experiment with these modes.

          Stopping in Loiter: Loiter doesn't break when you let go of the sticks. Loiter is an artificial Stabilize mode. So like in Stabilize, if you let go of the sticks you drift forward and slowly stop. To quickly stop you need to pull your sticks back in the opposite direction, just like you would in Stabilize.

          Yeh, I agree that Loiter got a bad rap when it was first released. This was when the devs/community was only just starting to get used to relying on Auto Modes for fast flight. So the defaults were set to something like 7.5m/s (I was running around at 20m/s). Many people never took the time to turn up the maximum speed and didn't realise it felt much better when it was set closer to the natural maximum speed of the copter.

          PosHold: Thanks for your feedback here. You  may be correct that wind brings out a couple of problems with switches between sub modes.

          Just to give you an idea of how long I would expect it to take to make the improvements I have in mind. I would take a day to fully understand how it is done now. A day or two to formalise my design and run some simulations in matlab to make sure all internal transitions are smooth and I have the maths correct. Probably about 2 days to do the coding and basic test flights to make sure each bit works as it should. Then there would be a half day with Randy to make sure everything is coded correctly, optimised, commented, properly integrated. Then Randy and I would start running tests both in SITL (simulation) and in real life to make sure the feel matches the old version (and look for problems). Then it would go into master and the flight test crew would start to give feedback. Hopefully this wouldn't be too much at this point but it generally results in a couple of edge cases or tweeks, say another day of work over a couple weeks. Finally it goes into a release candidate and onto formal release. And that would be if everything goes to plan....

          Thanks again for your feedback!!

          • In regard to loiter - I had this only once, but there is a condition where while in loiter you suddenly lose GPS or GPS sensor gets blocked by an object - drone moves extremely erratically, probably due to sudden distortion of GPS data feed and wrecks havoc to all around it.

            I had literally throw my radio at it and knock it down to the grass where it continued to engage props at 100% power (with me having all throttle cut on the remote) and destroying grass for at least a minute until it finally gave up and shut itself down acknowledging 'crash'.

            It was all on 3.2. version on APM, so, not sure if it applies to the discussed scope, but, as I intend to keep this APM FC - I really wonder if any of those proposed safety measures will be retrofitted into previous APM compatible builds?

            I had problems with 3.2.1, so I really wonder about 3.2 here, specifically.  

          • I'm sure my X-8 is worse with this, and right now it has 3.2.1 on it. My IRIS has 3.3rc5. So I'll test with the same firmware on both and try to get the parameters as close as possible.

            Sorry about the Loiter braking comment. I haven't used Loiter in a while and forgot that it doesn't have braking. :p

            I'll test with 3.3rc5 then. Seems to work well on the IRIS.

            • Though Loiter *can* have braking.  Just set WPNAV_LOIT_MIN_ACCEL (or something like that) higher than the default of 50.  I've run 2-300, and it stops quick.  The only problem is, it behaves well from a high speed.  But I find it becomes over-reactive when making small movements at low speed.  It tends to bob around.

        • To be honest, I just came back from a short test (6 min) comparing poshold and loiter.

          Everything worked perfectly!! Go figure?? It's a pretty calm day though, it's incredible what a bit of wind can do.

          I'm using 3.3rc5 right now. Since I really haven't "specifically" gone out to test poshold in a while, I couldn't say if it's only with 3.3rc5 that its better. I mentioned poshold here though because only a very short while ago I saw the same twitchiness. like last week or the week before.

          I'm going to keep looking, it's got my curiosity up. Maybe a little more wind takes it over some kind of a threshold.

          In these tests BTW, the loiter stop response was a little sluggish. Even slowing from 4 km/hr it took a whole 6 meters or more, while poshold brakes nicely in about half the space.

           The only other thing I saw was that tendency to drop a meter or two on horizontal runs. That airspeed bubble effect. I know that's a toughy, but would nice to get rid of it somehow.

This reply was deleted.

Activity

DIY Robocars via Twitter
RT @SmallpixelCar: Today at @RAMS_RC_Club for @diyrobocars. Used @emlid RTK GPS and @adafruit @BoschGlobal IMU. Lap time 28s https://t.co/R…
7 hours ago
DIY Robocars via Twitter
May 15
DIY Robocars via Twitter
May 14
DIY Robocars via Twitter
May 13
DIY Robocars via Twitter
RT @f1tenth: Say hi to our newest #F1TENTH creation for @ieee_ras_icra next week in Philly. It’s going to be huge! 😎 🔥 @AutowareFdn @PennEn…
May 13
DIY Robocars via Twitter
May 11
DIY Robocars via Twitter
May 8
DIY Robocars via Twitter
RT @SmallpixelCar: Noticed my car zigzagged in last run. It turned out to be the grass stuck in the wheel and made the odometry less accura…
May 8
DIY Robocars via Twitter
RT @SmallpixelCar: Test my car. RTK GPS worked great. Thanks @emlid for their support. https://t.co/EkQ6qmjmWR
May 8
DIY Drones via Twitter
RT @chr1sa: @kane That's @diydrones circa 2009. Still have a box of those Canon cameras that we used to strap into planes, just like this.…
May 3
DIY Robocars via Twitter
RT @chr1sa: Our next @diyrobocars race is going to be outside at a real RC racetrack in Fremont on May 28. Fully autonomous racing, head-to…
Apr 30
DIY Robocars via Twitter
RT @f1tenth: Our Spring 2022 F1TENTH course @PennEngineers is coming to an end with a head-to-head race as a big finale. So proud of our st…
Apr 26
DIY Robocars via Twitter
RT @DanielChiaJH: I wrote a thing! Throughout the development of my @diyrobocars car I've been using @foxglovedev Studio to visualize and d…
Apr 23
DIY Robocars via Twitter
RT @SmallpixelCar: My new car for high speed. Low body, everything ( @NVIDIAEmbedded Jetson Xavier NX, @emlid RTK GPS, IMC) under the deck…
Apr 23
DIY Robocars via Twitter
Apr 21
DIY Robocars via Twitter
RT @f1tenth: F1TENTH Race training setup @PennEngineers for our upcoming ICRA2022 @ieee_ras_icra competition. @OpenRoboticsOrg @IndyAChalle…
Apr 21
More…