Category Archives: Colin

Obstacle Avoidance

Posted on by

 

At long last I’ve gotten around to doing a post on obstacle avoidance! Thanks to everyone for your patience.

When I started writing this post it had been months since I had last thought about obstacle avoidance. I opened my obstacle avoidance sketch for Colin intending to use it for this post unchanged but it looked terrible. It was a kludgy mess of nested if/else statements. So I took a few hours to totally rewrite my code and make it more efficient and readable. Revisiting old programs can be a great opportunity to reevaluate previous work.

Anyway, the basic idea behind obstacle avoidance is pretty simple. Colin, my mobile robot, can sense objects around himself. If he gets too close to an object he turns away and goes off in another direction. Easy, right?

Wiring Diagram
Program Design
Example Sketch
Video

Preliminaries

We’ll be using HC-SR04 ultrasonic sensors for this tutorial. If you’ve never used ultrasonic sensors before you should take a look at my tutorial. This tutorial also uses DC motors. If you’ve never used DC motors with an Arduino before, take a look at my motor control tutorial.

There is one problem to address right away: the configuration of our sensors. HC-SR04 sensors have a roughly 30° field of view, so with just one sensor Colin won’t be able to see anything to his sides.

Others have solved this problem by mounting a sensor on a servo so the sensor rotates and sweeps out a larger field of view. This instructable is a good example of the technique.

For my purposes it was easier to use an array of three sensors, however. With sensors facing forward, left and right Colin gets a pretty good picture of what’s around him. He still has blind spots at +45° and -45° though, so I’m planning on adding two more sensors.

top

Wiring Diagram

Wiring up the sensors and motors is pretty simple. We really just have to combine the wiring diagrams from the motor control tutorial and the ultrasonic sensor tutorial. Wire the components per the diagram below and you’ll be in good shape.

Wiring diagram for obstacle avoidanceIt’s come to my attention that, on some displays, the color of the TRIG and ECHO wires for the left sonar sensors is very similar to the color of the +5V wire. These wires SHOULD NOT connect, however.

top

Program Design

Before we get into actually writing the obstacle avoidance program we have to decide: how should Colin react to sensor inputs?

The simplest thing we could do is have Colin turn 90º to the left whenever one of his sensors sees an obstacle in front of him. But what if there is also an obstacle to his left? He would turn directly into the obstacle on his left while trying to avoid the one in front of him. What if there is an obstacle on Colin’s left or right but no obstacle in front? Clearly there are several possibilities here.

We need to identify the set of situations Colin might encounter that require him to react. Then we need to identify what those situations look like to Colin in terms of sensor inputs. Lastly, we need to specify an action for Colin to take in each situation.

Let’s assume Colin only needs to take action when an obstacle is within a certain distance. We can call this distance, dr for reaction distance. When the distance from one or more of Colin’s sensors to the nearest obstacle is less than dr Colin needs to take action to avoid the obstacle(s). The table below breaks down the situations and sensor inputs that require Colin to react and the action Colin could take.

Reaction Matrix
Obstacle Locations Left Distance Front Distance Right Distance Response
No Obstacles > dr > dr > dr Drive forward
Front > dr < dr > dr Turn left 90°
Front and right > dr < dr < dr Turn left 90°
Front and left < dr < dr > dr Turn right 90°
Front, left and right < dr < dr < dr Turn left 180°
Left and right < dr > dr < dr Turn left 180°
Right > dr > dr < dr Turn left 45°
Left < dr > dr > dr Turn right 45°

Notice that our reaction matrix requires Colin to turn by a number of degrees for most of his reactions. But Colin has no way of knowing how far his wheels have turned, which would be required for him to know how many degrees he’s turned. The best we can do for now is set Colin’s motors to run at different speeds for a certain time interval. Through trial and error we can find the speed differential and time interval required to get a specific amount of turning. This is an approximate solution but we can’t do any better until we add encoders to Colin’s motors.

top

Example Sketch

/*
 * Obstacle avoidance example
 * by Andrew Kramer
 * 8/3/2015
 *
 * Uses 3 ultrasonic sensors to determine
 * if nearest obstacle is too close.
 * Outlines 8 possible cases for
 * positions of obstacles.
 */

#include <NewPing.h>

#define RH_PWM 3 // PWM pin for right hand motor
#define RH_DIR1 4 // direction control for right hand motor
                  // BIN1 pin on motor controller
#define RH_DIR2 5 // direction control for right hand motor
                    // BIN2 pin on motor controller
#define LH_PWM 9 // PWM pin for left hand motor
#define LH_DIR1 7 // direction control for right hand motor
                     // AIN1 pin on motor controller
#define LH_DIR2 8 // direction control for left hand motor
                     // AIN2 pin on motor controller
#define DEFAULT_SPEED 25 // default PWM level for the motors
#define TURN_DIST 25 // distance at which the bot will turn
#define MAX_DISTANCE 200 // max range of sonar sensors
#define NUM_SONAR 3 // number of sonar sensors
#define NUM_CASES 8 // number of reaction cases

#define MS_PER_DEGREE 10 // milliseconds per degree of turning

NewPing sonar[NUM_SONAR] = { // array of sonar sensor objects
  NewPing(13, 13, MAX_DISTANCE), // left
  NewPing(12, 12, MAX_DISTANCE), // front
  NewPing(11, 11, MAX_DISTANCE) // right
};

/*  
 *  stores a bool for each sensor (left, front, and right respectively
 *  true if nearest obstacle is within TURN_DIST
 *  true if not
 */
bool sensor[3] = {false, false, false}; 

// stores all possible sensor states
bool reactions[NUM_CASES][NUM_SONAR] = { 
   {false, false, false}, // 0: no obstacles
   {false, true, false},  // 1: obstacle in front
   {false, true, true},   // 2: obstacles front and right
   {true, true, false},   // 3: obstacles front and left
   {true, true, true},    // 4: obstacles front, left, and right
   {true, false, true},   // 5: obstacles left and right
   {false, false, true},  // 6: obstacle to the right
   {true, false, false} }; // 7: obstacle to the left

void setup() {
  for (int pin = 3; pin <= 9; pin++) {
    pinMode(pin, OUTPUT); // set pins 3 through 9 to OUTPUT
  }
  Serial.begin(9600);
}

void loop() {
  updateSensor();
  switch (compareCases()) {    
    case 0: // no obstacles
      straightForward();
      break;
    case 1: // obstacle in front
      turnLeft(90);
      break;
    case 2: // obstacles front and right
      turnLeft(90);
      break;
    case 3: // obstacles front and left
      turnRight(90);
      break;
    case 4: // obstacles front, left, and right
      turnLeft(180);
      break;
    case 5: // obstacles left and right
      turnLeft(180);
      break;
    case 6: // obstacle to the right
      turnLeft(30);
      break;
    case 7: // obstacle to the left
      turnRight(30);
      break;
  }
  delay(100);
}

void updateSensor() {
  for (int i = 0; i < NUM_SONAR; i++) {
    int dist = sonar[i].ping_cm();
    // if sonar returns 0 nearest obstacle is out of range
    if (dist == 0) sensor[i] = false;
    else sensor[i] = dist < TURN_DIST;
  }
}

int compareCases() {
  for (int i = 0; i < NUM_CASES; i++) {
    bool flag = true;
    for (int j = 0; j < NUM_SONAR; j++) {
      if (reactions[i][j] != sensor[j]) flag = false;
    }
    if (flag) return i;
  }
}

void setLeftForward() {
  digitalWrite(LH_DIR1, HIGH);
  digitalWrite(LH_DIR2, LOW);
}

void setRightForward() {
  digitalWrite(RH_DIR1, HIGH);
  digitalWrite(RH_DIR2, LOW);
}

void setBothForward() {
  setLeftForward();
  setRightForward();
}

void setLeftBackward() {
  digitalWrite(LH_DIR1, LOW);
  digitalWrite(LH_DIR2, HIGH);
}



void setRightBackward() {
  digitalWrite(RH_DIR1, LOW);
  digitalWrite(RH_DIR2, HIGH);
}

void setBothBackward() {
  setRightBackward();
  setLeftBackward();
}

void setLeftSpeed(int speed) {
  analogWrite(LH_PWM, speed);
}

void setRightSpeed(int speed) {
  analogWrite(RH_PWM, speed);
}

void setBothSpeeds(int speed) {
  setLeftSpeed(speed);
  setRightSpeed(speed);
}

// sets direction of both motors to forward and sets both speeds
// to default speed
void straightForward() {
  setBothForward();
  setBothSpeeds(DEFAULT_SPEED);
}

void turnLeft(int deg) {
  setBothSpeeds(0);
  delay(100); // delay to allow motors to stop before direction change
  setLeftBackward();
  setBothSpeeds(DEFAULT_SPEED);
  delay(MS_PER_DEGREE * deg); // allow time for the bot to turn
  straightForward(); // resume driving forward at default speed
}

void turnRight(int deg) {
  setBothSpeeds(0);
  delay(100); // delay to allow motors to stop before direction change 
  setRightBackward(); 
  setBothSpeeds(DEFAULT_SPEED); 
  delay(MS_PER_DEGREE * deg); // allow time for the bot to turn
  straightForward(); // resume driving forward at default speed
}

You probably won’t be able to load up the code on your differential drive robot and run it, even if you have it wired properly. Depending on how you have the motors wired, one or both of them might run backward. To fix this you should just swap the values in the DIR1 and DIR2 fields for the problematic motor. Also, you may have to adjust the value of MS_PER_DEGREE to get accurate turning.

You’ll notice most of the code in the above sketch is devoted to simply controlling the two motors: setting motor directions, PWM levels, etc. In fact, very little of the above sketch codes for higher level behaviors like deciding when and how to react to obstacles. This makes the sketch more difficult to read and it will only get worse when we add encoders to the mix.

To fix this I’ve developed a motor control library. Encapsulating the motor control code in separate motor objects allows us to focus on programming high-level behaviors without worrying too much about how we’re controlling the motors. I’ll present my motor control library (and make it available for download) in my next post.

top

Video

Below you can see a video of Colin running the above example sketch.

You’ll notice that Colin always stops before making a turn. This slows him down and makes his behavior appear jerky. New methods could be added to the sketch to allow Colin to turn while still moving forward in some situations. These methods would simply slow down the wheel on the inside of the turn rather than reversing it. This could be useful when Colin approaches an obstacle obliquely. In this case only a minor course correction is required so a small, smooth turn is better than stopping, rotating, and starting forward again.

That’s all for today. Check back in a couple of weeks for posts on my motor control library and a refinement to obstacle avoidance that uses bit math!

top

Ultrasonic Sensors

Posted on by

If you’ve been through my simple motor control tutorial you now know how to control the input voltage to DC motors using an Arduino. In a differential drive robot like Colin, this means driving in a (nearly) straight line, a circle, or some other preset path. It would be more interesting if we could make a robot that reacts to its surroundings. For this we need sensors and ultrasonic sonar sensors are a good place to start.

Ultrasonic sensors determine the distance between themselves and the nearest obstacle by emitting an ultrasound pulse and timing how long it takes for that pulse to be reflected off the nearest obstacle and back to the sensor. They are easy to use, accurate, and they can be extremely cheap.

They do have limitations, however. Sound reflects best off of hard, smooth objects, so soft or uneven surfaces are not detected very well. Most kinds of fabric are basically invisible to an ultrasonic sensor. Reflection is another problem. To work properly, the sensor needs an obstacle to reflect its emitted pulse straight back to the sensor. If the sensor isn’t aimed straight at a perpendicular surface, the reflected pulse could miss the sensor entirely. In this case the sensor would not detect the obstacle. The datasheets for most sensors specify an angle within which the sensor will be able to reliably detect obstacles.

HC-SR04 sensor

HC-SR04 sensor

For this tutorial I’ll be using an HC-SR04 sensor. The datasheet for the sensor can be found here. Note that it will only reliably detect obstacles within +/- 15 degrees from perpendicular to the face of the sensor. The HC-SR04 definitely isn’t the best ultrasonic sensor out there. More accurate, longer range sensors exist. You cannot, however, find a cheaper ultrasonic sensor than the HC-SR04. If you shop around on Amazon you can find them for $1-3 apiece.

Before I get into the actual tutorial I should mention I’m making use of Tim Eckel’s NewPing library for Arduino here. It makes using these sensors a complete snap. You should definitely take a look at the tutorial on the Arduino Playground in addition to this one. If you don’t have experience installing or using new libraries in Arduino, take a look at this tutorial.

Single Sensor Example

We’ll start out by wiring up and testing a single HC-SR04 sensor. You’ll want to wire it up as in the diagram below.

Wiring diagram for a single HC-SR04 sensor.

Wiring diagram for a single HC-SR04 sensor.

Note the Trig and Echo pins on the sensor can be connected to different pins on the Arduino. The NewPing library makes it possible to connect the Trig and Echo pins to the same Arduino pin. This is great because it means the HC-SR04 doesn’t occupy as many I/O pins.

Note also there is no power source pictured on the above diagram. For the purposes of this exercise we can power the Arduino through its USB port, so no external power source is required.

Example Sketch

#include <NewPing.h>

#define TRIGGER_PIN 2
#define ECHO_PIN 2
#define MAX_DISTANCE 200 // max distance the sensor will return

NewPing sonar(TRIGGER_PIN, ECHO_PIN, MAX_DISTANCE); // declare a NewPing object

void setup() {
  Serial.begin(115200);
}

void loop() {
  delay(50);
  int uS = sonar.ping(); 
  Serial.print("Ping: ");
  Serial.print(uS / US_ROUNDTRIP_CM); // convert ping time to distance in cm
  Serial.println("cm");
}

Load the above sketch on your Arduino and open a terminal window. Make sure the baud rate of the window is the same as the baud rate in your Serial.begin();  statement.

When initializing a NewPing object use the following form: NewPing(triggerPin, echoPin, distanceLimit); If you’re using the same pin for the trigger and echo just set triggerPin and echoPin to the same pin.

The example sketch will display the distance from the sensor to the nearest obstacle in centimeters every 50 milliseconds. If the nearest obstacle is beyond the distanceLimit or if the nearest obstacle is not detectable then sonar.Ping() will return 0.

Play around with the single sensor for a bit. Have some fun with it. Eventually start to realize how limited a single sensor is. A robot that can only see directly in front of itself can’t see obstacles at its sides. So if it approaches an obstacle at an angle, the obstacle won’t be detected. So what should we do? Add more sensors, of course!

Three Sensor Example

Now that we’ve got a single sensor up and running it should be a simple matter to add two more sensors. It can be useful to have an array of sensors when we’re trying to detect obstacles around a mobile robot like Colin. Wire the sensors up as in the diagram below.

Wiring diagram for three HC-SR04 sensors.

Wiring diagram for three HC-SR04 sensors.

Example Code

#include <NewPing.h>

// trigger and echo pins for each sensor
#define SONAR1 2
#define SONAR2 3
#define SONAR3 4
#define MAX_DISTANCE 200 // maximum distance for sensors
#define NUM_SONAR 3 // number of sonar sensors

NewPing sonar[NUM_SONAR] = { // array of sonar sensor objects
  NewPing(SONAR1, SONAR1, MAX_DISTANCE),
  NewPing(SONAR2, SONAR2, MAX_DISTANCE),
  NewPing(SONAR3, SONAR3, MAX_DISTANCE)
};

int distance[NUM_SONAR]; // array stores distances for each
                         // sensor in cm

void setup() {
  Serial.begin(115200);
}

void loop() {
  delay(50);
  updateSonar(); // update the distance array
  // print all distances
  Serial.print("Sonar 1: ");
  Serial.print(distance[0]);
  Serial.print("  Sonar 2: ");
  Serial.print(distance[1]);
  Serial.print("  Sonar 3: ");
  Serial.println(distance[2]);
}

// takes a new reading from each sensor and updates the
// distance array
void updateSonar() {
  for (int i = 0; i < NUM_SONAR; i++) {
    distance[i] = sonar[i].ping_cm(); // update distance
    // sonar sensors return 0 if no obstacle is detected
    // change distance to max value if no obstacle is detected
    if (distance[i] == 0)
      distance[i] = MAX_DISTANCE;
  }
}

Note the step in the updateSonar() method that checks if the distance returned by sonar[i].ping_cm() is 0, meaning the nearest obstacle is probably out of range. Technically it’s possible there is an obstacle 0cm away from the sensor, but that is not very likely. If the value returned by sonar[i].ping_cm() is 0, we switch it to MAX_DISTANCE .

Now we can control 3 sonar sensors simultaneously. We can use this in conjunction with our ability to control motors to make a robot that has autonomous behavior! One of the simpler things we can do with these two tools is program an obstacle avoidance routine. If that interests you stay tuned for my next tutorial, because I’m planning to do in on that very topic!

Simple Motor Control

Posted on by

I’ve finally gotten around to outlining the basics of DC motor control with the Arduino. We won’t be completely starting from scratch. I will assume you have some familiarity with the Arduino and its programming environment. If you’ve never done anything with the Arduino before I’d suggest doing some simple tutorials, like how to blink an LED, first. If you can make the blink tutorial work and wire everything up properly, you should be able to get through the examples here.

I’ll start out with a parts list, then I’ll outline how to control a single motor, and then I’ll move on to dual motor control.

Parts List

  • 1 Arduino; I’ll be using the Duemilanove but the examples should work with the newer Uno and most of the other Arduino variants as well.
  • 1 dual motor driver; I’ll be using the TB6612FNG from Pololu
  • 2 DC motors; I’m using micro metal gearmotors from Pololu
  • Batteries; I’m using a 4 AA pack that gives around 6V but I’ll discuss other options as well
  • 1 voltage regulator; this can be really handy but it’s not totally necessary
  • Hookup wire; I suggest you use ribbon cable but, at a minimum you should use several different colors of wire. It’s hard to appreciate how hard it is to wire up electronics using only one color of wire unless you’ve actually tried it.
  • Finally, some soldering skill will be necessary. There’s a good tutorial here if you’re not familiar. Do a lot of practicing before you try to solder anything you care about.

The Motor Driver

The Arduino’s digital pins cannot provide enough current to run even a small motor. So we need a power source for the motor that can supply a lot of current, but we also need a way to control that power source using the Arduino. This can be done using a simple switching transistor as in this great Adafruit tutorial but using a motor driver circuit like the TB6612FNG has some advantages:

  • We don’t have to build our own motor control circuit. As long as we wire it up correctly the TB6612FNG works right out of the box.
  • It allows us to control two motors with the same circuit, so it saves us a bit of complexity for dual motor control.
  • Most importantly, it gives us software control of the motor’s direction using the AIN1 and AIN2 pins for one motor, and the BIN1, and BIN2 pins for the other:
    • If IN1 is driven HIGH and IN2 is LOW the motor will turn forward
    • If IN1 is driven LOW and IN2 is HIGH the motor will turn backward
    • If IN1 and IN2 are LOW the motor will freewheel
    • If IN1 and IN2 are driven HIGH the motor will lock up or be in a “braking” state

The Battery / Voltage Regulator

All of the components in this setup have different power requirements. The motors require around 6V and they draw a lot of current. The Arduino needs 7-12V. It is possible to power the Arduino by connecting a 5V source to the 5V pin, but this bypasses the Arduino’s onboard voltage regulator so you need to make sure you have a regulated 5V source if you want to go that route. Lastly, the motor driver needs 5V for its logic. The motor driver can get its 5V from the 5V pin on the Arduino, but how do we satisfy the different requirements of the motors and the Arduino?

Option 1: Different power sources for the motors and Arduino

A 4 AA battery pack provides between 5.5 and 6.5V and can give a lot of current, which makes it good for the motors. But the Arduino needs 7-12V. Some people solve this by using a separate power source for the Arduino, usually a 9V battery. This is problematic for a couple of reasons. First, the Arduino’s onboard regulator isn’t very efficient when stepping 9V down to 5V and a lot of energy from the 9V battery is lost as waste heat. Second, having 2 separate battery packs adds weight and complexity. Wouldn’t it be much easier if we could power everything using just one battery pack?

Option 2: Voltage regulator

The addition of a voltage regulator like this one can make things much simpler. As in the wiring diagram above, you can power the motors directly from the battery pack and the Arduino can get power from the voltage regulator, which is tuned to output 5V. This approach is simpler, lighter weight, and more efficient than option 1.

A word of warning: do not try to power the motor with the output of the voltage regulator. They will draw more current than the regulator can supply and cause the voltage from the regulator to drop. When this happens your Arduino will reset, which can cause some pretty baffling problems if you don’t know what’s happening. Just power your motor directly from the battery as in the diagram.

Single Motor Control

The most important part of this project is wiring the physical components correctly. As I said in a previous post, I highly recommend wiring everything up on a breadboard. Do not make any soldered connections if you don’t absolutely have to. Rewiring is far easier when you’re using a breadboard. Below is a diagram of a wiring configuration that will work with my example sketch.

single motor control

breadboard layout for single motor control

Single Motor Example Sketch

It’s finally time for the example code! You should be able to copy and paste the code below into your Arduino IDE if you’ve wired your motor up exactly as I have in the diagram above.

// Single Motor Control example sketch
// by Andrew Kramer
// 5/28/2015

// makes the motor run at 1/2 power

#define PWMA 3 // PWM pin for right hand motor
#define AIN1 4 // direction control pin 1
               // AIN1 on the motor controller
#define AIN2 5 // direction control pin 2 
               // AIN2 pin on motor controller

void setup() {
  // set all pins to output
  for (int pin = 3; pin <= 5; pin++) {
    pinMode(pin, OUTPUT); // set pins 3 through 5 to OUTPUT
  }
  // set motor direction to forward 
  digitalWrite(AIN1, HIGH);
  digitalWrite(AIN2, LOW);
  // set the motor to run at 1/2 power
  analogWrite(PWMA, 128);
}

void loop() {
  // we're just making the motor run at a constant speed,
  // so there's nothing to do here
}

So now we can wire up a motor and feed it a constant amount of voltage. That’s useful, but not very interesting by itself. To make a differential drive robot like Colin, we need to be able to control two motors simultaneously.

Dual Motor Control

The basics of dual motor control are the same as for single motor control, we’re just adding an additional motor. Wire up your second motor as shown in the diagram below.

dual motor control

wiring diagram for dual motor control

Dual Motor Example Sketch

The sketch below, when used in a differential-drive robot will make the robot drive in a small circle. It’s a common problem to load up this example and find one or both of your motors is running backward. If this happens, you can either switch the states of the IN1 and IN2 pins for the backward motor in void setup() . Or, if you want a hardware solution, you can switch the positions of the wires connecting to IN1 and IN2 or OUT1 and OUT2.

// Dual Motor Control example sketch
// by Andrew Kramer
// 5/28/2015

// makes motor A run at 1/4 power and
// motor B run at 1/8 power
// in a differential drive robot this would cause the robot to
// drive in a small circle

#define PWMA 3 // PWM pin for right hand motor
#define AIN1 4 // direction control pin 1 for right motor
#define AIN2 5 // direction control pin 2 for right motor
#define PWMB 9 // PWM pin for left hand motor
#define BIN1 7 // direction control pin 1 for left motor
#define BIN2 8 // direction control pin 2 for left motor

void setup() {
  // set all pins to output
  for (int pin = 3; pin <= 5; pin++) {
    pinMode(pin, OUTPUT); // set pins 3 through 5 to OUTPUT
  }
  for (int pin = 7; pin <= 9; pin++) {
    pinMode(pin, OUTPUT); // set pins 7 through 9 to OUTPUT
  }
  // set both motors to forward 
  digitalWrite(AIN1, HIGH);
  digitalWrite(AIN2, LOW);
  digitalWrite(BIN1, HIGH);
  digitalWrite(BIN2, LOW);
  // set right motor to run at 1/4 power
  analogWrite(PWMA, 64);
  // set left motor to run at 1/8 power 
  analogWrite(PWMB, 32);
}

void loop() {
  // we're just making the motors run at constant speed,
  // so there's nothing to do here
}

Further Work

So now we can give two motors a constant amount of input power. That’s a bit boring, isn’t it? You can take things a bit further by making the motor speed respond to sensor inputs. For example, you could control the power to the motors using a potentiometer. You could make your differential drive robot follow more complicated paths or avoid obstacles using ultrasonic sensors, which I’ll discuss in a later post.

There’s a big problem here though. Just using analogWrite()  doesn’t control the motor’s speed, only the voltage to the motor. Even if you give both motors the same input voltage they won’t run at exactly the same speed. So you won’t be able to get a differential drive robot to drive in a straight line. For that we need actual speed control, and for that the motor needs to be able to tell the Arduino how fast it’s turning, and for that we need encoders. I’ll write a post about speed control using encoders like these soon.

 

First Pictures of Colin

Posted on by

I have an increasing number of friends and family members who use Facebook mainly as a vehicle for posting pictures of their toddlers. I try to counterbalance that by posting lots of pictures of Colin. Here’s Colin at 11 months old:

Isn't he adorable?

11 month old Colin!

Look at his cute little bluetooth radio!

Look at his cute little bluetooth radio!

I’m going to add more ultrasonic sensors soon, but this is what he looks like for now.

So far I’ve gotten him to avoid obstacles, follow walls, and I’m working on a PID motor control library. I’ll be doing a post with the technical details of motor control very soon. Stay tuned!

Designing Colin

Posted on by

I had wanted to build a robot for years and my friendly competition finally gave me a motivation: to complete my robot before Jacob’s and throw my success right in his face.

Our Problem:

It seems simple enough at first glance. We just need to create robots capable of autonomously mapping a small, indoor space such as a 1 bedroom apartment. The robots need to determine the outline of the room and map all of the obstacles (furniture, tool boxes, piles of clothes, etc) within the room. We even made a couple of concessions to speed things up: The robots do not have to operate on carpet and they are allowed to use fixed points (such as RF beacons) for navigation. Easy, right?

Of course, neither of us know very much about robotics or programming, but learning-on-the-fly is sort of the point of this exercise.

Physical Requirements:

An abandoned early design.

An abandoned early design.

I decided to sort out my robot’s physical design before worrying about software, which would likely be far more difficult. So I need to ask, what does my robot need to do?

  • Move around
  • Control its own movements
  • Power itself
  • Transmit map data to a remote computer
  • Sense its surroundings
  • Sense its location

I realized from the outset that I would probably need to change the design in response to unforeseen problems, so I also wanted my robot to be easy to rewire and reconfigure. Also, I’m not a rich man, so I need a robot that will fulfill these requirements without being absurdly expensive. This means I need to use cheap, off-the-shelf parts as much as possible and keep custom fabrication to a minimum.

Finally, I my robot needed a name. Referring to it as “my robot” is just too cumbersome. I named it Colin, after the happy security robot from Mostly Harmless by Douglas Adams.

Design

For movement I elected to go with a differential drive system, like you would find on a Roomba. It has two parallel wheels, each with its own motor. Colin can move forward or Differential drive diagram from wikipedia.backward by running his motors at the same speed and he can rotate by running them at different speeds. I also considered omni-wheels for added maneuverability but the extra complication in design and programming did not seem to be worth the benefit. I chose a pair of gearmotors and wheels from Pololu. I made sure to get motors with extended backshafts so they could be used with encoders. This will be important later. Also, most controllers can’t directly power a motor, so a motor driver circuit will be necessary as well.ArduinoDuemilanove

For control I decided to use an Arduino Duemilanove. It is functionally equivalent to the newer Arduino UNO and I had one lying around from a previous project. The computation requirements of this project are probably greater than the Arduino’s ATmega328 can handle, but it will suffice for awhile. I can always change it out later.

For power I’m using four AA batteries. I badly wanted to use a lithium polymer battery like one of these from SparkFun but the extra expense did not seem worth the slight convenience.

To transmit map data I’m using a bluetooth radio. It probably would have been easy enough to do this via USB but bluetooth gives more versatility. Colin can’t be tethered by a USB cable while he’s mapping a room, but bluetooth presents no such problem. He can send back error messages and status updates to let me know how his job is progressing. Also, it seemed like a good idea to learn how to use bluetooth.hcsr04_hires

For sensing I decided to start with HC-SR04 ultrasonic sensors. They’re fairly accurate and Arduino already has a good code library to handle them thanks to Tim Eckel. The main advantage though, is that they’re dirt cheap. If you shop around on amazon you can get them for 2 or 3 dollars apiece including shipping.

For localization (telling Colin where he is) I’m using shaft encoders on my motors. These can be used to record how far the motor shaft has turned or how fast it’s turning, allowing Colin to calculate his present position relative to where he started.

To hold everything together I’m using a very simple chassis made from laser cut ABS plastic. I made my own designs using Inkscape and had the plastic custom cut at Metrix Create:Space in Seattle.

Lastly, to ensure my design is easy to reconfigure and rewire I’m doing all of my connections using a breadboard. If you’ve never used a breadboard I suggest you make learning to use one your first step before starting any electronics project. They allow you to build circuits without soldering, so rewiring is a snap.

I’ll include details on how to put these elements together into a functioning robot in later posts. Also stand by for tips on programming and example code!

Friendly Competition

Posted on by

Almost a year ago my old friend Jacob and I were hanging out at Lake Samammish, waiting for another friend, Dan, to arrive with his boat so we could go water skiing. Dan was running late and Jacob and I killed time by talking about robots. We both wanted to build a robot, but neither of us could think of a useful task we could build a robot for, especially with our limited budgets. We talked about other peoples’ robots we’d seen on the internet. Other homebuilt robots did simple obstacle avoidance routines or balanced on two wheels like a Segway scooter. They did things that were mildly interesting but they didn’t really accomplish anything useful.

It was at this point we hit upon an idea: a robot doesn’t have to directly do anything useful in order to accomplish a worthy goal. For us that goal would be competition. We would each design, build, and program a robot to accomplish a simple task. Whomever’s robot completes the task first would be the winner.

I should mention that Jacob, who is a great guy in most respects, is also totally infuriating sometimes because he seems to have a natural talent for almost everything. I showed him how to wakeboard one spring and by the end of the summer he was doing better than most people who’ve been wakeboarding for years. He is a man who is difficult to beat. This is why I wanted to compete with him. This is a rare chance to be quantitatively better than him at something.

The challenge we set ourselves is as follows: to design, build, and program a robot capable of autonomously exploring and mapping a small, indoor space such as a one-bedroom apartment. The map must be accurate to within +/- 5 centimeters and it must be output in a common file format. All of the data collection and processing must be done by the robot itself. It cannot be controlled by a program running remotely on a separate computer.

Jacob and I both thought this would be a much easier task than it has turned out to be. It is one year later and there’s still no end in sight, although good progress has been made. Our problem: autonomous exploration was once a major issue in robotics. This wikipedia article on simultaneous localization and mapping (SLaM) does a good job of describing the problem.

I’ve been working on my robot for nearly a year now. It’s a small, differential drive robot that’s quite similar to a Roomba. I decided to name it Colin after the helpful security robot in Mostly Harmless by Douglas Adams. At the moment he’s controlled by an Arduino Duemilanove I had leftover from a previous project but I’ll probably need to upgrade to something like an Arduino Mega or Intel Edison before the project is done.

I’ll include info on Colin’s design and development process in subsequent posts. I will post design details and make my code available through GitHub so anyone can use and build upon my work. If you use my work to make something cool of your own I would love to hear about it. If you make improvements to my designs or code definitely tell me what you did and how it worked for you!