Hi Bill!
Thanks for your detailed answer. Ok, if we’re talking about something like 15 deg it should be safe enough to give it a try and see, where I actually am with my configuration.
I totally agree with that. I’m not trying to improve flight characteristics of my rc-helicopter. I’m just using it as a testbed for some aerodynamic experiments I’d like to do with the new stab. So the flight modes arducopter provides are actually just perfect for it. Especially because I can see what the controller is doing (servopositions etc.).
Yes, it’s only after I’ve been in acro. When I arm in stabilize and stay there, the movements are exactly as commanded. But when I go to acro, move the stick around a bit (actually it is sufficient to just command e.g. roll) and go back to stabilize then the phenomenon occurs. It doesn’t look like just a phase shifting in the controls. It’s more like a wave: When I move the stick to the right, it also makes a pitch movement but goes to neutral again. (Of course roll stays there as I hold the stick to the right.) And when I then centre the stick again, roll is centered as expected, but it again makes a strange pitch correction (this time in the other direction) and goes back to neutral.
I’ve noticed a problem in my setup. I think it doesn’t have to do something with the described pich movements when roll is commanded. But just to be sure…
The cyclic deflections of my swashplate are not symmetrical. I can measure 6.2 deg when I roll to the right and 8.4 deg with roll left. Of course I checked it on 0 deg of collective and also with H_COL_MID set very precisely. It doesn’t have something to do with my mechanical setup because all my servo arms are perfectly horizontal and also I can see in the servo monitor of Mission Planner that my Pixhawk is commanding a greater servo travel to the left than to the right. Of course I had to make some adjustments to the servo trims in ardupilot. They look like this:
SERVO1_TRIM,1542
SERVO2_TRIM,1580
SERVO3_TRIM,1480
(Servo 1 is left, 2 right and 3 on the rear.)
Could this cause the problem? E.g. ardupilot is trying to prevent the servos from binding? But in reality there is enough space for the movements.
So you adjusted your servo trims so that the swashplate was level and thus perpendicular to the shaft. 6.3 to 8.4 is a big difference. What is the pwm difference with full left cyclic and full right cyclic?
Truthfully I have never looked at this like you are doing. I set up the head making sure the swashplate is perpendicular to the shaft using the servo trims and really don’t check cyclic. I have never had an issue.
Actually I adjusted the servo trims so that all servo arms were perfectly horizontal. (Couldn’t get the trim values smaller, because of the mechanical restrictions of the servos and levers.) Then I adjusted the mechanical links to the swashplate so that it was level (or at least almost level, because I can’t do half or quarter turns on the ball links. Finally I corrected the trim values a tiny little bit to achieve a perfectly level swash plate. I used a swash leveling tool to be sure it’s perpendicular to the shaft.
What could also be important is that the swash is only moving about ¾ of the way of the stick. When the stick is near the endpoints the swash doesn’t move at all. But I guess that’s ok. I also redid the rc-calibration (over and over again), but this doesn’t help.
The PWM values Pixhawk is commanding in manual mode are:
Stick: left middle right
Servo1: 1290 1534 1744
Servo2: 1322 1580 1775
Especially on servo2 you can see it. From mid stick to full left there is a difference of 258 microseconds, but to full right it’s only a value of 195. Maybe you’re right and it doesn’t matter, but I’m always trying to do my whole setup very carefully, because I know it can help a lot to get the best out of the helicopter.
With the servo trims set that much different, the head is not geometrically perfect. If the head geometry was perfect all three servos would be at 1500 pwm with the swash level and blades at zero pitch, and the angle between the servo horns and swash links would all be the same.
Depending on what you have the servo directions set to, Pixhawk is already putting out higher pwm value on one side in a static condition with the swash mechanically leveled due to the trims being that far off.
If it was me, I’d center the servos at 1500 and make sure the angle between the horn and links was all identical, then level the swash and zero the pitch mechanically with the turnbuckles instead of doing it in software. You can certainly do what you have done in the software, but the heli won’t fly perfect because those actuators travel in an arc. They are not linear. And the difference will show up at maximum travel.
If you would put two dial indicators on the swash links for servos 1 & 2 you will likely see what the problem is.
Hi Chris!
Thank you too for your help! I’ve just tried to do what you suggested. I saw, that the trim values of servo 1 and 3 are low and servo 2 is high. So I pulled off the servo arm of servo 2 and put it back on in a position one tooth lower than before. But now I’m way off in the other direction. My trim value for no. 2 is now 1435 (instead of 1580 where it was before).
The problem is not my head not being geometrically perfect (I use a T-Rex 800E Pro DFC with BL815H Servos). It’s that the servos are being in a “mirrored position”. The left servo has the arm on the left side, the right one on the right side. Unfortunately the servo arms have a different midpoint when they are mounted on the left or on the right side.
With the new position of the servo arm I just did the complete setup again. Now it’s the other way around. 9.0 deg of cyclic with roll right and 6.3 with roll left.
To make it even worse: When I turn the rotor 180 deg the values change completely. But when I turn it with 0 deg (collective and cyclic), it’s 0 in every position. That’s only possible when the collective has changed a bit because of the roll input. When I look closely, I can observe this behavior.
I’m pretty sure this is because Pixhawk is calculating with that arc you talked about, Chris. But it doesn’t seem to know, that my trim values are the new zero for the calculations with the arc.
I’m sure, I can’t get my setup better now. Maybe I just have to live with it like it is. But it’d be great if it could be considered in future versions of the code, because it affects all helicopter setups more or less.
The Pixhawk does not actually mix for the arc that the servo horn travels in. I understand the problem with the head geometry there. It stems from the fact that assuming the servos are centered with the links at perfect 90 degrees, you get 50% of the length of the arm in linear travel for 30 degrees of servo shaft rotation. And going to full travel at 60 degrees of shaft rotation the linear travel from zero is 86.7% of the length of the servo horn.
That particular head would need a mix like FBL units do to correct for head geometry with aileron or elevator input to get a “pure” response to the head. Moving the horns around and making it worse sort of reinforces some testing I recently did with a couple dial indicators and measuring this stuff up. Unfortunately, ArduPilot cannot currently do the correction to fix the problem. I have written some code that can do the mix corrections like FBL units do, but I don’t have it done yet. It’s going to require scrapping ArduPilot’s infinite servo position scheme and going with pre-defined swashplate configurations like all the popular FBL units. So the mixes can be done on the specific swashplates without playing musical chairs servo positions.
The best that you can do right now for that head is to set the servos all to 1500 and put the horns on as close to 90 degrees to the links as possible. They’re not going to be all the same. So now adjust the servo trims to get them all to perfect 90 with the links. Then snap the links off the balls (or if they are turnbuckle type just turn with a wrench) and turn them to mechanically level the plate. Then adjust the DFC drive links to get zero pitch on both blades. Due to the servos being off-center, you still will run into problems at full collective with aileron or elevator input but it is the best we can do with the current code not being able to tune out a collective interaction on aileron input.
I started working on it, not only because of the problem you note, but also because ArduPilot does not support the very popular 135/140 swashplates. I have the H3-140 swashplates working. But I only have a partial implementation at this point for the H3-120 plates. When done it will have elevator and aileron to collective compensation. And aileron to elevator, and elevator to aileron mixes to tune out interactions. Identical to how all the high-end FBL units do it.
Hi Chris!
Thanks a lot for this interesting explanation! I’ve done what you suggested and think it’s the best we can get out of the head and code for now. It’s great to hear, that you are already aware of the problem and even started writing some code for it and for the other types of swashplates you mention.
Let’s assume, I ripped the servo arms off and somehow could glue it in the correct position (with no trim adjustments at all). Than everything would work fine, all the cyclic inputs were symmetrical etc.
Wouldn’t that be the same as if I always added a constant trim value to the outputs of my Pixhawk? For the servo with my perfectly glued arm 1500 us is the middle. If the Pixhawk wants to move it 200 us it sends 1700 us to the servo.
But when 1500 us isn’t the middle (let’s say 1600 is the middle with my real servo), than it could just add the +100 us trim value to the 200 us it wants to move the servo and send 1800 us. The servo would also move 200 us. And because my arms are both 90 deg to the link (one is glued perfectly, the other one is trimmed perfectly), it’s just the same reaction on the swashplate.
It will be close enough for UAV operation probably. But it will run out servo travel one direction when you try to add cyclic pitch at full collective and will cause an undesired reaction from the heli. Since most people don’t push their UAV heli’s that hard, it usually isn’t a problem. But it can be if you are making a tight turn that requires full collective and then run out of cyclic control one direction because a servo bottoms out.
I have a CGY750 FBL unit and I watched all of Nick Maxwell’s videos on advanced tuning in the thing. With dial indicators on the head to see what’s it’s doing I was able to sort of reverse engineer it and figure out how to implement at least part of the type of mixing it is using.
I know with my CGY750 downstream of the Pixhawk, set it up by capturing the swash range and doing the tuning on it, it turns my heli into a whole different machine. The handling is unbelievably precise and smooth compared to the just the Pixhawk. It has some advanced algorithms in it like predictive response that I have no clue how to implement in ArduPilot. I figured out one of them - just like a full-size heli it automatically compensates on collective if you do a elevator or aileron input. You can’t see it with the naked eye. But if you put dial indicators on the head and measure it it is doing automatic compensation.
I’m not sure about this, because the head is designed for it. I’ve got a T-Rex 600 with a 3GX on it and it looks pretty much the same with the servos not being centered at 1500 us and so on. But it just doesn’t matter. It moves ±12 deg of collective and 8 deg on cyclic with no problem in all positions. Just measured it again. I guess it’s the same with my T-Rex 800 I’m trying to setup now.
It’s obvious that Pixhawk calculates something with my trim values and doesn’t just add them to 1500 us. Otherwise the cyclic wouldn’t be unsymmetrical at 0 deg of collective. Maybe it thinks I’m running out of servo travel and tries to prevent that…? But I’m not.
I’m sure FBL controllers like your CG750 have some advanced control algorithms in it that are really hard to understand or implement in a new code. It’s pretty impressive that you managed to do that for a part of it!
I know, using a unit like that downstream of the Pixhawk would be a simple and effective way to get very precise and smooth reactions in flight. But at least in my particular case I don’t want to use that method, because then I can’t see anymore what the servos are actually doing. I need that for my measurements and another flybarless unit would be a black box.
But great to hear that you are working on it. Thanks a lot for your effort!
Yes, I thought that too. But in the servo monitor I can see that Pixhawk is commanding larger movements to one side than to the other. And after I changed the position of the servo arm it’s the other side than before. So it has something to do with the trims I guess.
Yes of course I can give you my current parameter file. Thank you for looking at the problem so intensively. Felix T-Rex 800 Pixhawk2.1.param (13.7 KB)
Felix,
I’ve done a little digging in the code. I believe you are right. It appears that the code does not account for the servo trim being something other than 1500. It appears this was properly accounted for in Copter 3.3.3 but a big changed occurred in that portion of the code going to 3.4 where this detail was overlooked. I need to do more checking to make sure my theory is right but I’m fairly certain based on what I’ve looked at and your report.
Thanks for bringing this to our attention.
Hi Bill!
Great news that you found the problem! So the trims I’ve set are actually something like control inputs on the specific servo? That would explain, why the swashplate stops at different tilt angles. Please let me know if I can help you with the testing or anything else.
I might send you an experimental version just so you can bench test it to see if that fixes your problem. I should have something to you in a day or two.
