AC3.3 TradHeli Release Discussion

WARNING to TradHeli users:

Do not attempt to fly AC3.3 until you hear otherwise from me.  I have not even bench tested it yet, let alone test flown it.  There are quite a lot of changes that have gone in that could be crash-o-matic for helicopters.

AC3.3 release for Tradheli is likely to be delayed.

This post will serve as the official release progress thread for TradHeli.

Warning: DO NOT FLY RC6!  It has a critical bug that will likely end in a crash.

Warning for RC5:

RATE_YAW_FILT_HZ param will change defaults from 5Hz to 20Hz to be more suitable for helicopters.  If you have never changed this parameter from 5 before, then it will automatically update the value to 20 without warning.  This much faster filter will probably require reduction in your P and D terms, and the yaw may oscillate badly.  Be prepared to retune these.  As a safety measure, probably cut them in half for your first take-off.

Warning #2 for RC5:

I accidentally broke the Landing Detector.  It will probably never trigger.  You should land in Stabilize mode, or be prepared to shut down the motor as soon as it touches the ground in Alt_Hold, Loiter, Auto, etc.

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

Join diydrones

Email me when people reply –

Replies

            • Thanks, I actually just sourced the parts myself last week. :)

              You shouldn't be able to start the motor, as the servo should be fully closing the throttle?

    • Hi David, my first recommendation is still the Trex 500.  They're affordable, ubiquitous, not too big, not too small, etc.  It can be a challenge to pack a full autopilot system on a 450.  It's certainly possible.  But it's just that much harder to do it well.  The 500 is just big enough to give you more room and it handles the weight better.

      • Moderator

        @Robert  @Tridge,

        you did a great work on APM Helicopter , the result obtain by Ferruccio with his Protos are very good.

        With some small patch and good mechanical seutup the result is in the video :) 

        best

        Roberto 

  • Another update.  I'm getting pretty excited about this release now as it cleans up a lot of long-standing issues.  I've just done a bunch more work and going for a test flight shortly.  But in addition to the recent announcement:

    - Piro Comp has been added.  There is a param which defaults to off, ATC_PIRO_COMP to control it.  You would have to turn it on to get this function.  Credit to Jolyon Saunders who wrote the initial code but which was commented out for a long time.  I just had to freshen it up a bit and now it's working and available.

    - Rate_****_I_L_Min.  This is Rate I-term Leak Min.  I hope most of you are aware of the "Leaky I-term" that we use when landed or hovering.  Basically, it tries to return to zero.  The reason being this prevents tipovers on the ground from the I-term building up too much due to small errors.  The problem is that in a hover, it prevents the I-term from being effective.  The Leak_Min is the point below which it won't leak.  I'll be testing with this set at 500.  This means that the I-term will be able to move to 500 while on the ground, but won't get much further because it leaks past that point.  But 500 should be enough to stabilize a level hover well.  When the system determines it's in dynamic flight, it switches to full I-term, limited by the Imax parameter.

    - Added a function to slowly slew between Acro Col and Stab Col.  If you use the H_Stab_Col_Min and Max parameter, and you also use Acro, you know that there's a good jump when switching modes.  Now, the jump will be smoothed out.  I'll be trying a 1/2 second transition time.  This should reduce shock to the airframe and give the pilot a chance to keep up with the change.

    - Added 3-segment Stab Col function.  Now instead of just being able to set the Min and Max collective in Stabilize mode, you will get two mid points.  So you can adjust the collective curve in Stabilize mode at 0 throttle, 40% throttle, 60% throttle and full throttle (aka collective pitch).  So values I'll be trying are 300, 500, 650, 900.  This really allows for smoothing out the area near hover.  Ideally I'd like to make this smooth instead of having "corners" but that will take more work.  NOTE: The old H_Stab_Col parameters have moved!  They are now called ATC_Stab_Col_1, 2, 3, and 4.  You will need to migrate these across manually.

    - Added Acro Col Expo.  This simply adds some Expo around center in Acro mode.  Again, to make it a bit smoother near 0 pitch.  This will be settable with the ATC_ACRO_EXP parameter.  Test the motion on the bench carefully.  I don't recommend setting this higher than 0.5, even that's a lot.

    Something else I want to get in is something else Jolyon worked on and has a PR for, which is making the cyclic inputs "circular" instead of square the way they are now.  ie: the swash moves further in the corners than it will with straight roll/pitch inputs.

    • That makes sense. It's a fair enough request to make it optional I guess. Is there any particular reason you would like it optional other than flexibility? The reason is that it's best to minimise options in the parameter list and I'm struggling to imagine how a rectangular limit would be useful in any case.

      Rob, what are your thoughts on this?

      Cheers
      • Is there any particular reason you would like it optional other than flexibility?

        Please correct me if I am wrong. On most FBL units I can(must) set the collective pitch range and the limit for elevator and/or aileron. I assume I have no problem (mechanical binding or stalled airflow) applying only elevator and collective OR aileron and collective with a standard setup.

        But if I have a problem applying simultaneously elevator and aileron (and collective) I would use the 'swash ring' limiter (of the FBL unit) as much as needed. As much as needed, because if I set i.e. 7° for elevator and aileron than I want 7° (and not i.e. 5°) no matter if I apply only elevator/aileron or elevator and aileron together.

        On all my helis I never used a 'swash ring' limiter, therefore I would like to have it optional.

        I'm struggling to imagine how a rectangular limit would be useful in any case.

        If I put the stick in the corner than I think I really need all of it i.e. 7° and not 5°. Is my understanding of the 'swash ring' limiter wrong or is your PR working differently ?

        • Ok, let's discuss this, but first we need to be clearer of how we define things. Your stick input does not correlate to cyclic unless you are using a flybarred heli. So full tick forward/left/diagonal doesn't make a difference as far as this PR is concerned.

          What this PR is for is so the user can set the cyclic limit in any direction and it remains the same in all directions. It's simpler to set up because you can measure from the most problematic point of rotation of the rotor and set the limit from there, rather than using trial and error to get a good fit with two parameters.

          It doesn't make sense to have a 10° limit in one direction and then say 12° in another. If you set up your machine to handle a specific amount of cylic in one direction, and then it becomes more and less in other directions it becomes more difficult to manage.

          If you want more/less cyclic in pitch vs roll (I have no idea why you would, but say you did), that would be best solved with an elliptical limit, which is possible if you guys require.


          The PR is there to limit the absolute maximal physical motion of the swashplate, that's it. It does not modify/scale/bend your inputs in any way. It does not modify the output of the control system in any way other than limit the tilt if it goes beyond what you specify. Under most flying conditions the limit will never be reached.

          To be honest it probably won't make any difference to how your machine flies unless it's reasonably large and you fly HARD. I just created it because it seems like a more correct way to limit swashplate motion :)

          It's totally up to you guys as to whether it's optional or not. I don't mind scanning through all the countless params, but it seems more user friendly to try and limit how many options we have.
          • Thank you for your explanation ! Shame on me for not reading your PR and implying your PR does the same as the usual 'swash ring', which reduces i.e. elevator output if I steer aileron at the same time.

            I apologize and I am happy to use your PR as it is and I don't need another parameter(= not optional).


            If you want more/less cyclic in pitch vs roll (I have no idea why you would, but say you did), that would be best solved with an elliptical limit, which is possible if you guys require.

            I never tried it and till now (AP flying) the PIDs were good enough to compensate for the different inertia, but I could imagine that a 700class 3D heli flying close to the limits could show different reactions. User friendly and Tradheli is an oxymoron, so please let me try elliptical :-).

    • @ultrafuge, the limits being applied by the patch are for mechanical swashplate limits, not control input limits coming from your radio. They are very separate things ;) The proposed mechanical limit is to ensure you have the same amount of physical swashplate travel in all directions. A limit set in your radio will not work because the PID controller only uses your radio as an input.

      FWIW, the circular input limits may already be applied to arducopter. If that is the case (need to confirm as that PR was submitted a very long time ago), setting a circular limit in your radio will have zero effect.
      • @Jolyon,

        thank you for your PR and sorry for my bad English. I understand (and knew already) what you are saying. I don't want to say the TX 'swash ring' (Futaba nomenclatura) can replace your limiter.

        Please make this only optional. IIRC I can set this option in every TX I have.

        This should mean in 'every' TX I can choose if I want(need) this option or not. Please make it an option to use the 'swash ring' (or not) in this code as well.

         

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…
6 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…