WallBot – Version 2.5

For the next revision of WallBot I’ve added quadrature encoders and replaced the Arduino motor shield with a much more compact  motor controller from Pololu.

1200_1401_IMG_3032

WallBot Version 2.5

Adding the new motor controller was meant to simplify the wiring between the upper deck and lower. However, while it did keep all the power wiring below decks there were four signal wires needed between the Arduino and the controller. The encoders themselves added four more signal wires, so the net result is a lot less elegant than version 2. Aesthetically it’s taken a step back.

The Build

The Encoders

The quadrature encoders are specifically built for the chassis system so they were very easy to install.

The first part was to solder on some leads. Two for power (Vcc and GND) and two for the signal output (A and B).

1200_1401_IMG_2928

Pololu Quadrature Encoder

The encoders mount under the motors as shown in this image.

1200_1401_IMG_2923

Assembly

You don’t have to worry too much about how much the soldered leads protrude out of the back of the board as there are, conveniently, holes in the chassis to accommodate them.

1200_1401_IMG_2926

Mounting

Here is the final assembly for the encoders.

1200_1401_IMG_2931

Installed encoders with leads

The A and B signals for each encoder are monitor by the microprocessor so it can measure how far each wheel has turned. This feedback allows us to track the actual movement of the bot. More about this in a later post.

The Motor Controller

While I like the motor shield I have for the Arduino – it’s very handy to have, for sure – I released that for most applications it’s best to have the motor controller as near to the motors as possible for two reasons:

  1. Minimizes the routing of the motor power lines
  2. Takes up much less real estate. The shield is not an effective uses of space.

I ended up purchasing Pololu’s Qik 2s9v1 motor controller (I’ve bought a lot of stuff from Pololu as you can tell). I really like its size and it handles more current and voltage than the Adafruit motor shield. My only complaint is it does not use I2C to communicate with the microprocessor. Instead it has an Rx, Tx, Err and RST line to the controller. I guess I could have gotten away with just wiring the Rx line but for now I wired all of them.

Went with using 90° headers to streamline its profile.

1200_1401_IMG_3019

Soldering headers

Drilled some holes and bolted the board on to the underneath of the top deck, just in front of the motor battery in the rear. Used double sided foam tape between the deck and the back of the board.

1200_1401_IMG_3020

Mounted Motor Controller

Made for a very secure fit with little stress on the board and nicely cushioned against vibrations (not that vibrations are going to be a problem).

After that it was just a question of wiring everything.

1200_1401_IMG_3024

Lower Deck Wiring

It’s surprising how quickly the number of wires increases as you add components. In the image there are wires running from the motor battery (2) to the motor controller. Motor controller to both motors (4), and power to the front servo (2). Then power from Arduino (2) to the two wheel encoders (4) and to the motor controller (2). Signal wires to the Arduino from the motor controller (4), encoders (4) and the servo (1).

1200_1401_IMG_3025

Motor Controller Wiring

[The astute observer may notice that the servo leads (brown, read and orange) are connected incorrectly to the battery power lead (the red/black leads in the top right of the image above).  I didn’t realize my mistake till I plugged in the motor battery. Then I heard a slight popping sound and could smell ozone….]

Here is the view from the top deck. So many wires.

1200_1401_IMG_3029

Top Deck

And the final result:

1200_1401_IMG_3038

I ended up adding the proto-shield. It has extra 5V pins, which I needed, as well as two built in LEDs and a button I can eventually use to allow toggling of different running modes.

The Code

I labeled this WallBot as version 2.5 because while I’ve upgraded the hardware I didn’t get time to do anything significant with the software except to replace the Adfruit Motor Controller library with the Pololu one. What I really want to get to is programming the encoders. That will have to wait.

However, switching over to the new motor controller library raised some interesting issues I want to address in the near future. As a software engineer I’m very sensitive to code factoring and decoupling. You can see the problem if we compare the motor related sections of the code between V2 and V2.5

Adafruit Motor Controller Version:

#include <Wire.h>
#include <Adafruit_MotorShield.h>
:
#define LEFT  1
#define RIGHT 0
:
// get motor shield set up
Adafruit_MotorShield AFMS = Adafruit_MotorShield();
Adafruit_DCMotor *lm = AFMS.getMotor(4);
Adafruit_DCMotor *rm = AFMS.getMotor(3);
:
int turnSpeed = 20;        // 0..255
int moveSpeed = 70;        // 0..s55
:
void setup()
{
  // set up motors
  AFMS.begin();
  lm->run(RELEASE);
  rm->run(RELEASE);

}
:
void stopMoving()
{
  :
  rm->run(RELEASE);
  lm->run(RELEASE);
  :
}
:
void turn()
{
   :
    rm->setSpeed( turnSpeed);
    lm->setSpeed( turnSpeed);
    rm->run(dir == LEFT ? FORWARD : BACKWARD );
    lm->run(dir == LEFT ? BACKWARD : FORWARD );
   :
}
:
void moveForward()
{
   :
    rm->setSpeed( moveSpeed+2);
    lm->setSpeed( moveSpeed);
    rm->run(FORWARD);
    lm->run(FORWARD);
   :
}
:
:

Pololu’s Qik Motor Controller Version:

#include <SoftwareSerial.h>
#include <PololuQik.h>
:
PololuQik2s9v1 qik(10, 9, 11);
:
int turnSpeed = 20;        // 0..127
int moveSpeed = 40;        // 0..127
:
void setup()
{
  :
  qik.init();
  :
}
:
void stopMoving()
{
  :
  qik.setM0Coast();
  qik.setM1Coast();
  :
}
:
void turn()
{
   :
   int p = dir == RIGHT ? 1 : -1;
   :
   qik.setM0Speed(p*turnSpeed);
   qik.setM1Speed(p*turnSpeed);
   :
}
:
void moveForward()
{
   :
    qik.setM0Speed( moveSpeed );
    qik.setM1Speed( -moveSpeed);
   :
}
:

As you can see the interfaces to the motor controllers are quite different. It would be nice to be able to write motor controller logic without having to customize it for each motor controller I might use. After all the logic is identical between the two, or any other controller I might happen to use the code with.

So my next mini-project is to find or create a motor-controller abstraction layer so I can write motor logic without having to deal with the specifics of each controller. Probably will want to do this for other common devices.

Advertisements

Comments welcome

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s