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

            • Hi, I did not see your reply when I typed mine.

              So, you suggest actually same thing I wrote about. Only question I have - ok, we use CH6_Rate_KP, got it. What values should be set for ranges? Will that range of CH6 input be applied on top (added) to the previous autotune produced result or is it overriding that value completely?

              For now I actually did a same routine with 3 sequential autotunes and I found that result to be quite acceptable. It was always a challenge to do a first one, after I re-flash FC - that takes very long time as craft often overturns/flips during autotune, I then started initiating autotune from a stabilize mode instead of alt-hold and it was able to complete it this way more realiably, bot sure if it was a glitch or just a coincidence.

              2nd and 3rd autotune, or any subsequent was never an issue.  

              • Wow,if it flips/overturns in autotune your initial PIDs must be waaaay off! I personally tend to set the dial quite low rather than high (default min/max values) as it's less likely to overshoot or oscillate. It does mean sometimes the autotune won't start so increase until it does start (also make sure you don't have any trim set and the throttle is in the middle, that also seems to stop autotune kicking in) and the twitches are quite 'muddy' to start with, but I find that safer and more reliable. Just make sure that when you land and disarm after the autotune, you turn the ch6 option off or to something else, otherwise it will override the autotune you've just done!

                • It was doing it using default values in the APM after initial firmware re-flash.

                  As I re-flashed it 3 or 4 times due to experiments and then did some parameters resets - I had a chance to experience it all several times, so, it is a repeatable issue. And it was with drone`s CG to be almost perfect in the center, all obvious requirements were observed.

                  Like I said - there is no guide no where what would say what parameters set to what for this kind of work after you are done with settings in the initial setup - flight mode, mandatory hardware, radio and compass calibration.

                  Nothing nowhere guides step by step what should be done next to prevent those flip over things. I understand it goes into some 'empirical knowledge' territory, like a 'then cook until ready' general direction in the old cookbook without bothering to provide any further specifics. :)

              • Developer

                Hi Paul,

                First up, if you get a good autotune you will not be able to do better with a manual tune. Manual tunes are only going to help when you have a problem copter. This may be caused by offset CG or a relatively heavy gimbal on vibration mounts. You may not be able to fix these things for various reasons leaving you with no option than to use manual tuning.

                So yes, you have the correct CH6_Rate_KP and KD. This does both roll and pitch at the same time. I set my minimum to what I know the copter will fly safely with. That way I can drop it to minimum and know I am ok. I increase it until it oscillates or maxes out. If it maxes out then I set the minimum to the maximum value and increase the maximum value again. I use somewhere from a 1:2 to 1:4 ratio between minimum and maximum each time.

                The Ch6 tune is overriding the value completely so be careful not to change the setting before switching the ch6 tune setting to another pid setting or turning it off.

                Manual tuning is complicated so I recommend sticking to Autotune if it gives you reasonable results. It looks like you have autotune pretty well sorted. I too tend to do an autotune on each axis to get it close then do them again. This reduces the cross coupling between axis and gets things tighter.

                • What do you put., literally, what numbers do you type in right below the ch6 dropdown selector into 'min' and 'max' input windows?

                  How do you choose those numbers? What is the logic and procedure to make this decision?

                  • Developer

                    Hi Paul,

                    I tried to answer that question but I wasn't as clear as I could have been.

                    "I set my minimum to what I know the copter will fly safely with."

                    This is what you can fly around with without flipping. It may not be perfect but it is safe.

                    "I use somewhere from a 1:2 to 1:4 ratio between minimum and maximum each time."

                    I am saying I set the maximum value to be somewhere between 2x and 4x the minimum value.

                    I have to disagree with Rob here.

                    I start out with the defaults and take off to 25cm above the ground to see if the copter feels like it is safe to go higher. Then 50, then 100cm. Each time I look to see if I have enough control. If I feel it is too sloppy I increase both Rate P I and D by 50% and try again. If I find it oscillates I reduce Rate P I and D by 50%.

                    This is where you can start the manual tuning process if you wish.

                    Personally I prefer autotune so once I have found a basic tune that I can fly gently with I take the copter up to about 20m and I move the sticks to one side then let go of the stick so it springs back to center. I start out with small angles like 5 degrees and work up to 45 degrees. I am looking for an overshoot. If it overshoots by a large angle or starts wobbling then there is a good chance it will flip during autotune. I generally increase the pids by 20% if it wobbles (as fast as you can say wobble wobble wobble) and decrease by 20% if it it oscillates (much faster than wobbling).

                    I personally then do an autotune and look at the results. I tend to do yaw then roll and pitch. Then I do yaw again followed by roll and pitch.

                  • Some experience required here.

                    Small copters, I start with Rate P 0.050 to 0.100, start with the knob at the bottom.  Larger copters, usually 0.050 to 0.200, start with the knob around 0.100.

      • This is encouraging. It shows that it is possible.

        In large scale industrial systems I've seen that it's very normal that the "designer/developer" can make his machine work "to perfection". But anyone else can quickly find the bugs, or can't easily find the steps to implement the perfect setup.

        This isn't a personal criticism. I think if anything your work has been better than many, and "that's" within in a top notch group. I know from our development environment, one of the toughest things to accomplish within a group is the insight and strength to "break" designs. In that respect I also appreciate your interest in getting to the bottom of these issues when they are raised.

        Perhaps a big part of "bullet-proofing", is making given freatures "innate": similar to what Marco is talking about, The procedure assures solid success and eliminates the ability to do it wrong.

        The whole concept of tuning is something that even qualified engineers can have difficulty with, and Ardu... to make things worse has multiple cascaded PIDs on top of everything. Autotune perhaps is the answer, once it's complete. But it can be seen that you are working toward a more "unspecialized user" approach.

        Just another note. There are a lot of DIYers out there. They usually build one or two rigs. But those of us in product development know that a new rig, say "Solo" or "IRIS" when it came out, reguired several more than one or two iterations to get it right. And that's starting with many man years of experience under their belts. So although the tendency would be to say, "If someone is going to build his own rig, he has to know what he is doing", this doesn't come anywhere near practicality.

        The bottom line is that even an experienced DIYer can't really be expected to get his new rig working to perfection in one iteration without a LOT of help from the firmware design. It's a tremendous challenge for you guys.

        I don't know if the question to this thread should be, "where should we dedicate our effort, bug fix or new dev?", rather than "How can we best advance with new design AND assure clean trouble free DIY performance"

        • Developer

          Hi David,

          I think you hit the nail on the head there.

          Most people starting out in this hobby just don't get some of the finer points (but very simple points). Make sure everything is rock solid and lock tighted or uses nyloc nuts. Make sure everything is fixed down and not able to shake around, including wires. Make sure motors in good condition, not bent, with no play, and smooth bearings. Make sure props are in good condition (I don't balance props as it doesn't help in forward flight).  Finally, get the CG in the right place.

          The only thing that takes a little more knowledge is power train design, prop/motor/esc/battery selection such that they all work together. This has tripped many people up.

          The other thing that is worth remembering. There are two types of people on the support forums, people with a problem that need help and people that are trying to help. The majority of people flying arducopter are out having a good time and only reading over the forum hoping to learn something (or lend a hand).

          Gotta love this community!!

  • Don't know about that compass but I'd buy a bobble head Randy to stick on the dashboard of my multi rotors, heck how about one for each of the dev team to help fund the project? With servo actuated flapping arms no less so we can all be reminded that under the brute force power and dedication of the dev team our bobble head ( or not ) enhanced rigs stay aloft. Seriously though… Whatever you guys decide here, you all don't hear this enough… Thank You!

This reply was deleted.

Activity

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
DIY Robocars via Twitter
RT @fatcatFABLAB: Proud to be hosting a restarted DIY Robocars NYC Meetup April 26. Come by if you want to talk about and race self-driving…
Apr 17
More…