Thread Tools
Aug 24, 2011, 04:57 PM
efx
efx
Rookie in training, heads up
efx's Avatar
That looks pretty neat, who sells that programmer and what's the other part you have on there with the wires on the left side of that picture?

Quote:
Originally Posted by Luvmyhelis
I have five of them and am reprogramming all of them. OlliW has great info on how to solder the board and do the bootloader, I am using the Robbebox Vs2
Sign up now
to remove ads between posts
Aug 25, 2011, 01:05 AM
as much as I can
beenflying's Avatar
Quote:
Originally Posted by cruzado
We can take some ideas from other people and from other devices...

In your opinion what does the delay parameter on the GY520?
Change the gain only on stops?
The delay in the LH GY520 had no effect on stop bounce with my 250. It appears to adjust the I gain. On the 250, with zero delay, it would oscillate on a hard pitch pump. With maximum delay the tail drifts out to the right and then returns some time later.

I'm also wondering if it's a good idea to update the PID at the servo frame rate, as this will cause issues when different servos types can be selected. Would it make sense to do this at the highest rate the processor can handle all of the time, no matter what servo type was selected?
Aug 25, 2011, 05:30 AM
Registered User
Quote:
Originally Posted by beenflying
The delay in the LH GY520 had no effect on stop bounce with my 250. It appears to adjust the I gain. On the 250, with zero delay, it would oscillate on a hard pitch pump. With maximum delay the tail drifts out to the right and then returns some time later.

I'm also wondering if it's a good idea to update the PID at the servo frame rate, as this will cause issues when different servos types can be selected. Would it make sense to do this at the highest rate the processor can handle all of the time, no matter what servo type was selected?
I thought that also, but I don't see any advantage in to update the PID and through out the PID result because in that case
we cannot update the servo everytime we update the PID (only at servo frame rate or lower).
There are also other issue. At 250Hz we update the servo every 4ms but a normal servo takes 70ms/60. Maybe this is an important detail.
Aug 25, 2011, 06:26 AM
as much as I can
beenflying's Avatar
Quote:
Originally Posted by cruzado
I thought that also, but I don't see any advantage in to update the PID and through out the PID result because in that case
we cannot update the servo everytime we update the PID (only at servo frame rate or lower).
The advantage is not having to change the kI value when the servo frequency changes. Any frequency can be used with the same value.

Quote:
There are also other issue. At 250Hz we update the servo every 4ms but a normal servo takes 70ms/60. Maybe this is an important detail.
That is the advantage of using a higher frame rate servo. You can tell it sooner to change the last position you sent it to, so faster reaction and less chance of overshooting. The worry is overheating the servo due to fast oscillation.
Aug 26, 2011, 05:22 AM
OlliW
Hey Crusado,

congrats for getting started this nice project...

maybe I could share some of my "insights" I got while working on the GA250 coax gyro mixer project
http://www.olliw.eu/2011/ga250-fpkoax-gyro-mischer/ (unfortunately only in German yet)
https://www.rcgroups.com/forums/show....php?t=1450125

Although both the rate and heading hold gyros are based on a PID (and the heading hold is essentially just adding the I term), I think one should not discuss them along the same lines but carefully separate the discussion, since not only the parameter settings would differ, but - at least IMHO - also the implementation should differ. Since nowadays few folks would use the rate mode, I myself will talk here only about issues related to the HH mode.

To that end, I think there are several advantages of increasing the PID loop update rate (and to "decouple" it from the servo update rate), which are related to the fact that the gyro sensor value is more often read with the adc.
more adc readings per sec ->
i) aliasing is reduced
ii) the effective accuracy/resolution is increased (deciphering)
iii) a simple software lowpass filter can always be (and should be) introduced to "slow" things down
iv) the D term is VERY sensitive to noise, which can be reduced dramatically with "appropriate filter" techniques

In fact, because of the D term being very sensitive to noise I guess one would not use the naive implementation as in the sample code. I myself had problems with that, and its reported to lead to problems "everywhere" else.So, I would recommend to use one of the "appropriate filter" techniques.

Quote:
In your opinion what does the delay parameter...?
This is a very good question. I could not figure out anything definitive from the resources available on the net (since almost no info as regards heli gyros exist, in contrast to the abundance of info for multicopters, which do not need delay as it seems). I would be most glad if anyone would have a competent answer here (not just the typical functional descriptions or guesses). From what it is supposed to do I believe delay is implemented as Smith predictor or some simplified version of it to account for the dead times. But as said, I would be most glad if anyone into heli gyro programmring could confirm/disconfirm that.

Have fun,
Olli
Aug 26, 2011, 08:06 AM
Registered User
Thank you very much for your opinion!

Quote:
Although both the rate and heading hold gyros are based on a PID (and the heading hold is essentially just adding the I term), I think one should not discuss them along the same lines but carefully separate the discussion, since not only the parameter settings would differ, but - at least IMHO - also the implementation should differ. Since nowadays few folks would use the rate mode, I myself will talk here only about issues related to the HH mode.
I agree with you. The HH mode is the most important (and difficult) part. The rate mode is just a "nice to have" feature. We should focus the HH mode part.

Quote:
iii) a simple software lowpass filter can always be (and should be) introduced to "slow" things down
Is your advice to increase ADC sample rate just to feed a low pass filter and only feed the PID when we gonna to update the servo?

Quote:
iv) the D term is VERY sensitive to noise, which can be reduced dramatically with "appropriate filter" techniques

In fact, because of the D term being very sensitive to noise I guess one would not use the naive implementation as in the sample code. I myself had problems with that, and its reported to lead to problems "everywhere" else.So, I would recommend to use one of the "appropriate filter" techniques.
I've read somewhere about this issue but as I said this first version is just a good starting point and I couldn't get yet debug data in real time to analise (I'm waiting for a bluetooth device).
Do you have some references about that "appropriate filter" or some code example?
Aug 28, 2011, 09:18 PM
as much as I can
beenflying's Avatar
Quote:
Originally Posted by cruzado
In your opinion what does the delay parameter on the GY520?
Change the gain only on stops?
Delay is a time delay filter of the feedback (MEMS level) to the PID. For example, the raw value would be no delay, and the value averaged, would be the delayed value. Effectively an RC on the MEMS output.
Aug 29, 2011, 05:36 AM
OlliW
OK. You claim to know the correct answer, so - for a moment - let's talk serious.

What reasons do you have to believe that this is the correct answer? What is your evidence? What is/are your source/s of this information? ...

Why and how does it do what the "delay" function is - according to the manuals - supposed to achieve?

"delay" is to you a filter delay?

Olli

PS: I think you are just guessing here, and I think it's nonsense, hence my "serious" talk... but I may of course be wrong...
Aug 29, 2011, 09:09 AM
Registered User
Hello, i'm interested in your project cruzado. I dont know almost nothing about programming risc or even c. But i'm learning since i have the time and i know a little about pid, since i use them for furnace temp (that have to be ~1 degree of error in 1000c)

Maybe and i m just guessing that delay is a simple way to soften the noise from the raw data from gyro sensor. That way you can make changes every let s say 4ms.
Imagine the sensor send data at a rate of 1/.1ms.
Delay 0 would mean all data from sensor is analized ( a lot of work for the processor). Putting a 1 ms delay would mean you do an average value of ten data from sensor. You smooth the data that way and perhaps less error end less creeping of servo.

Just an idea anyway.

Have a nice day.
Aug 29, 2011, 12:42 PM
Registered User
I've been reading about Smith Predictor and Predictive PID and I found it very interesting but also not easy to understand all the theory.

Now I can change PID parameters and get debug information in real time. I have the bluetooth device connected to the gain connector and it's working. Next days I will try to adjust better the PID parameters. I will test also some simple filters for the Derivative part and for the Delay.
Aug 29, 2011, 04:08 PM
OlliW
you also might wish to test setpoint weighting (for both the P and derivative part). This can also be considered a 2DOF controller, which allows you to set independently the repsonses to a disturbance (wind etc) or a setpoint change (rudder stick), and is also related to feed forward. I am convinced that for a heli this will allow you to significantly improve the overall performance (although I have no "proof" as to yet).

Olli
Aug 29, 2011, 04:31 PM
Registered User
delay is a rather unspecific approach to deal with a not-ideal servo. I wonder, if there is a better approach. Maybe by creating a profile for each servo-type and upload it to the gyro?
Aug 29, 2011, 06:37 PM
as much as I can
beenflying's Avatar
OlliW, this was the information one of my engineers gave me. He has been doing motor speed controllers for over 20 years (not gyros).

Good luck, cruzado, but my time is better spent elsewhere for now.
Aug 30, 2011, 12:49 AM
OlliW
Quote:
OlliW, this was the information one of my engineers gave me. He has been doing motor speed controllers for over 20 years (not gyros).
many thanks for this information, but I wonder, since I found that in the context of motor speed controllers, are you talking about what's (also) called a "lag compensator"? (maybe you can double-check with your engineer)
Last edited by OlliW; Aug 30, 2011 at 12:56 AM.
Aug 30, 2011, 01:09 AM
Professional heli wrecker
Luvmyhelis's Avatar
Quote:
Originally Posted by daybyter
delay is a rather unspecific approach to deal with a not-ideal servo. I wonder, if there is a better approach. Maybe by creating a profile for each servo-type and upload it to the gyro?
That would take some fairly extensive research to document each servo. Are you suggesting to upload all of them into the very small memory of the Ga250 or just individually during setup? The latter would make sense. And cruz, your bluetooth combo is very cool! Keep up the great thread guys. With OlliW here I have no need to comment further. I respectfully bow at the feet of the true master here.


Thread Tools

Similar Threads
Category Thread Thread Starter Forum Replies Last Post
Discussion Firmware for the KK Micro by JussiH or other KK's using the IDG500 gyro kapteinkuk Multirotor Drone Talk 22 Oct 31, 2011 08:03 AM
Help! Assan ga250 gyro setup TubeBarHeli Electric Heli Talk 1 Jul 01, 2011 01:08 PM
Sold Turnigy DS480 servo + GA250 MEMS gyro flying4food Aircraft - Electric - Helis (FS/W) 3 May 15, 2011 05:37 PM
Discussion Another newbie video from CRUZROY on the ASSAN GA250 GYRO'S cruzroy Mini Helis 2 Apr 27, 2011 09:42 PM
Question HK GA250 Gyro: Servo settings. bamm 3D Electric Heli Flying 5 Apr 08, 2011 07:58 PM