Searched and searched and haven't found much info on getting the tail to work on a TH. Just completed an install yesterday on a T500 and while the MR appears to work reasonably well the TR just wags back and forth and no amount of gain adjusting seems to make a difference. I read that the developers feel the tail now works properly so I'm looking for the hints on what to do to achieve that.
The "Gain" setting on the Setup page seems to do nothing. Is that only for an external gyro? Is the check box for an external gyro? I couldn't get the tail to operate at all without checking that box.
Also, how to set the tail mode separate from other axis. For normal helicopter operation you'd want either acro(rate mode) or stabilize(self leveling) for the MR and heading mode for the TR. How to do?
I spent some time browsing the source code last night (which amazed me at it's simplicity) but didn't come away with any revelations.
I have the system installed on a T600 with no external gyro, and the system works pretty well.
I think there's a checkbox for the external gyro in the setup page, but I'm not positive, I haven't used it. Last time I looked at that it could only be toggled in CLI mode.
You can't set the tail mode seperate from the others with the stock code. Could probably be modified, but it's not a priority. So at this point, if you're in stabilize, you get "heading-lock-like" gyro operation. And Acro mode really doesn't work for helis, so you're pretty much stuck with heading lock mode.
I have to imagine your problem with tail wagging has to do with your gains. And yes, they do work. It's kind of tricky because you have to tune the yaw rate PI and the yaw stabilize PI loops. I'd suggest zeroing out the stabilize PI terms, and work on the rate PI first. Like this is will work like a non-heading-lock gyro. So you get that stable, and then start working on the stabilize PI.
I'll try to get my values and post them here so you can see.
In my experience, without an external gyro, it works really well. Really well. I only have a small hickup at this point which is that if I input left yaw, it jumps to the right a few degrees before starting to yaw left. I'm trying to figure that out. I'm pretty sure it's something in the code.
I wasn't implying that it doesn't work well I just haven't been able to get it to work. ;-) Heading lock mode is good. Don't need more than that. I'm quite sure the the tail wagging is a gain issue however, on the setup page there is a checkbox for "Enable Gyro". Unless I check that box the tail doesn't even work. If I check the box it clear that it's working (I've built tens of TH's so I do know) but it wags. This said "gain" to me. There is a gain value below the "Enable Gyro" which defaults to 1000. Changing it from 300 to 1300 makes no difference so this tells me it must be for an external gyro but I'm puzzled by the check box (which was why I was looking at the code - to figure out what the check box does - I used to be a software engineer in another life).
Anyhow, I'm sure it's merely an operator error on setup up. Guess I should dump the mission planner and do setup in the terminal.
Yes, your values for the 600 would be an excellent starting point for me! It might be easier for you if you could just send me the whole parameter file.
Thanks so much,
What is going on? I could swear I made a post last night and uploaded a screen shot of my setup in APMP.
I'll have to try again.
What exactly is "TH"?
Now, it says unless you check that box the tail "doesn't even work". What exactly do you mean by that? The tail control will feel a bit peculiar to those used to external gyros.
First, the tail servo will never move if the throttle is at the very bottom. It's a safety thing for quads, we're going to try and fix that. So, disconnect your ESC and try throttling up.
It's also possible that when you're in Stabilize mode, if Stabilize_Yaw P and I terms are zero, it might not move if you input some rudder stick. It may still respond if you push the tail around however. I haven't actually tried that test.
Ok, I'll try this. Here is my Parameter file.
The gain value you see below "Enable gyro" in APMP's heli set-up screen simply outputs that gain value (1300) on output channel 7 so that you can connect an external gyro's gain channel to it. You can try connecting a spare servo to channel 7 and try modifying that gain value and you'll see the servo moves. How to wire up the gyro is in the image on this page.
Re the wiki (discussed on another thread). You're probably right that we should update the wiki to show how to do the set-up using the AP Mission Planner instead of the CLI. I alwasy use the mission planner these days.
I can handle the wiki for you Randy. I just have to figure it out for myself first since I haven't really used it since I did my setup months ago.
Hmmm... well, are you supposed to use an Ext.Gyro in tail hold mode with the AC2 code, or are you supposed to run it in rate?
Either way, I'm not that surprised to hear this description. I think what is happening is that the heading hold function in AC2 is trying to send signals to the gyro to tell it to move the tail back to the set heading. It's almost like it assumes the HH gyro hasn't done it's job. I'm not sure though, just a guess.
Try my settings and report back.
I'm on the road now but I may be able to try this on Saturday or Sunday. I'll let you know. In the meantime I want to come up to speed on the source code and may be able to make some useful contribution there.
Ok, if you think you can contribute, you might want to ask Chris Anderson to put you on the Dev Team mailing list. Randy is the only dev guy really working on TH. I'm trying, but I'm a mech.eng. and I'm a bit lost with the code. I get the basics but once you start talking about "object oriented" I'm totally lost. ;)
It would be great to have somebody else on the TH team, as Randy has been working on some other projects lately. (Optical flow). I'm trying to do a few things in the code, mainly at this point solving a problem we have where the upper and lower limits of swash movement are absolutes. So if you are at full pitch, and then try to roll, none of the servos move up any more, only the relevant one can move down. So it limits the control authority at the pitch limits. I'm trying to break it out so that the swash limits only apply to collective, but still allow pitch and roll inputs to fully tilt the swash. I'm also working on getting our equivalent of "revo mixing" working properly.
If you want to surf the code, start by looking at attitude.pde and heli.pde as that's where the bulk of the "flying" part is done.
Yes, was looking at those files last night....
There are at least a couple of different strategies for what you are trying to do. I'm quite familiar with how SK720, VBar, and BeastX handle it. I need to get a bit more familiar with ArduCopter code though - and am doing that in my spare time.
If you know how the others work, it would be super helpful. Currently Acro mode doesn't work at all. Basically, with low values for PI, the helicopter is almost dead in the air. You can't get it to move. As you increase the P term to try and get some response out of it, but you end up with severe oscillation on the swashplate before you ever get the desired motion. You have to choose between almost no swash motion, or death-wobble.
My theory is that our problem is the Acro mode uses the gyros to try and sense rotation rate. But since the rotor head is the source of most vibration, and the disk is well above the CG, that the rotor disk imbalance results in angular accelerations that the gyros pick up, and cause the swash servos to over-react.
I just sent an idea to Randy today on another way to handle this. Instead of controlling roll and pitch rate with the roll and pitch gyros, use the accelerometer direction of virtual Z instead. Similar to the way stabilize works. Currently, full up pitch stick in Stabilize requests the heli to pitch forward 45° and hold there. In acro, why not just use the pitch stick to request the virtual Z angle to move at a speed proportional to the stick movement. That way the accelerometers sort of automatically filter out the vibration accelerations.
We know that stabilize works. We would basically just make Acro into a rate stabilize, instead of looking directly at the angular accelerations.