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.
