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.
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.
@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.
Rob, what are your thoughts on this?
Cheers
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.
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 ?
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).
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 :-).
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.
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.
-
15
-
16
-
17
-
18
-
19
of 34 Next