Bill,
There were definalty 4 times i lifted it off the ground and hovered for a min or two along with a quick weighted down spool up after adjusting the throttle setup. Hmm, im going to have to see if i can figure out which is which?
I have too many logs in the Pixhawk and on the computer at this point, logging while disarmed is all well and good, but is creating too many files during bench testing.
I slowly bumped up the P gain each flight to about .1 from .04. I will say it flew better than i expected after looking at other first time heli videos? I had to constantly correct it but still had no problem keeping in a box.
Im thinking ill drop a degree off the collective limits at either end and flatten out the middle a tad, i dident have issues with pogo-ing but it was definatly too sensitive for carrying a camera.
Also ill have to figure out the horizon issue? It wasent bad by any account, but still felt like it was trying to level itself to an un-level horizon. Im assuming this is the ālevelā parameter that is below the ācalibrate accelsā button in Mission Planner? Tracking looked good in flight and im quite certain the head is at 90Ā° throughout, ergo the swash is level. To me it felt like fighting the accelerometers in a BeastX Pro with self level mode engaged before you trim it?
Hopefully a few more flights and im up to .2ish with the P and some I makes it feel a bit better.
The tail certainly needs work, although not alot. I was quite suprised how well it held considering I just plugged in Chrisās numbers and admittedly dident put any counter thrust on tail pitch, its rougly centered. If im understanding the available information correctly Pixhawk is a system that likes some counter pitch on the tail at neutral? My experience lies with FBL controllers and some like counter pitch and some want a neutral setup throughout to lock in the tail and get bounceless stops as well as no blow out on higher speed backwards flight etc. But id say its good enough to not worry about until the P and I gain are set on the head.
Tim
Chris,
Yeah, im definatly going to up the headspeed a bit, its certainly not in a sweet spot. Not alot, but some. Im glad to hear there were no major vibration issues though, ive been wondering for awhile how the Pixhawk 2.1 strapped down to the side of the frame was going to pan out?
At some point im going to have to figure out what constitutes acceptable vs bad vibrations as currently it just looks like a messy graph when i look at it?
Thanks for the tail settings btw, for a first few flights it was pretty solid. It does hunt a tad the moment i lift off, but nothing crazy. Ill likely play with it more once the P and I gains for the head are more tuned.
Tim
Going from memory here, it was trying to head to the right and forward a bit. Were not talking alot, but i definatly felt like i was holding a constant correction in there to keep it from heading off in the same direction. I noticed it on the last two hovers the most as the wind wasent a factor then.
The only way i have to describe it is comparing it to an FBL that uses accelerometers to self level and the way they act before being trimmed properly.
Tim
Tim, there is AHRS trim params for x and y to compensate for the FC board not being perfectly true with the mainshaft. Positive values on those will make it drift right and nose up, negative the other way. I always adjust those to get my heliās to hover hands-off in no wind in Stabilize.
Those trim params are radians, so .017 radians = 1 degree of trim.
Chris,
That sounds like what i am looking for. Its not alot weāre talking about, but seeing that i got a couple good hovers in with no wind it was evident that some kind of trimming needs to be done.
Tim
I must say im glad the first flight is over now though. Always worry too much before a maiden, especially this one as I had no clue what to expect from the unit. Very happy it dident eat itself on the front lawn.
Now i can move forward with a little confidence at least.
Tim
They are called AHRS_TRIM_X and AHRS_TRIM_Y. There is usually some values in there that the were calculated (I think) during accel calibration. But Iāve always had to adjust them.
There is another trim param as well called ATC_HOVR_ROL_TRM that is set to 300 (3 degrees - not radians here) by default that is designed to compensate for tail rotor side-blow. I think the idea behind that is that is if you adjust the AHRS trims, with the ATC_HOVR_ROL_TRM set to zero, then the tracking of desired roll vs actual will be off with a helicopter. So for roll trim it is probably best to adjust the AHRS_TRIM_X with the hover roll trim set to zero, then look at the logs. If there is a 3 degree discrepancy between desired roll and actual, then adjust the trim x by that 3 degree and enter that compensating value into the ATC_HOVR_ROL_TRM to get it to hover hands-off again.
There is no documentation on this anywhere - it is something I have figured out by trial and error. And I donāt know if itās the right way to do it, but itās what I have been doing and it seems to work.
Chris,
Thanks for the info, i think that all makes sence. Unfortunatly as its back to Seattle style weather here and raining, ill be grounded for the immediate future and will have to wait to implement any changes. Uggh.
Tim
Bill, I sure wish I understood better how that all works. I attached a BIN file from an Auto flight that I did some time back. I donāt remember the details but I think it was a 3-4 mile flight at about 25 mph. Flown with the 600. This is a flybar so there is no I-gain.
The difference between desired and actual is pretty big on the ground, but thatās due to the heli sitting on unlevel ground (I think). As soon as I take off it narrows up but itās still a degree off or so for the entire flight. Same on the pitch axis. That helicopter flies so nice and accurate it would be hard to improve on it with anything. But I still think that discrepancy has to do with the AHRS trims that I set to make the heli hover nice may not be exactly what the flight controller thinks it should be, and it looks to me like itās off by about the amount the hover roll trim is set to. And even though this is a flybar, my DFC head helicopter shows the same phenomenon in the logs.
Chris,
I havenāt spent much time understanding how the flybar mode works in stabilize as well as auto ( which should be similar to stabilize). So it sounds like you can still use the PID controller but at a minimum you need VFF to be able to control the heli. So in auto or stabilize the attitude controller is feeding commands to the PID controller, which is essentially VFF only in your case. The attitude controller is trying to null attitude errors but it could be that the gain, VFF in this case, is not strong enough to zero the attitude error and you end up carrying some bias. This is where the PID controller is used, specifically the I gain, to zero the attitude error and gives better tracking of commanded to actual.
I wonāt have time today to look at your flight today but thatās my thoughts on what you describe. Hope that makes sense.
I can use I gain with a flybar but it doesnāt make any difference. The flybar is a mechanical rate integrator and it does itās job very well. I think in flybar mode the rate integrator in the PID controller is āfrozenā or disabled anyway.
So myself, I donāt think it has anything do to with the rate controller. If it did, it would seem that there would be error on both sides of the desired. But since it seems to track consistently on only one side, I think itās an issue with trim. I might have to play with this some more and see if I can figure it out. Other folks have asked about trimming their helicopter for drift one way or another, and I recite my method, which may not even be right. But I know it works even though the logs show that ~1 degree difference between desired and actual attitude.
Now, the yaw doesnāt show that at all. Only pitch and roll. So Iām going to have to make some AHRS trim settings with the hover roll trim turned off and see if I can experiment and get them to be the same. And then see if I can still get the helicopter to hover hands-off in Stabilize.
The flybar does not do the same thing as the I gain in the PID controller. The flybar works on the gyroscope principle that when a rate is applied to it, it opposes the rate, not attitude. Now the flybar can be set up very sensitive to rate and thus make it seem like it is holding attitude. I donāt know but I suspect your flybar is setup to be very sensitive (more weight on flybar) to rates this provides more stability. . I think your attitude error only occurs in one direction because the attitude controller is seeing a bias and either the ATC_ANG_XXX_P can be increased or use the I gain to decrease the bias.
By the way, you can use the PID controller in stabilize mode. It is bypassed in acro.
I guess I got that from what Rob had written long ago about how it works - down near the bottom of the page:
So the second big thing Flybar_Mode does is that it makes the Rate I term only āactiveā near zero rate command. It wonāt move whenever youāre asking the heli to move. It will only move the Integrator, basically in a hover. So itās sort of like an auto-trim for hover. Whenever you are moving the sticks, itās frozen. Again, I did that because I didnāt want the Integrator doing whacky things to the flybar, because the flybar and the rate integrator do the exact same thing, but neither one of them knows what the other is doing!
So what happens is that when the pilot (or autopilot) makes a control input to the swashplate we now have the same effect as a huge I-term buildup. That control input only changes the flybar paddle pitch. The flybar changes its plane of rotation because of the paddle pitch. This acts on the main rotor blades thru the washout/mixing arms and linkage. With the result that the main rotor is forced to assume the same plane of rotation as the flybar. As it does, the flybar goes back to equilibrium and the mechanical I-gain āleaks offā just like the rate integrator in the software for FBL. With one difference - the leak rate of the flybar is infinitely variable and leaks off at the precise rate to prevent over-shoot of the target. The I-gain and leak rate of the software integrator is fixed.
The flybar is also a damper, replacing the P-gain in the software rate controller. The pilot can make the control input to the swashplate as fast as he/she wants and it will be damped by the flybar, adjustable with paddle weight. The mechanical integrator can be adjusted with paddle pitch.
This is why I still think that desired vs actual discrepancy in the logs is due to trim, and not the rate controller. The rate controller PID loop is totally bypassed with the VFF it takes to fly a flybar heli, and yet that discrepancy is still being logged. The reason it never hits desired is because, due to mis-trim, if it actually does the helicopter takes off in an undesirable direction. Iām going to see if I can tune it out with trims. That may help Tim with his if I can come up with a way to do it.
Bill, Iāve studied the history and development of it. Because I consider it one of the most ingenious inventions ever put on a helicopter. The Bell-Hiller mixing head was what made early RC collective pitch helicopters even possible. A few adventurous souls tried flybarless back in the day, but they flew them either hiding behind the truck, or carried a garbage can lid.
I think I was on the right track with how to get rid of that logging discrepancy. I flew a short test hover and got the same thing Iāve been noticing:
It is a cool invention. So would you agree that a stab bar (essentially a flybar without paddles and just weights on the end) works on the same principle as a gyroscope and as such resists rates only. I believe you said you flew the H-13? which used a stab bar for stability. The bar without paddles was designed not to be affected by wind gusts and remained in its plane of rotation and as the aircraft was disturbed made inputs into the blade pitch to oppose the aircraft rotation rate. And it also opposed angular rates due to pilot inputs as well.
From what Iāve read, the flybar was designed to reduce cyclic control loads. As you pointed out the pilot is flying the paddles which in turn changes blade pitch. This is ingenious because not only does it reduce control loads, it also moves the plane of rotation of the flybar since the inertia of the bar wants to stay in one plane of rotation.
And I agree with this.
Iām not sure what you mean by this.
So are you increasing pitch on the paddles in the same direction? Essentially your are effectively adding collective to the paddles and thus creating thrust with the paddles? This is a preset adjustment that canāt be changed in flight, right?
Iām not saying it is the rate controller causing the discrepancy. I thought it was the attitude controller not being able to completely null the attitude error. Iāve looked at the code and I still donāt believe in stabilize mode that the PID loop is bypassed. I definitely see that in acro both the attitude and PID controller is bypassed.
So it looks like you figured it out for your flybar heli. I think this is different for what Tim is encountering and in your case with the DFC head heli. In my opinion, the I term with a non zero ILMI should reduce the error to zero between the commanded and actual. I believe that the I term with ILMI =0 does not null that error because the integrator leak is too fast.
I flew the Bell 47, which was the commercial result of the prototype Bell 30, designed by Art Young. It was Stanley Hiller that put paddles on it, aka the OH-23 Raven that flew from the 40ās thru the Korean War. It became known as the Bell-Hiller mixing head, and is still used today in some designs like the Yamaha Rmax and Fazer.
Yes, with a flybar head you can set the static paddle pitch. Most set them at zero in relation to the flybar cage so the flybar is āneutralā. But adjusting them to 1 or 1.5 degrees provides the same effect as more I-gain in a software rate controller. It causes a larger displacement of the flybar with swash input, and resists changes to the plane of rotation of the flybar when there is neutral swash input. The old timer who taught me to fly RC heliās and how to set up a flybar, showed me that you can set the paddle pitch to 5 degrees and put the helicopter in hover with a rope tied to a skid. It is so stable that you can pull on the rope and the helicopter will fight it and doesnāt want to move. And this is just a straight flybar with no GPS or gyros.
Itās not bypassed in the code. But itās turned off with the params with rate P, I and D all set to zero. I think this is the same setup that people that are using FBL controllers with Pixhawk are using. They set H_FLYBAR_MODE to 1, turn off the rate PIDās and turn up the VFF. That lets the external FBL unit do itās job, just like a flybar.
I am going to try the same experiment I did this afternoon with the flybar, with the DFC heli and see what it does. The way I set those up before is to level the helicopter using my digital pitch gauge so the mainshaft is vertical. Then adjust the AHRS trims to get zero pitch and roll shown on the screen in the ground station. That method may not be quite accurate enough. I did definitely determine, at least with the flybar, that the discrepancy is related to those trim settings. I think there is some other dynamics there at play in flight, using the EKF state estimator for attitude. And if what the EKF state estimator thinks is desired, but actual is slightly different because of the trim value, then it shows up in the log.
Thatās my theory, anyway. Iām going to check it out with the DFC heli and see if itās the same result as I got with flybar. It seems that almost everybody that posts logs will have that discrepancy and problems with drifting. It would be kind of nice to figure it out, because itās not documented anywhere in helicopter tuning.
