Heading Hold for YAW

[VladZ]

I am trying to implement HH mode on my TriWii... well, it kind of works. Not like commercial gyros but in my opinion better then just rate yaw control.
(just for reference, I am flying CP helis for around 3 years).

Well, if someone saw somewhere on INTERNET algorithms for HH I would appreciate URL.

[Alexinparis]

I think the yaw command response could be improved.

for tri:
There is currently a small smoothing function on yaw gyro to avoid too small movements on the servo.
I suppose it does not help the HH precision, it's a compromise.

for quad:
there is still a yaw jump sensation I managed to reduce is the last dev version, but still present.

[VladZ]

yes, I saw some ideas for quad... basically this jump sensation happens because upwind and downwind have different times. I mean, motor accelerate faster then decelerate. And this depends on different factors.

So, with the YAW command couple motors that should speed up will get up to the rpm faster then opposite pair who should slow down - so quad will jump...

BTW, I think that some corrections on down/up winds should also help for general stability.

Well, HH mode - it's kind of control when copter is trying to keep YAW direction on it's own even when rpm/torque got changed due flight progress or due wind gust etc. I have no problem to keep YAW direction with rate mode but with "commercial grade" HH gyro it's totally different ball game. Though I understand that there are serious R&D involved in order to develop such software.

I'm still working on my HH implementation but if anyone interested I can post it here for suggestions and critics.

[Centurian]

The "I" in the pid settings is "heading hold"

What is needed is a faster update rate for digital servos.

I'm using a cheap 401 clone w/digital servo on my tri and it's a vast improvement..... but I works best for me in rate mode rather than heading hold... the yaw response time and yaw inertia on tri's is not very compatible with heading hold as configured in helicopter gyros. With multiwii software support for digital servos, heading hold performance might PID tune better yet than a seperate gyro.

[Alexinparis]

@Centurian

I'm not sure it is a servo update rate problem.
You can try to de activate the smoothing function on yaw
Just remove:

Code: Select all

  gyroData[YAW] = (gyroYawSmooth*2+gyroData[YAW]+1)/3;
  gyroYawSmooth = gyroData[YAW];

It should improve the response, but with many glitches.

I'm sure it's possible to support what you like with a real gyro.
Could you explain more your observations ?

[VladZ]

'i' is kind of HH but pretty simple implementation.

Well tuned and modern classic heli's HH gyro should give "rock solid" tail authority. Meaning, without stick input, tail will stay put regardless of different torque due to maneuvers or external forces like wind gusts etc. So, pilot could concentrate on 3D pilotage more and not on keeping the tail in desired position.

Of course, there are differences in between multi-copter and helicopter YAW controls. And I don't think that using digital servo or higher update rate would benefit tri-copter YAW control as greatly as helicopter's.

Heli tail reaction is much faster due to low latency (changing pitch on blades vs. pivoting motor or changing rpm on motors) and greater efficiency (more authority, utilizing prop thrust in more efficient way vs as of tri-copter pivoting motor or using difference in torque as for quads). So it will benefit using shorter control loop.

Btw, removing filter will help reduce phase delay in control loop, make it shorter, though I am not sure if this would be noticeable better then before. Filter helps to fight vibration and other high frequency noise but it adds latency in control loop and can make control nonsensitive to valid gyro input.

[Centurian]

@Centurian

I'm not sure it is a servo update rate problem.
You can try to de activate the smoothing function on yaw
Just remove:

Code: Select all

  gyroData[YAW] = (gyroYawSmooth*2+gyroData[YAW]+1)/3;
  gyroYawSmooth = gyroData[YAW];

It should improve the response, but with many glitches.

I'm sure it's possible to support what you like with a real gyro.
Could you explain more your observations ?

Hey Alex,

I've been trying to catch up on this project, have so many things going on, my original tri, a y6 that the props came for today, a 2nd hand quad I got yesterday, tyring to fully understand PID tuning, trying to learn about video tx/rx & cameras so forgive me if I can't tell you exactly how I arrived at the decision to use a seperate gyro.. as I recall the servo when hooked up to the arduino is very knotchy at a low frequency(why use a digital servo @ 50hz?) which indicates to me the update rate is slow and the resolution is pretty low. I will admit I didn't put a lot of effort in tuning the wii pid's, but was never really satisfied with how the yaw response and hold was working. Anyway, I had 4 cheap 401 clone gyros laying here from my original non-wii tri so I put one on the yaw servo. The yaw gyro is connected to the arduino output because I was too lazy to change my receiver wiring(that was the next step if unsatisfied. The arduino needs yaw input to arm & program, so a Y cable could be used between the RX & arduino.). I set the arduino PID's to 0,0,0. I first tried the the gyro in heading hold and from what I recall, the intergral was too large for the tail response and would cause a large overshoot and rebound on a yaw stop from a high rate. I then tried in rate mode and can run the gyro at maximum gain with no noticable feedback. Now the yaw feels locked in, no drifting around. Accelerations are slow both starting and stoping but I think that's due to the amount of yaw authority available and yaw inertia but there is no rebound. Tri's don't have a tendency to point into relative wind due to their symetrical drag profile, so heading hold isn't really necessary anyway.

All that being said, I think that a high frequency yaw servo output(why not update the servo with the speed controls?) would be a huge improvement and allow for better PID tuning than choosing from 2 realtive sets preprogrammed in a heli gyro. Obviously, this would have to be an option in the code so non-digital servos would still be supported.

Given time and weather, I'll test your suggested code change and let you know.

Once again, Alex, a great big thank you for all you've done, this project amazes me on many levels. There is no better bang for the buck that I know of.

I hope to get more up to speed on the whole project in the near future and be of more help!

Doug

[VladZ]

Centurian,

If you want to try faster update rates for YAW servo you can do it by reducing value of count variable like this:

ISR(TIMER0_COMPA_vect) {

......
} else if (state == 2) {
PORTD &= ~(1<<3);
count = 16; // 18 x 1020 us <=== this is for 50Hz update rate, if you want faster updates then reduce 16 down to whatever your servo can handle.
state++;
OCR0A+= 255; // 1020 us
} else if (state == 3) {
------

I would suggest start with count = 8, so your update rate would be around 100Hz and your controller would not feel too much of interruptions.

I am looking forward to your testing reports.

[Centurian]

I dropped count to 3 as the GY401 outputs 270hz, seemed like the right value. I also removed the smoothing per Alex's suggestion as well. I would say it's almost as good as the gy clone at this point. I made a hat cam today and here's a little video I played around making:

http://vimeo.com/19152816

This is PID 11/0/0 on yaw, holding pretty well.

[bradleyk]

i would recommended increasing i to at least 0.001

but it look very good

[VladZ]

Well, interesting... I did not think that digital servo can provide significant improvement in YAW control but now, thanks to you, it looks like it does.

[Alexinparis]

I dropped count to 3 as the GY401 outputs 270hz, seemed like the right value. I also removed the smoothing per Alex's suggestion as well. I would say it's almost as good as the gy clone at this point. I made a hat cam today and here's a little video I played around making:

http://vimeo.com/19152816

This is PID 11/0/0 on yaw, holding pretty well.

Do you think it's better because of the refresh speed increase, or because of the smoothing removal ? or both ?

[Centurian]

alex,

I put the smoothing back in today and can't really tell a difference. Isn't this smoothing the result of a I2C Issue that will be taken care of in the next release?

I do think that digital servo support is important, why refresh ESC"s at high rate and just let the tri yaw sloth along??

I posted @ RCG about PID tuning... Just today, I finaly really understand all 3 terms, I think a lot of what I have experienced is based on my learning PID tuning.

Keep up the good work!!!

[JollyJoker]

I just finished some tests with different digital servos:
MPX/Hitec, Hyperion, BMS/Turnigy, they all manage to work even on a ESC output of the arduino driven by 490Hz! Some are knurring a little, other are as quite all the same behavior as driven by 50Hz or 270Hz (HK401Gyro). So there should be no reason not to drive a digital servo also with 490Hz

So i would greatly welcome a digital servo mode with full 490Hz output. As a rise from 50Hz to about 100Hz gives a better tail-steadyness (and much less wobble in fast forward!), especially with my 3-Servo solution.

Thanks for audience.

Regards Peer

[JollyJoker]

Hi Alex,

is there a chance of getting a version of the code, which is driving the servo for the tri (three in my case) with full 49ß0 Hz output?
Can you advise me how to change this. My full tilt copter does greatly improve yaw stability with every HZ i could gain. Now at 110Hz the end is reached with the count variable set to 1.

Regards Peer

[Alexinparis]

Hi,
In the last version I use the same loop to drive up to 4 servo, and it's impossible to increase the Hz loop at 500Hz.
I must separate the yaw servo code for this. It's possible with some code adjustment. In the next dev.

[JollyJoker]

Thanks for this information Alex,

i thought it would be easier. My idea behind was, just to treat the yaw-servo like an esc - for the generation of the pwm-pulse. So if this doesn´t work then i don´t want to make circumstances. I don´t had in mind that with this new release there are 4 servos to deal with - of course - the camera stabilisation.

Regards Peer