RPM Governor in R/C Helos
Archiver
Posts: 46,084
Howdy group,
I know others have tried this, but now its my turn.
As part of a larger system, I'm using a BS2SX Stamp in a radio
controlled helicopter connected to the engine throttle. For
helicopters to fly, their main rotor blades must be spinning at a
constant speed, with only their pitch changing. When the pitch
changes, torque is added or taken away from the engine, needing the
throttle to be adjusted accordingly.
My plan is to clock the RPM in with a hall-effect sensor. A software
preset RPM speed represents the target speed that should be acheived.
Then its up to the Stamp to decide if more or less throttle is needed
to reach the goal.
I'm figuring a psuedo-logrithmic calculation in the difference between
the actual and preset speeds is a ratio to servo movement for the
throttle. Big RPM difference = Big servo movement, etc. (Ok, so maybe
not log, but more like proportional, but that's for you mathemeticians
to figure out!)
I have yet to try it, but one potential problem I've heard about is
that the Stamp is actually too fast for this. The RPM range we're
dealing with is around 1500 RPM. At that rate, the Stamp will have
calculated far beyond that reading, and by the time physics catches up
(remember a leg between adding throttle and seeing the RPM difference)
can lead to "pumping" of the throttle.
What about taking an average of RPMs and working out some in-between
servo command with a "wait and see" loop?
Thanks for any help. I'll have the code up ready for download soon at
http://flyheli.cjb.net under that ACAMS section.
-Doug
I know others have tried this, but now its my turn.
As part of a larger system, I'm using a BS2SX Stamp in a radio
controlled helicopter connected to the engine throttle. For
helicopters to fly, their main rotor blades must be spinning at a
constant speed, with only their pitch changing. When the pitch
changes, torque is added or taken away from the engine, needing the
throttle to be adjusted accordingly.
My plan is to clock the RPM in with a hall-effect sensor. A software
preset RPM speed represents the target speed that should be acheived.
Then its up to the Stamp to decide if more or less throttle is needed
to reach the goal.
I'm figuring a psuedo-logrithmic calculation in the difference between
the actual and preset speeds is a ratio to servo movement for the
throttle. Big RPM difference = Big servo movement, etc. (Ok, so maybe
not log, but more like proportional, but that's for you mathemeticians
to figure out!)
I have yet to try it, but one potential problem I've heard about is
that the Stamp is actually too fast for this. The RPM range we're
dealing with is around 1500 RPM. At that rate, the Stamp will have
calculated far beyond that reading, and by the time physics catches up
(remember a leg between adding throttle and seeing the RPM difference)
can lead to "pumping" of the throttle.
What about taking an average of RPMs and working out some in-between
servo command with a "wait and see" loop?
Thanks for any help. I'll have the code up ready for download soon at
http://flyheli.cjb.net under that ACAMS section.
-Doug
Comments
There were a lot of postings about 2-3 weeks ago regarding using the stamp
to meter tachometer pulse inputs. This thread discusses most of the issues
you are looking at. If you can't access them let me know and I'll dig them
out.
The chances are your stamp *wont* handle 1500 RPM directly - you will
probably have to use a divider chain.
Also you might need to think about hysteresis and inertia - you want your
stamp to respond sluggishly to changes otherwise even a slight change in RPM
will result in big changes of the throttle as the system *hunts* to try and
get back on track. A divider chain might help to average things out.
Lastly, have you thought about a semi-mechanical solution. Have you seen how
gasolene generators maintain their speed? They usually have a little plastic
lever close to a fan which spins on the engine shaft. As the engine speeds
up, the fan makes more wind and moves the lever away fom the fan, and closer
to the fan when the engine slows down. The lever is attached via a spring
to the throttle. The spring provides inertia, reducing the amount of
*hunting*
Whilst I'm not suggesting you use a direct attachment, you might want to
think about using a lever connected to a slider pot via a spring, and useing
the stamp to decode the rev count from that.
Regards,
Tony Wells
Original Message
From: "newsdawg2002" <newsdawg@a...>
To: <basicstamps@yahoogroups.com>
Sent: Wednesday, January 30, 2002 6:35 AM
Subject: [noparse][[/noparse]basicstamps] RPM Governor in R/C Helos
> Howdy group,
>
> I know others have tried this, but now its my turn.
>
> As part of a larger system, I'm using a BS2SX Stamp in a radio
> controlled helicopter connected to the engine throttle. For
> helicopters to fly, their main rotor blades must be spinning at a
> constant speed, with only their pitch changing. When the pitch
> changes, torque is added or taken away from the engine, needing the
> throttle to be adjusted accordingly.
>
> My plan is to clock the RPM in with a hall-effect sensor. A software
> preset RPM speed represents the target speed that should be acheived.
> Then its up to the Stamp to decide if more or less throttle is needed
> to reach the goal.
>
> I'm figuring a psuedo-logrithmic calculation in the difference between
> the actual and preset speeds is a ratio to servo movement for the
> throttle. Big RPM difference = Big servo movement, etc. (Ok, so maybe
> not log, but more like proportional, but that's for you mathemeticians
> to figure out!)
>
> I have yet to try it, but one potential problem I've heard about is
> that the Stamp is actually too fast for this. The RPM range we're
> dealing with is around 1500 RPM. At that rate, the Stamp will have
> calculated far beyond that reading, and by the time physics catches up
> (remember a leg between adding throttle and seeing the RPM difference)
> can lead to "pumping" of the throttle.
>
> What about taking an average of RPMs and working out some in-between
> servo command with a "wait and see" loop?
>
> Thanks for any help. I'll have the code up ready for download soon at
> http://flyheli.cjb.net under that ACAMS section.
>
> -Doug
>
>
> To UNSUBSCRIBE, just send mail to:
> basicstamps-unsubscribe@yahoogroups.com
> from the same email address that you subscribed. Text in the Subject and
Body of the message will be ignored.
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
some links that include PID(Proportional, Integral, Derivative) information and
examples. Also, see below, for some important terms you will need to know.
http://www.expertune.com/articles.html,
http://www.controleng.com/archives/1998/ctl0301.98/03a305.htm,
http://lorien.ncl.ac.uk/ming/pid/PID.pdf,
http://www.tpub.com/doeinstrument/instrumentationandcontrol84.htm.
PID Controller: Controllers are designed to eliminate the need for continuous
operator attention. Cruise control in a car and a house thermostat are common
examples of how controllers are used to automatically adjust some variable to
hold the process variable (or process variable) at the set-point. The set-point
is where you would like the process variable to be. Error is defined as the
difference between set-point and process variable.
(error) = (set-point) - (process variable)
The output of PID controllers will change in response to a change in process
variable or set-point.
Error: Error = set-point - PV. In auto mode, the controller uses the error in
its calculation to find the output that will get you to the set-point.
PV or Process Variable: What you are trying to control: temperature, pressure,
flow, composition, pH etc. Also called the measurement.
Proportional Band: The "P" of PID controllers. With proportional band, the
controller output is proportional to the error or a change in process variable.
Proportional Band = 100/Gain.
Proportional Gain: This is the "P" part of the PID controller. See gain. (of the
controller). (Proportional gain)=100/(Proportional Band).
Gain (of the controller): This is another way of expressing the "P" part of the
PID controller. GAIN = 100/(Proportional Band). The more gain a controller has
the faster the loop response and more oscillatory the process.
Gain (of the process): Gain is defined as the change in input divided by the
change in output. A process with high gain will react more to the controller
output changing. For example, picture yourself taking a shower. You are the
controller. If you turned the hot water valve up by half a turn and the
temperature changed by 10 degrees this would be a higher gain process than if
the temperature changed only 3 degrees.
Integral Action: The "I" part of the PID controller. With integral action, the
controller output is proportional to the amount and duration of the error
signal. If there is more integral action, the controller output will change more
when error is present. If your units on integral are in "time/rep" or "time"
then decreasing your integral setting will increase integral action. If your
units on integral are in "rep/time or "1/time" then increasing your integral
setting increases integral action.
Reset: Same as the integral or "I" part of PID controllers.
Reset Windup: With a simple PID controller, integral action will continue to
change the controller output value (in voltage, air signal or digital computer
value) after the actual output reaches a physical limit. This is called reset
(integral) windup. For example, if the controller is connected to a valve which
is 100% open, the valve cannot open farther. However, the controller's
calculation of its output can go past 100%, asking for more and more output even
though the hardware cannot go past 100%. Most controllers use an "anti-reset
windup" feature that disables integral action using one of a variety of methods
when the controller hits a limit.
Derivative: The "D" part of PID controllers. With derivative action, the
controller output is proportional to the rate of change of the process variable
or error. Some manufacturers use the term rate or pre-act instead of derivative.
Derivative, rate and pre-act are the same thing. Derivative action can
compensate for a changing process variable. Derivative is the "icing on the
cake" in PID control, and most people don't use it. It can make the controller
output jittery on a noisy loop and most people don't use derivative on noisy
loops for this reason.
Rate: Same as the derivative or "D" part of PID controllers.
newsdawg2002 <newsdawg@a...> wrote: Howdy group,
I know others have tried this, but now its my turn.
As part of a larger system, I'm using a BS2SX Stamp in a radio
controlled helicopter connected to the engine throttle. For
helicopters to fly, their main rotor blades must be spinning at a
constant speed, with only their pitch changing. When the pitch
changes, torque is added or taken away from the engine, needing the
throttle to be adjusted accordingly.
My plan is to clock the RPM in with a hall-effect sensor. A software
preset RPM speed represents the target speed that should be acheived.
Then its up to the Stamp to decide if more or less throttle is needed
to reach the goal.
I'm figuring a psuedo-logrithmic calculation in the difference between
the actual and preset speeds is a ratio to servo movement for the
throttle. Big RPM difference = Big servo movement, etc. (Ok, so maybe
not log, but more like proportional, but that's for you mathemeticians
to figure out!)
I have yet to try it, but one potential problem I've heard about is
that the Stamp is actually too fast for this. The RPM range we're
dealing with is around 1500 RPM. At that rate, the Stamp will have
calculated far beyond that reading, and by the time physics catches up
(remember a leg between adding throttle and seeing the RPM difference)
can lead to "pumping" of the throttle.
What about taking an average of RPMs and working out some in-between
servo command with a "wait and see" loop?
Thanks for any help. I'll have the code up ready for download soon at
http://flyheli.cjb.net under that ACAMS section.
-Doug
To UNSUBSCRIBE, just send mail to:
basicstamps-unsubscribe@yahoogroups.com
from the same email address that you subscribed. Text in the Subject and Body of
the message will be ignored.
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Do You Yahoo!?
Yahoo! Auctions Great stuff seeking new owners! Bid now!
[noparse][[/noparse]Non-text portions of this message have been removed]
http://www.stampsinclass.com/html_files/downloads_curriculum.htm, Industrial
Control (Version 1.1)
Experiment #6: Proportional Integral Derivative Control.
newsdawg2002 <newsdawg@a...> wrote: Howdy group,
I know others have tried this, but now its my turn.
As part of a larger system, I'm using a BS2SX Stamp in a radio
controlled helicopter connected to the engine throttle. For
helicopters to fly, their main rotor blades must be spinning at a
constant speed, with only their pitch changing. When the pitch
changes, torque is added or taken away from the engine, needing the
throttle to be adjusted accordingly.
My plan is to clock the RPM in with a hall-effect sensor. A software
preset RPM speed represents the target speed that should be acheived.
Then its up to the Stamp to decide if more or less throttle is needed
to reach the goal.
I'm figuring a psuedo-logrithmic calculation in the difference between
the actual and preset speeds is a ratio to servo movement for the
throttle. Big RPM difference = Big servo movement, etc. (Ok, so maybe
not log, but more like proportional, but that's for you mathemeticians
to figure out!)
I have yet to try it, but one potential problem I've heard about is
that the Stamp is actually too fast for this. The RPM range we're
dealing with is around 1500 RPM. At that rate, the Stamp will have
calculated far beyond that reading, and by the time physics catches up
(remember a leg between adding throttle and seeing the RPM difference)
can lead to "pumping" of the throttle.
What about taking an average of RPMs and working out some in-between
servo command with a "wait and see" loop?
Thanks for any help. I'll have the code up ready for download soon at
http://flyheli.cjb.net under that ACAMS section.
-Doug
To UNSUBSCRIBE, just send mail to:
basicstamps-unsubscribe@yahoogroups.com
from the same email address that you subscribed. Text in the Subject and Body of
the message will be ignored.
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Do You Yahoo!?
Yahoo! Auctions Great stuff seeking new owners! Bid now!
[noparse][[/noparse]Non-text portions of this message have been removed]
Original Message
From: Chris Loiacono [noparse]/noparse]mailto:[url=http://forums.parallaxinc.com/group/basicstamps/post?postID=lV5fsHm3czSelj_J16zzTNYPuYYTx8aE59WnNGg_59jY5rv9qJCLFZK2eQWPxtifvf1VRymMRjo]cl1a@e...[/url
Sent: Wednesday, January 30, 2002 10:38 AM
To: 'basicstamps@yahoogroups.com'
Subject: RE: [noparse][[/noparse]basicstamps] RPM Governor in R/C Helos
Doug:
The Stamps In Class link is a good place to start. Proportional control may
suffice. I say this because it sounds like your RPM will be your set point,
and will be fixed, not adjustable. An Integrator is generally used in
control systems that have to contend with varying set points. If you were to
use full Proportional with a Derivative, you should be able to achieve very
smooth flight when using the controller on a variety of aircraft, since the
Derivative serves to increase the gain when large changes are needed.
You will have to know the conditions of your application very well - what
creates process disturbances (load changes in this case), how frequently,
and for what durations and duty cycles to expect are all vital pieces of
information required before starting. PID, PI, or PD control will allow
your system to respond almost 'predictively' as long as you have a good
understanding of the above conditions. Trial and error are always called for
to some degree.
There may not be a need to adjust the output once per revolution. A recent
PID program I worked with was for a heating process with 300 cycles per
minute. I was able to control it well by taking samples of every other
cycle. Also, Before starting, you might try to assess the events related to
a typical disturbance. A disturbance in this process, I would say is likely
anything that causes increased load, and hence, reduced rotor speed.
Somehow, you will need to estimate an average response time for disturbances
of various degrees. I would gather the time response of the copter to
several load changes - small, medium, large...and plot them first. Then you
can estimate the amount, or proportion of correction that is needed.
Starting with a wide window, or 'Proportional Band' is safest - correction
will be slower but smoother. That band is in this case an RPM range: at 1450
apply maximum power, at 1500 apply none. Of course, I am only guessing on
the 1450 value. Remember to use a low band limit that is higher than one
that would cause a catastrophic failure - there will be a delay between the
detection and the actual correction (lag.)
Since you have a pretty constant force opposing your output (gravity and air
pressure) you may not need more than this. If your first attempt at
Proportional control results in hysteresis that is unacceptable, you might
try increasing the proportional band. If that won't cut it, you will need to
inject an integral. You will be able to recognize this need by observing the
copter adjustments in flight. If the correction causes a correction that
overshoots the desired effect, then undershoots to correct that, you may
have unacceptable hysteresis. Most likely you will always have some, but,
again, you will have to determine what is acceptable. If your pitch servo or
rotor motor is underpowered, you will go nuts trying to work out an
algorithm that will always work the same. This is perhaps the best way to
make minimum power determinations.
I use 3 different methods to find the starting point for my PID controllers.
You may find something if you search for info on the 'Ziegler-Nichols'
closed loop method. A second textbook approach is called the 'Minimum
Overshoot' method. I tend to favor my own method, which starts with a huge
integral, no derivative, and a very narrow proportional band. Then in my
first test I start by increasing the Proportional band until the oscillation
rate stabilizes. Doubling this band should stop the oscillation completely.
I would then increase the Derivative until process stability begins to lose
it, then back off. This may not work for you if it causes crashes.
This is a very challenging area for programmers, and sounds like a fun
project. Please continue to post with your results.
Chris
My plan is to clock the RPM in with a hall-effect sensor. A software
preset RPM speed represents the target speed that should be acheived.
Then its up to the Stamp to decide if more or less throttle is needed
to reach the goal.
I'm figuring a psuedo-logrithmic calculation in the difference between
the actual and preset speeds is a ratio to servo movement for the
throttle. Big RPM difference = Big servo movement, etc. (Ok, so maybe
not log, but more like proportional, but that's for you mathemeticians
to figure out!)
I have yet to try it, but one potential problem I've heard about is
that the Stamp is actually too fast for this. The RPM range we're
dealing with is around 1500 RPM. At that rate, the Stamp will have
calculated far beyond that reading, and by the time physics catches up
(remember a leg between adding throttle and seeing the RPM difference)
can lead to "pumping" of the throttle.
What about taking an average of RPMs and working out some in-between
servo command with a "wait and see" loop?
Thanks for any help. I'll have the code up ready for download soon at
http://flyheli.cjb.net under that ACAMS section.
-Doug
robots. You factor in the lag and so forth and the program deals with all of
it.
Original Message
> As part of a larger system, I'm using a BS2SX Stamp in a radio
> controlled helicopter connected to the engine throttle. For
> helicopters to fly, their main rotor blades must be spinning at a
> constant speed, with only their pitch changing. When the pitch
> changes, torque is added or taken away from the engine, needing the
> throttle to be adjusted accordingly.
>
> My plan is to clock the RPM in with a hall-effect sensor. A software
> preset RPM speed represents the target speed that should be acheived.
> Then its up to the Stamp to decide if more or less throttle is needed
> to reach the goal.
>
> I'm figuring a psuedo-logrithmic calculation in the difference between
> the actual and preset speeds is a ratio to servo movement for the
> throttle. Big RPM difference = Big servo movement, etc. (Ok, so maybe
> not log, but more like proportional, but that's for you mathemeticians
> to figure out!)
>
> I have yet to try it, but one potential problem I've heard about is
> that the Stamp is actually too fast for this. The RPM range we're
> dealing with is around 1500 RPM. At that rate, the Stamp will have
> calculated far beyond that reading, and by the time physics catches up
> (remember a leg between adding throttle and seeing the RPM difference)
> can lead to "pumping" of the throttle.
>
> What about taking an average of RPMs and working out some in-between
> servo command with a "wait and see" loop?