I've got a head-scratcher in the last stages of a gyro project
The gyro puts out 38k4 data bursts at the rate of 75 - 77 bursts
per second. The information in the data is converted to a number
of pulses that are sent to motor drivers. Everything is working....
.....except. The motors really perform best when supplied with
evenly-spaced pulses. At present each motor is set to require
1200 pulses to move a gearbox 1 degree
The problem is that the bursts (as measured from the end of the
fifth byte in one to the end of the fifth byte in the next) are not evenly
spread, and can be anywhere from 11 to 14ms apart.
The first version used a single F877 to read the data and generate
the pulses. To do this I had to take the worst-case timing of 8ms free
time for motor pulses (which may be only a few us apart) before the
micro had to return to picking up data. This meant there could be up
to 6ms when the motor wasn't receiving pulses, which caused very
unacceptable jittering. Now the circuit has been split up into an F628
to read data and 3 others - one for an LCD and one each for taking
the calculated spacing from the reader to generate pulses. However,
as can be seen in this diagram
the problem has arisen again, although hopefully there is better
hardware in place now. I'm trying not to think of it as "re-arranging
the deck chairs on the Titanic". What will happen is that a short
interval following a long interval will cause a driver PIC to still be
in the throes of putting out pulses when it is told to stop that and
pick up new data
The only way I can see out of this is to cause an IRQ on the driver
PIC and temporarily suspend its pulse activities whilst it picks up
that data, and then uses the new spacing at the end of the current
run of pulses
This sounds workable. Any reason why not, or better solutions ?
Losing a few pulses here and there shouldn't (touch wood) be too
much of an issue. I thought of taking the serial data and re-transmitting
it at a more regular rate, but I don't think that will work out because
of the unpredictable nature of the gyro's timing. Sooner or later the
PIC and gyro will get out of synch
Not clear to me just what the motors are driving. Is it an indicator or does
it feed back to the gyro by changing the vehicles direction?
In order to fix your problem I suspect you may have to do something to get
your motors to move within the shortest update period. From your description
I take it they are stepper motors. Then you may have to ramp up the stepping
rate to a speed that allows them to complete the movement inside the time
period, and ramp down again.
Do you really need the dead time while receiving the data stream? I would
have thought a suitable interrupt driven set of routines would have handled
two motors and a serial stream with ease.
Hi,
I am new to PIC'ing, being an old (very old!) analogue man. Why cannot you,
even if only as a "get out" use D/A, analogue, A/D? I realise it may go
against the grain as a PICer, but if it would work, what the heck!
Regards Ivan
> The gyro puts out 38k4 data bursts at the rate of 75 - 77 bursts
> per second. The information in the data is converted to a number
> of pulses that are sent to motor drivers. Everything is working....
>
> .....except. The motors really perform best when supplied with
> evenly-spaced pulses. At present each motor is set to require
> 1200 pulses to move a gearbox 1 degree
>
> The problem is that the bursts (as measured from the end of the
> fifth byte in one to the end of the fifth byte in the next) are not evenly
> spread, and can be anywhere from 11 to 14ms apart.
This sounds to me like a filtering problem. You have data coming in in
bursts, and need to send it out smoothly in time.
I'm not totally clear on this, but I guess each gyro burst indicates a
number of pulses that need to be sent to a motor over the next 11 to 14mS or
so. Suppose the gyro burst only adds to a counter that keeps track of
pending pulses to be sent to the motor, and the counter is decremented for
every pulse sent. Whenever a gyro burst comes in and the counter is
updated, calculate the new period between pulses so that the counter would
reach zero a bit after the latest time for the next gyro pulse, like 20mS
for example.
This would keep the pulses coming regularly, with a change in pulse period
after every gyro burst. If you want to smooth that out too, just low pass
filter the pulse period a bit. You get smooth operation at the cost of some
lag. I can't tell if that's acceptable.
It seems the most time-critical thing you are doing is producing the regular
pulses. I would therefore generate the pulses from an interrupt. This
shouldn't take many cycles on the average, so there are plenty left for the
foreground loop to receive the gyro bursts, determine the number of
resulting motor pulses, update the pending pulses counter, and compute the
new pulse period.
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
I haven't followed the description through fully but here's what seems
sensible to me (but may, of course, not be).
Motor rate for a given error should be constant in the absence of any new
information re changes in the error. For a given error signal the motors are
fed a constant frequency pulse stream. At the end of each pulse the
processor reads an error signal and adjusts the frequency of the pulse
stream accordingly. Simplistically one could imagine the error signal being
provided as a parallel 8 (or more) bit word on a data port to be read in a
single port read and used to reset the timer for the next pulse. If desired
the changing error could be filtered, probably by the sending processor or
the receiving processor to modify step changes in some manner (moving
average, PID, whatever ...). The actual application of a pulse would seem to
require the relatively trivial task of reading a parallel word and setting a
timer appropriately. But perhaps I've missed the point fairly thoroughly.
> I am new to PIC'ing, being an old (very old!) analogue man.
> Why cannot you, even if only as a "get out" use D/A, analogue,
> A/D? I realise it may go against the grain as a PICer, but if it
> would work, what the heck! Regards Ivan
The gyro does actually have analogue outputs, accurate to 14
bits. However, being this close with the serial data (some of
which is generated by an A2D + micro inside the gyro) is
tantalising, as there's all sorts of info that's not present in the
analogue signals
I suppose if you have already moved to the 628 its probably not practical,
but I imagine you could quite likely use the 877 PWM with a low frequency
setting to generate a nice consistant pulsestream and then update the
frequency each time you receive a new serial packet. You might need to keep
track of how many output pulses the PWM has actually made to synchronise
with your serial input data but then the serial stream would be less time
critical.
> Not clear to me just what the motors are driving. Is it an
> indicator or does it feed back to the gyro by changing the
> vehicles direction?
There's no feedback from the motors to the gyro. They are
meant to mirror the orientation of the gyro by moving a
gimbal so that an object the gyro is attached to stays in the
same orientation
> In order to fix your problem I suspect you may have to do
> something to get your motors to move within the shortest
> update period.
I've tried that and the result is that they chatter horribly. What
the motor sees is virtually a 75Hz wave with a very short "mark"
(made up of perhaps 500 pulses) and a very long "space".
There's an upper limit to the pulse rate frequency because of
counter testing, although the motor controller will accept up to
10MHz. The motor does microstep for every single pulse btw,
even at 10MHz, right up to 36,000 steps/degree
> From your description I take it they are stepper motors.
Correct - Type23, 1.8deg
> Then you may have to ramp up the stepping rate to a speed
> that allows them to complete the movement inside the time
> period, and ramp down again
The thing is, if you've 2000 pulses to get out in 1/75th second it's
hard enough to do that without the burden of extra calculations,
and that's just for one motor. Then you still have to get the data
from the gyro in the first place
> Do you really need the dead time while receiving the data stream?
> I would have thought a suitable interrupt driven set of routines
> would have handled two motors and a serial stream with ease
As just mentioned, when you get down to 5 or 6us per pulse, timing
is at an absolute premium. The added nuisance of irregular data
timing just complicates matters
> > The problem is that the bursts (as measured from the end
> > of the> fifth byte in one to the end of the fifth byte in the next)
> > are not evenly spread, and can be anywhere from 11 to 14ms
> > apart.
>
> This sounds to me like a filtering problem. You have data coming
> in in bursts, and need to send it out smoothly in time
That's pretty much it in a nutshell. If I could count on new data exactly
every 15ms things would be so much easier. Considering there's a
(presumably heavy duty) micro inside the gyro, I'm disappointed that
the data timing is so rough
> I'm not totally clear on this, but I guess each gyro burst indicates a
> number of pulses that need to be sent to a motor over the next 11
> to 14mS or so.
That's right. The difference between consecutive gyro readings
is converted to degrees, then you work out the number of pulses
needed to move the motor an equal angle
> Suppose the gyro burst only adds to a counter that keeps track of
> pending pulses to be sent to the motor, and the counter is decremented
> for every pulse sent. Whenever a gyro burst comes in and the counter is
> updated, calculate the new period between pulses so that the counter
> would reach zero a bit after the latest time for the next gyro pulse, like
> 20mS for example
Yes, there's something in that. The big fly in the ointment is if there's
a direction change. I thought I had it all sorted out at the weekend
until I "remembered" about direction changes. Does tend to mess
things up a little
> This would keep the pulses coming regularly, with a change in pulse
> period after every gyro burst. If you want to smooth that out too, just
> low pass filter the pulse period a bit. You get smooth operation at the
> cost of some lag. I can't tell if that's acceptable.
Some lag is OK, but not more than a few ms, maybe 20ms at the most.
Anything like a running average is out, already looked at that. There
are occassions when a filtered or smoothed response is a handicap,
for example when trying to compensate for vibrations
> It seems the most time-critical thing you are doing is producing the
> regular pulses. I would therefore generate the pulses from an interrupt
Pulses may be spaced anywhere from around 5us to 1600us apart,
depending on the degree difference, so probably Timer1 would be
the way to go. It seemed to work alright on the first prototype, even
though the data timing thing wasn't fixed
> > Suppose the gyro burst only adds to a counter that keeps track of
> > pending pulses to be sent to the motor, and the counter is decremented
> > for every pulse sent. Whenever a gyro burst comes in and the counter is
> > updated, calculate the new period between pulses so that the counter
> > would reach zero a bit after the latest time for the next gyro pulse,
like
> > 20mS for example
>
> Yes, there's something in that. The big fly in the ointment is if there's
> a direction change. I thought I had it all sorted out at the weekend
> until I "remembered" about direction changes. Does tend to mess
> things up a little
I don't see why direction change is a problem. One direction adds to the
counter, the other subtracts. A similar increment or decrement is done
whenever a pulse is emitted. Each time a gyro burst comes in, you compute
the signed pulses represented by that burst and add it into the counter.
Then you compute the pulse period and step direction for the next interval
from the current counter value regardless of how it got there.
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
On Mon, Jun 24, 2002 at 10:47:12AM +1000, James Caska wrote:
> I suppose if you have already moved to the 628 its probably not practical,
> but I imagine you could quite likely use the 877 PWM with a low frequency
> setting to generate a nice consistant pulsestream and then update the
> frequency each time you receive a new serial packet. You might need to keep
> track of how many output pulses the PWM has actually made to synchronise
> with your serial input data but then the serial stream would be less time
> critical.
It's imminently practical. The 628 has the same 10 bit PWM module as the 877.
Another reason why it's the cream of the crop when it comes to 18/20 pin PICs.
I already said a quiet doah! to myself after sending this.
Having spent more than a little while simulating it I of all people
should remember a 628 has a PWM module... and yes it is simply
a brilliant gem of a micro.
> > This sounds to me like a filtering problem. You have data coming
> > in in bursts, and need to send it out smoothly in time
>
> That's pretty much it in a nutshell. If I could count on new data exactly
> every 15ms things would be so much easier. Considering there's a
> (presumably heavy duty) micro inside the gyro, I'm disappointed that
> the data timing is so rough
Hi Jinx, I still don't understand the exact problem. :o)
Is it like this:
* gyro outputs an "error" signal every 5mS to 20mS
* period between signals is unknown and varying
* you decode error signal and generate number of pulses
to turn stepper motors to re-stabilise gyro again
* the ideal is to turn motors at perfect speed so the
error is zero by the time next error signal arrives,
so no dead band or overlap.
If I understand the problem you can get around it by
always keeping one error signal in buffer, this gives you
lag of one period, up to 20mS. The advantage is that you
can then see the "future", you know WHEN the next error
signal will arrive and can turn the motor at the correct
speed so it gets to the goal exactly when the next signal
arrives. So you have both the error DISTANCE and also the
TIME allowed to correct it.
Obviously pulse frequency is adjusted for each sample to
ensure the motor arrives at goal position at the end of
the period. Is this workable, ie can you afford one
period lag? Or have I just misunderstood the problem
entirely?? :o)
-Roman
Is the real problem a case of the gyro sending messages only when it can
justify sending a difference message?
What I envisage is that if the gyro moves a large amount then it rapidly
sends a message showing a large difference, which requires you to move your
motors a large distance. When the gyro moves a small amount it has to wait a
long time to sense a position change or timeout period to send the next
message. This means you have a long period to move your motor a small
amount, i.e. the time between messages is inverse to the amount of movement,
which is the inverse of what you want to maintain the motors at a constant
stepping rate :)
mitvma.mit.edu with SET PICList DIGEST in the body
