Wheel encoders on a Raspberry Pi Robot

One of the problems with normal DC motors on robots is that you can’t accurately control them- you can vary the power to them using PWM but you’ve no real idea how far your’ bot will travel.

If you use stepper motors instead, then you can get very accurate results but the cheap ones don’t turn very fast and so are not suitable for a large floor area but ideal for table top use.

Recently, the Initio Robot Chassis from 4tronix has come along  and has wheel encoders built in and I’ve attempted to incorporate them into my ScratchGPIO project.

Basically, I use the RPi.GPIO library to do all my GPIO in and out and it has a facility to generate a pseudo-interupt (a callback routine)  every time it gets a pulse.  The wheel encoders produce 36 pulses for every 1 revolution of the wheels so its just a case of using the callback mechanism to count the number of pulses.

So I tell the wheels to turn 1 revolution and the count goes up by 36 – well not quite 🙂

I have no idea what power for what length of time (but approx 0.5) will give 1 revolution so I just switch the motor on, wait until count exceeds 36 then stop the motor.

The problem with this is that the motor takes some time to stop and so the final count ends up at about 48 or so.

The trick at this point is to remember the over-shoot and use the difference to compensate for the next move.


encoderpicBut, as usual with ScratchGPIO, all this is hidden beneath the bonnet and all the Scratch has to do is the scripts on the left to move forward and back one wheel circumference.

At the moment only the left hand encoder is read and I only use one of the sensing wires.


To connect it up
Looking at your PirRoCon board with GPIO pins on the left and regulator nearest you, remove the blue link nearest you in the bank of 8. (This disables the level-shifter for pin 7 (GPIO 4) which is the one I’ve designated for using for this.

Connect the brown wire from the left hand encoder (that’s left hand as if you were driving the robot yourself) and connect it to the exposed pin nearest the GPIO pins on the link you have just removed

Connect the black wire to a 0V pin and connect the red wire to 3.3 (NOT 5V!!!!!!) (The 1.2 version has dedicated 3.3V pins but if you have an original PiRoCon then you need to connect to the 3.3V on the i2C sockets using a short male-male lead)

You may also like...

11 Responses

  1. You might be interested in Scratch for Arduino as well. It allows Scratch to link to an Arduino board and you can program it via a regular PC. The beauty is you can either control the Arduino wirelessly or you can let it run as an independent robot.

  2. Bantammenace says:

    I’m about to bite the ScratchGPIO bullet for the first time and one question I have is wheel related. I am building an azimuth/elevation rotator mount for an antenna using 2 servos (12volt 1.0 and 0.5 rpm) and Ryan’s motor addon to hopefully track the Amsat Funcube satellite as it pases overhead. This involves precisely (if possible) and at slow speed, rotating the two motors to keep the directional antenna pointing towards the satellite. I want to try this in Scratch first as the Funcube project is targeted at Schools and I can envisage savvy geeks teachers like yourself being able to introduce it to your Robot Club.
    I want to try two Sofpot Rotary Encoders to provide the feedback. The potentiometer value can be converted to a rotational angle. One gives the horizontal angle, the other verical.
    On the Picoboard and Nanoboards AG there is a slider which acts as a potentiometer and this appears in Scratch as Slider in the sensing options. How do I get the Softpot to be recognised as the Slider in ScratchGPIO and how do I connect to 2 of them ?
    If there’s too much processing to do on the RPi then I might use one of the Arduino boards/libraries you have mentioned elsewhere.
    Thanks in advance as ever.
    kind regards

    • cymplecy says:

      Hi Kevin
      I’ve never had or played with a Picoboard (as its an input only device and I’m all about output! 🙂

      But, someone sent me a PCF8591P based add-on board and if ScratchGPIO detects one plugged into the I2C pins then it will return the analog input values from the ADCs and it creates sensor values adc1 to adc4.

      So that might be a relatively easy route for you

      The add-on board came from 4tronix but it was a prototype and I’m not sure if they are selling them yet but a plain chip would probably do the job just as well


  3. James Dore says:

    Hi Si,

    I’m testing this out, and it works fine going forwards, but reversing just continues until I tell it to go forwards again – there’s no count. Have I miswired something? (I have the yellow lead from the when sensor unconnected).


    • cymplecy says:

      Your the 1st person to use it apart from me 🙂 – My Initio not wired up at moment so it’ll take me a few days to check operation – shouldn’t make any diff which lead you use – can you post link/pic of your code and email it to me?


    • Jezz says:

      I think the Yellow lead is for direction, and using it will take up 2 GPIO pins. One for count, and one for direction. How its used I have no idea yet as I have not tired it myself, and a novice to Scratch and Initio, even the RPi itself.

      • cymplecy says:

        Using encoders in ScrachGPIO is the most advanced thing I’ve attempted so you are on the edge here 🙂

        The 2 wires just produce overlapping pulses which in a “proper” wheel encoder device would give both indication of how much turn has occured and in what direction
        Now I cheat because I know what direction the motors are going in (as we tell them with motorA = +/- values.

        So I just count the pulses and use the value to determine how far the wheels have turned in he direction I’ve told them to go.
        That’s why you should be able to use either pin.

        Hope this helps
        Still not rewired my Initio 🙁 What controller board are you using BTW?


  4. Jezz says:

    Hi Simon.
    Thanks for the link. Thinking about what you said with the motors over running when using the wheel encoders, would giving the motor a quick pulse in the opposite direction at 50% power help to reduce the problem.
    I am using the 4tronix PiRoCon 1.2.

Leave a Reply

Your email address will not be published. Required fields are marked *