1. Limited time only! Sign up for a free 30min personal tutor trial with Chegg Tutors
    Dismiss Notice
Dismiss Notice
Join Physics Forums Today!
The friendliest, high quality science and math community on the planet! Everyone who loves science is here!

Finding Speed

  1. Mar 17, 2005 #1

    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?
  2. jcsd
  3. Mar 17, 2005 #2


    User Avatar
    Science Advisor

    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

    [tex]speed = \frac{f*c}{n}[/tex]

    where f=frequency (pulses/sec), c=circumference of the wheel (in), and n=pulses per revolution.
  4. Mar 17, 2005 #3
    the encoder is made of a beam... and it reads between "holes" of wheels... wheneter the beam breaks, it counts toward the counter.
  5. Mar 17, 2005 #4


    User Avatar
    Science Advisor

    There you go. Now all you need is a timer and you will have your frequency. You know how many holes you have.
  6. Mar 17, 2005 #5
    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?
  7. Mar 17, 2005 #6
    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.
    Last edited by a moderator: Apr 21, 2017
  8. Mar 17, 2005 #7
    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?
  9. Mar 17, 2005 #8
    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?
  10. Mar 17, 2005 #9
    its a handyboard

    how do i measure the time then...
  11. Mar 17, 2005 #10
    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).
  12. Mar 17, 2005 #11
    well it has an internal clock... called by long mseconds(), float seconds().
  13. Mar 17, 2005 #12
    I would start here:

    And here:

    According to this:
    http://handyboard.com/hblabel.html [Broken]

    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.
    Last edited by a moderator: May 1, 2017
  14. Mar 17, 2005 #13
    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.
  15. Mar 17, 2005 #14
    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

    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.


    From reset:
    Code (Text):

    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:


    Thus we have:

    Code (Text):

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

    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:

    Code (Text):

    if( (right_new-right_old)>(left_new-left_old))

    elseif( (right_new-right_old)>(left_new-left_old))
    The simple comparison would probably be easire than doing the math and then a comparison.
  16. Mar 17, 2005 #15
    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...
  17. Mar 17, 2005 #16
    Last edited by a moderator: May 1, 2017
  18. Mar 17, 2005 #17
    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.
Know someone interested in this topic? Share this thread via Reddit, Google+, Twitter, or Facebook

Similar Discussions: Finding Speed
  1. Infinite speed (Replies: 18)