Finding Speed from Displacement and Time

[PrudensOptimus]

Hello,

We all know speed is the first derivative of displacement... but here is what i want to know:

I know displacement and time... how can i find speed. The reason is that i have 2 wheels operated by motors, and on the wheels I attached an encoder, which reads the rotation of the wheels...

But because the motors tend to run at different speeds, which causes instability(i want both wheels to operate at the same rate.) So... I want to use the information feedbacked from Encoders to adjust the speed of these motors. How can I achieve that?

 

[FredGarvin]

The encoders are giving you what kind of signal? A pulse? The usual practice is to count a certain number of pulses per revolution. That would result in a pulse frequency. You could then calculate the speed by

$$speed = \frac{f*c}{n}$$

where f=frequency (pulses/sec), c=circumference of the wheel (in), and n=pulses per revolution.

 

[PrudensOptimus]

the encoder is made of a beam... and it reads between "holes" of wheels... wheneter the beam breaks, it counts toward the counter.

 

[FredGarvin]

There you go. Now all you need is a timer and you will have your frequency. You know how many holes you have.

 

[PrudensOptimus]

Umm I'm kind of slow,.. could you give an example with say... the reading is 60 holes? and say every 6 holes is a revolution, so thereby 10 revolutions?

 

[faust9]

Umm I'm kind of slow,.. could you give an example with say... the reading is 60 holes? and say every 6 holes is a revolution, so thereby 10 revolutions?

Here's probably the easiest approach to this.

Measure the time between pulses on both wheels and compare those times.

An example:

Lets say you want the right wheel to be the master wheel. This is the wheel that you--the user--control the angular velocity of. When you want to speed up you tell the right wheel controller to speed up.

The left wheel is the slave and/or the turning wheel. The angular velocity of this wheel can be used to turn your device or make it go straight. To accomplish this, you'll need some sort of microcontroller (like a PIC or a BASIC STAMP or something). Your microcontroller should have a built in timer(very few don't have pre-installed tmr functions), though two timers would be better. This chip: http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1335&dDocName=en010115 is versitle enough to control the speed of the master and slave wheels.

Feed the encoder outputs from both wheels to the microcontroller.

Now, this is the meat and potatos of the controller. The above chip has two timers. The master wheel will reset one timer with every encoder pulse and the slvae wheel will reset the second timer with every encoder pulse. Just before reset though the timer has some numeric value stored which will be analagous to angular velocity. For instance, it might take 255 milli seconds between pulses so the timer would hold the 8-bit value 11111111. If the left wheel was going a little slower say 231 mS between pulses then that timer would hold 1110 0111. The microcontroller can then compare these two values and adjust the slave wheel speed controller to match the drive wheel speed.

All your doing is comparing the time for the master wheel to rotate between two encoder positions and comparing that value to the time for the slave to go between two encoder positions (between resets).

This method allows you to check the angular velocities of the wheels as often as possible because each encoder pulse causes a corresponding comparison and speed correction.

Anyway, hope this helped.

 

[PrudensOptimus]

so say... basically run a timed test... say 1000ms, and see how far the master wheel went... and then compare the same thing to right wheel... and if it didn't travel as far... then speed up the right wheel, right?

 

[faust9]

so say... basically run a timed test... say 1000ms, and see how far the master wheel went... and then compare the same thing to right wheel... and if it didn't travel as far... then speed up the right wheel, right?

Don't use a fixed time. Simply measure the time between encoder pulses on one wheel and compare that to the time between encoder pulses on the other wheel. If you use a fxed time then you will have more inaccuracies.

How are you controlling this BTW--what kind of controller?

 

[PrudensOptimus]

its a handyboard

how do i measure the time then...

 

[faust9]

Give me a few minutes. I'll have to look up that controller. It's HC11F1 based isn't it? I know an HC11 can easily handle multiple timing events(HC11's were designed originally to control GM engines).

 

[PrudensOptimus]

well it has an internal clock... called by long mseconds(), float seconds().

 

[faust9]

I would start here:
http://www.freescale.com/webapp/sps...peKey=10MTYPgQ&DocTypeKey=10Ksgj8q&Results=25

And here:
http://handyboard.com/

According to this:
http://handyboard.com/hblabel.html

The handy board has 9 digital inputs. Attach your encoders(through buffers) to 2 of the 9 digital inputs. You'll have to read the handyboard docs to determine hwo to work with timeing events. This board was designed for robotic use, so I'm willing to bet dollars to doughnuts that multiple timing events can be used.

 

[PrudensOptimus]

har har you are very humorous.

What do you mean by multiple timing events?

Could you make a list for me as to what to do in order to achieve my goal? I'm very slow... and I need guidance from people like you.

 

[faust9]

Motorola chips use something called vectored interrupts--its just a scary name. Essentially, when the chip receives an interrupt(like from an encoder) the processor will always jump to a certain location in memory. There are different types of interrupt and each interrupt has its own location in the address map. For instance, the reset vector(the memory location the HC11 jumps to when it gets a reset request on the reset pin or when it is powered up) is located at FFFE and FFFF. That's two memory locations for the reset vector. The reset vector holds the location of the program counter so when reset, the HC11 reads FFFE and FFFF then jumps to the memory location stored there. Every time you reset any HC11 it will goto (pun) FFFE/FFFF initially. That is how HC11's use vectored interrupts.

The HC11 also has timers installed (stopwatches) This is what motorola has to say(from one of the documents on the HANDYboard site)

"10.1 General Description
This timer system is based on a free-running 16-bit counter with a four-stage programmable
prescaler. A timer overflow function allows software to extend the timing capability
of the system beyond the 16-bit range of the counter. Three independent inputcapture
functions are used to automatically record (latch) the time when a selected
transition is detected at a respective timer input pin. Five output-compare functions are
included for generating output signals or for timing software delays. Since the inputcapture
and output-compare functions may not be familiar to all users, these concepts
are explained in greater detail.
A programmable periodic interrupt circuit called the real-time interrupt (RTI) is tapped
off of the main 16-bit timer counter. Software can select one of four rates for the RTI,
which is most commonly used to pace the execution of software routines."

Moreover, this is how the input timer works:

"10.1.2 Input-Capture Concept
The input-capture function is a fundamental element of the timer architecture of the
MC68HC11A8. For the MCU, physical time is represented by the count in the 16-bit
free-running counter. This counter is the central element in the main timer system. Input-
capture functions, used to record the time at which some external event occurred,
are accomplished by latching the contents of the free-running counter when a selected
edge is detected at the related timer input pin. The time at which the event occurred is
saved in the input capture register (16-bit latch); therefore, although it may take an undetermined
variable amount of time to respond to the event, software can tell exactly
when the event occurred.
By recording the times for successive edges on an incoming signal, software can determine
the period and/or pulse width of the signal. To measure a period, two successive
edges of the same polarity are captured. To measure a pulse width, twoalternate
polarity edges are captured. For example, to measure the pulse width for a high-going
pulse, the user would capture at a rising edge and subtract this time from the time captured
for the subsequent falling edge. When the period or pulse width is less than a full
16-bit counter overflow period, the measurement is very straightforward. In practice,
software usually has to keep track of the overflows of the 16-bit counter to extend its
range."

I thought HC11's had multiple input timers but I could be wrong(been years since I've touched one) but that doesn't matter. What you need to do is have your program record the value stored in the input timer when the encoder sends a pulse. then subrtact the previous encoder value from the new and you have a "time" compare the "times" of the two wheels and use that to match their speeds. Here, I'll step through this onece.

Image that you have created 4 variables for encoder timing.

left_old
left_new
right_old
right_new

From reset:

left_old=	0
left_new=	0
right_old=	0
right_new=	0

Your device starts to roll forward.

The encoder on the right pulses first(one of the sides will pulse before the other probably if you are using independent motors I just said the right pulsed first) The value in the input-timer is:

110010100101100 (29000 in decimal I just chose this randomly)

This gets stored in right_new

The encoder on the left pulses and is read as:

110010100110110

Thus we have:

left_old=	0
left_new=	110010100110110
right_old=	0
right_new=	110010100101100

right_new-right_old=110010100101100
left_new-left_old=110010100110110

Now if we subtract the right value from the left we'll have a relative value of: 0000000000001010

This 1010 represents the relative speeds of the two wheels. In this case the left wheel is spinning slower (only due to the initial placement of the encoder pulses from rest).

The other thing you could do is test which value is greater:

if( (right_new-right_old)>(left_new-left_old))
{
speed_up_left_wheel
}

elseif( (right_new-right_old)>(left_new-left_old))
{
slow_down_left_wheel
}
else
{
do_nothing
}

The simple comparison would probably be easire than doing the math and then a comparison.

 

[PrudensOptimus]

Well I had tested the comparison of "Ticks". There's this function called read_encoder(), and it would return the value of "ticks" (holes). I compare read_encoder(left) to read_encoder(right):

int i = 0;
if ( read_encoder(left) < read_Encoder(right) )
{
motor(left, current_speed + ++i );
}


however, doesn't seem to work...

 

[faust9]

http://www.fcps.k12.va.us/AnnandaleHS/StudentActivities/BotBall/softwarecode.html

http://web.mit.edu/rikky/www/motion.c.txt

 

[PrudensOptimus]

one from mit is pretty good,

the first one though is inferior and coding look noobish ..

Thanks for teh info friend.

Please supply more as you find.