Your Smart IOT

Building an Arduino Robot, Part VI: Remote Control

Wall's Corners

Link Author

Title: Building an Arduino Robot, Part VI: Remote Control
Author: Wall's Corners
Rating 5 of 5 Des:

Welcome to the sixth article in the tutorial series in which I’m building a remote controlled Arduino based vehicle robot. Here is the lis...

Welcome to the sixth article in the tutorial series in which I’m building a remote controlled <a href="http://ift.tt/1pCdnqV" itemprop="url" target="_bank" title="Arduino">Arduino</a> based vehicle robot.
Here is the list of articles I have published so far:
<ul>
<li>
<ul>
<li><a href="http://ift.tt/1Q5a7tA">Part I: Hardware Components</a></li>
<li><a href="http://ift.tt/1VkrLl0">Part II: Programming the Arduino</a> (this article)</li>
<li><a href="http://ift.tt/1XtKBnT">Part III: Assembling the Robot</a></li>
<li><a href="http://ift.tt/1TPFUFR">Part IV: A (Not So) Basic Robot Firmware</a></li>
<li><a href="http://ift.tt/1XtKBnV">Part V: Avoiding Obstacles</a></li>
<li><a href="http://ift.tt/1VkrI8O" target="_blank">Part VI: Remote Control</a></li>
</ul>
</li>
</ul>
In the past two articles I have implemented the motor and distance sensor control for my little robot vehicle, using sound software development techniques that make this project easier to write and to maintain.
Today I will be implementing the most challenging (and let’s admit it, also the most fun) aspect of my project: the ability to remotely control the robot from a smartphone over Bluetooth.
<h2>A small improvement</h2>
Before I get into the main topic of this article I’m going to tell you about a small modification I’ve made to my robot that helps with the remote control functionality.
If you recall the article in which I showed you how to program the Bluetooth module, it is not possible to upload a sketch over USB while the Bluetooth module is connected to pins 0 and 1, because those pins are used by the USB/serial communication.
When I started writing the remote control code I became a bit frustrated with having to constantly connect and disconnect Bluetooth and USB. To avoid this hassle I decided to use the<code>SoftwareSerial.h</code> library that comes with the Arduino software to move the Bluetooth connection to a different set of pins.
The change is pretty simple. I moved the connections from the Bluetooth module going into pins 0 and 1 to analog pins 2 and 3 (numbered 16 and 17), which are unused. Then I created a<code>SoftwareSerial</code> object at the top of the sketch:
<pre class="prettyprint">
<code>#define BT_RX_PIN 16
#define BT_TX_PIN 17

#include <SoftwareSerial.h>
SoftwareSerial BTSerial(BT_RX_PIN, BT_TX_PIN);</code>
</pre>
And then, instead of using the <code>Serial</code> object like in my previous tests, I used the <code>BTSerial</code>object. The <code>setup()</code> in my sketch then changed to:
<pre class="prettyprint">
<code>void setup()
{
 Serial.begin(9600);
 BTSerial.begin(9600);
}</code>
</pre>
Why keep the <code>Serial.begin()</code> call? Because I elected to keep sending the logging output to the regular serial interface. I now have access to two serial ports, so I will use the Bluetooth connection for remote commands and the USB one for logging and debugging output. Neat!
With the Bluetooth module connected in this way there is no collision with the USB serial interface so I could keep the USB cable connected at all times while developing and testing.
<h2>Remote Control device driver</h2>
Like in the previous articles, I’m going to start by designing a device driver that can abstract the main sketch from having to deal directly with hardware.
But this case is a little different. We really have two separate pieces to abstract. The most obvious is the communication method. My robot uses Bluetooth, but this is not the only mechanism by which a robot can be controlled. At least I can think of three more, WiFi, RF and infrared. I clearly need a device driver that can read remote commands, regardless of the wireless technology used.
The second, and less obvious dimension to this problem is the remote protocol. Different remote controllers will use different command codes to mean the same thing. For example, one remote control may send the command to turn left as a byte, maybe the letter “L”. Another controller with a numeric keypad configuration may use “4” for the same thing. Another, joystick inspired remote control may not support a direct “go left” command at all and may just send instructions as vectors in a two-dimensional grid, so going left would be given as two numbers, (-1, 0). I do not really want to deal with these differences in the high-level robot code because that will make my code more complex. So clearly a driver that can hide these protocol differences from the main sketch is also needed.
So do I need two different drivers, then? Let’s think about how the main sketch will obtain remote control commands. Ideally I want something simple, like a <code>getCommand()</code> function that just returns the next command if one is available. If that’s all I need then it seems all the main sketch requires is access to one remote control driver that somehow knows how to receive remote controls and interpret them.
There are two ways this could work. If I implement two drivers, for communication and protocol separately, then the main sketch will only talk to the protocol driver, and it will be the protocol driver’s job to know what communication driver to talk to. This provides great flexibility, because the same protocol can easily be supported over different communication channels.
And what would be the alternative? I could embed the communication part inside the protocol driver. This is less flexible because now the remote protocol is tied to a particular communication channel. But on the other side it is simpler to implement because I don’t need to define a device driver for communication channels, each protocol driver does its own thing to read remote commands.
Which of these options is better? It really depends. If I was working with standard protocols that remote controls of different kinds implement, then having separate protocol and communication drivers makes sense. In this case, however, I believe the kinds of remote controls that I will find are mostly using proprietary protocols. My impression is that I will never need to use a protocol driver with more than one communication method.
Based on this analysis, I’m going to go with the simpler option for now, one driver for the combined protocol and communication handling. I can always break the driver into two in the future if I find the need.
<h3>The remote control driver interface</h3>
Given the variety of remote controls out there, I need to find a common format that all the remote drivers can use to represent commands. For the purpose of driving a vehicle, I can think of three types of remote controls that I might ever need to support:
<ul>
<li>Keypad based: the robot is controlled with directional keys or buttons.</li>
<li>Joystick based: the robot is controlled with a multi-directional stick that returns <code>(X,Y)</code>coordinates inside a circle.</li>
<li>Slider based: the robot is controlled with two sliders, in two possible configurations:
<ul>
<li>each slider controls one side of the vehicle</li>
<li>one slider controls forward/backward motion, the other controls left and right motion.</li>
</ul>
</li>
</ul>
In all cases it is safe to assume that in addition to the directional control there are a few function buttons.
As you can see there are significant differences between the types of remote controls, so the job of defining a common format for all of them is not easy.
Obviously I cannot indicate direction with simple forward, backward, left and right commands, since many remote controls can provide a finer degree of directional control and it would be a pity to ignore all that extra information.
So I have to pick one of the more advanced remote control data representations. The one that translates more easily into motor instructions for my vehicle is the one where the controller uses two sliders, each controlling one side of the vehicle. This directly translates into speeds for my two motors, so the application can simply send the data from the remote control into the motors. Since I like to keep the main sketch simple this is the approach that I’m going to take.
But there is a downside to selecting a single data representation for all types of controllers. For remote controls that don’t use the chosen format a conversion will be needed. To help with this task the base driver class will provide the conversion functions for all types of remote controls.
Let’s take a look at the definition of the remote control device driver interface:
<pre class="prettyprint">
<code>/**
 * @file remote_control.h
 * @brief remote control driver definition for the Michelino robot.
 * @author Miguel Grinberg
 */

command_t() : left(0), right(0), key(keyNone) {}

// conversion functions
 void goForward();
 void goBack();
 void turnLeft();
 void turnRight();
 void stop();
 void leftAndRightSliders(int l, int r);
 void forwardBackAndLeftRightSliders(int fb, int lf);
 void joystick(int x, int y);
 };

/**
 * @brief Class constructor.
 */
 RemoteControlDriver() {}

/**
 * @brief Return the next remote command, if available.
 * @param cmd a reference to a command_t struct where the command
 * information will be stored.
 * @return true if a remote command is available, false if not.
 */
 virtual bool getRemoteCommand(command_t& cmd) = 0;
 };
};</code>
</pre>
For this driver I will use an auxiliary <code>struct</code> that represents a remote command. The representation of a command includes left and right slider values and a possible function key. A remote control driver can provide up to four function keys, all listed in the <code>enum</code> definition.
The <code>getRemoteCommand()</code> method will be implemented by remote control drivers. It takes a reference to a <code>command_t</code> structure and is expected to fill it out appropriately, using one of the provided conversion functions if necessary.
As far as conversion functions I know I’m going to need to cover the basic remotes, with four commands to represent the four directions that they provide and one more to make the robot stop. For the more advance remotes I need to handle left and right side sliders (which really require no conversion, but for the sake of abstraction and consistency I will provide a function as well) and forward/back and left/right sliders, which as you will see in a moment also covers the joystick type controllers.
Let’s look at the implementation of the conversions:
<pre class="prettyprint">
<code> void goForward()
 {
 left = right = 255;
 }
 void goBack()
 {
 left = right = -255;
 }
 void turnLeft()
 {
 left = -255;
 right = 255;
 }
 void turnRight()
 {
 left = 255;
 right = -255;
 }
 void stop()
 {
 left = right = 0;
 }
 void leftAndRightSliders(int l, int r)
 {
 left = l;
 right = r;
 }
 void forwardBackAndLeftRightSliders(int fb, int lr)
 {
 left = fb - lr;
 right = fb + lr;
 if (left < -255)
 left = -255;
 else if (left > 255)
 left = 255;
 if (right < -255)
 right = -255;
 else if (right > 255)
 right = 255;
 }
 void joystick(int x, int y)
 {
 forwardBackAndLeftRightSliders(y, x);
 }</code>
</pre>
All but one of these are trivial. The first five just set the left and right sides appropriately, while the sixth copies the values given as arguments, since these match the internal data representation.
The next conversion is the one that requires some thought. Here I have a controller that has two sliders, one vertical to move forward or backward and one horizontal to move left or right. Both sliders can be operated independently, so at any given time the remote control provides forward/backward speed and left/right turn values. Somehow I need to use these two values to derive independent left and right values to power the motors.
The algorithm that I came up with for this conversion is relatively simple. The forward/backward slider is transferred directly into both sides, so that when there is no left/right motion the vehicle moves straight forward or backward. Then the value of the left/right slider is added to the right motor and subtracted from the left motor. If the left/right slider is positioned towards the left then it’s value will be negative, so adding it to the right side will lower the power of that side, while subtracting it from the left side will make the left side stronger. And these changes will just make the robot go towards the left side, which is what I want. Of course, the reverse happens when the left/right slider is moved towards the right.
The last conversion function is for joystick type controllers. The good news is that I realized that the joystick’s <code>(x,y)</code> coordinate values are really the same as the left/right and forward/backward values in the previous conversion functions, so I can use the same function for those.
<h3>Remote control driver implementation</h3>
My choice of controller is a free Android app called <a href="http://ift.tt/1ciuwcc" target="_blank">BlueStick</a>. Here is a screenshot of this app:
<center><img alt="Arduino Robot" src="http://ift.tt/1VmU4Qz" /></center>
This is a very simple controller with five directional commands and six function buttons. The directional commands can be triggered by touching arrow buttons on the screen or by tilting the phone. The app documentation provides the codes that are sent over Bluetooth for each of the commands:
<pre class="prettyprint">
<code>'0' = Stop
'8' = Up
'2' = Down
'4' = Left
'6' = Right
'A' = Auto Grab
'B' = Auto Release 
'C' = Grab
'D' = Release
'E' = Rotate Left
'F' = Rotate Right</code>
</pre>
Note that while this remote control app gives specific names to its six function keys, I will ignore those names and just define my own meaning for these keys.
The above list defines the protocol for this remote control, so this is really all I need to know to be able to implement this driver. So here is the code for the BlueStick driver:
<pre class="prettyprint">
<code>/**
 * @file bluestick_remote_control.h
 * @brief remote control driver for the BlueStick Android remote control app.
 * @author Miguel Grinberg
 */

#include "remote_control.h"

virtual bool getRemoteCommand(command_t& cmd)
 {
 cmd.stop();
 cmd.key = command_t::keyNone;

private:
 command_t::key_t lastKey;
 };
};</code>
</pre>
If you need a refresher on how the Bluetooth slave module works feel free to reread my <a href="http://ift.tt/1VkrI8N" target="_blank">previous post about the topic</a>.
This implementation is extremely simple. If the <code>BTSerial</code> class has a character in its queue, then I read it, and depending on what character it is I configure the command, using conversion functions for the directional commands or the key constants for the function keys. I have six function keys in this remote control app, but I decided to just use four in my driver, so I map the two extra keys as duplicates of another two.
I also need to explain what the <code>lastKey</code> member variable is for. As a test I connected the BlueStick app running on my cell phone to a Bluetooth terminal running on another phone, just to confirm that the commands the app sends are in alignment with the documentation. I found that they did match, but also found that the app is constantly sending commands. There isn’t really a point in having to handle repeated keys, so I added the <code>lastKey</code> variable to keep track of the last key received. If I find that the new key is the same as the previous one then I just throw it away as a duplicate.
Another important thing to note about this implementation is that it tries to be tolerant of unknown codes. At the start I initialize the command structure as a stop with no function keys. If I receive an unknown character then the sketch will receive a stop command, which will make the robot stop and wait for more commands.
With this basic driver implemented I have enough to incorporate and test the remote control functionality into my sketch, so that’s what I’m doing next.
<h2>Design the Remote Control Feature</h2>
But before I delve into code again, let’s discuss how is the robot going to behave, because in the previous article I ended up with a really nice and neat firmware that made the robot run standalone avoiding obstacles, and I’m not really interested in throwing all that code away!
My goal for the remote controlled robot is to incorporate the automated mode I wrote in the previous article as an option that can be enabled with a special remote command. In lack of a better name I’m going to call the automatic mode the “Roomba” mode (I hope I don’t get sued for copyright infringement!).
After some consideration I designed the following flow chart for how the robot will operate under remote control:
<div class="ezAdsense adsense adsense-midtext" style="text-align:center;margin:12px;"><script async="" src="//pagead2.googlesyndication.com/pagead/js/adsbygoogle.js" type="text/javascript">
</script> <ins class="adsbygoogle" style="display:block" data-ad-client="ca-pub-2979805726071943" data-ad-slot="7471922310" data-ad-format="auto"></ins> <script type="text/javascript">
//<![CDATA[
(adsbygoogle = window.adsbygoogle || []).push({});
//]]>
</script></div>
<center><img alt="Arduino Robot" src="http://ift.tt/1S4N6JE" /></center>
Translating the chart into words this is what I’m going to do:
<ul>
<li>The robot will begin by listening for remote commands, without moving.</li>
<li>If a command is received it will be executed, and then it will go back to listen for more commands.</li>
<li>There will be a “Roomba” mode command that acts as a toogle.</li>
<li>Any other commands sent while the robot is in “Roomba” mode will be ignored.</li>
</ul>
<h2>Adding remote control to the sketch</h2>
Okay, now I will move on to the most exciting part, which is to actually write the code to make the robot follow the remote commands.
Starting from the sketch as I left it in the previous article I begin by adding the remote control driver class to the top of the sketch, where all the drivers are:
<pre class="prettyprint">
<code>#define ENABLE_BLUESTICK_REMOTE_CONTROL_DRIVER

#ifdef ENABLE_BLUESTICK_REMOTE_CONTROL_DRIVER
#include "bluestick_remote_control.h"
#define REMOTE_CONTROL_INIT
#endif</code>
</pre>
This class does not take any arguments to initialize, but I can’t really be sure other drivers will be the same, so I keep the same style I used in previous drivers and just make the initialization constant empty this time.
Now I can add a remote control object to the <code>Robot</code> class:
<pre class="prettyprint">
<code>private:
 RemoteControl remoteControl;</code>
</pre>
And I can initialize it in the <code>Robot</code> class constructor:
<pre class="prettyprint">
<code> Robot()
 : leftMotor(LEFT_MOTOR_INIT), rightMotor(RIGHT_MOTOR_INIT),
 distanceSensor(DISTANCE_SENSOR_INIT),
 distanceAverage(TOO_CLOSE * 10),
 remoteControl(REMOTE_CONTROL_INIT)
 {
 initialize();
 }</code>
</pre>
I had been using the concept of states to know if the robot was moving or turning. I now need to have an additional state for when the robot is under remote control:
<pre class="prettyprint">
<code>private:
 enum state_t { stateStopped, stateMoving, stateTurning, stateRemote };</code>
</pre>
And since I have functions <code>stop()</code>, <code>move()</code> and <code>turn()</code> to enable the other states I should be consistent and have one to enter the remote control state:
<pre class="prettyprint">
<code> void remote()
 {
 leftMotor.setSpeed(0);
 rightMotor.setSpeed(0);
 state = stateRemote;
 }</code>
</pre>
I also had the tiny functions that returned true if a given state was enabled, to help make the code a bit more readable. Again, to be consistent I need one for the new state:
<pre class="prettyprint">
<code> bool remoteControlled() { return (state == stateRemote); }</code>
</pre>
To initialize the robot I simply put it in remote mode:
<pre class="prettyprint">
<code> void initialize()
 {
 randomSeed(analogRead(RANDOM_ANALOG_PIN));
 remote();
 }</code>
</pre>
And finally, I have a new version of my <code>run()</code> method that does all the fun stuff:
<pre class="prettyprint">
<code> void run()
 {
 unsigned long currentTime = millis();
 int distance = distanceAverage.add(distanceSensor.getDistance());
 RemoteControlDriver::command_t remoteCmd;
 bool haveRemoteCmd = remoteControl.getRemoteCommand(remoteCmd);
 log("state: %d, currentTime: %lu, distance: %u remote: (%d,l:%d,r:%d,k:%d)\n", 
 state, currentTime, distance, 
 haveRemoteCmd, remoteCmd.left, remoteCmd.right, remoteCmd.key);

if (remoteControlled()) {
 if (haveRemoteCmd) {
 switch (remoteCmd.key) {
 case RemoteControlDriver::command_t::keyF1:
 // start "roomba" mode
 move();
 break;
 case RemoteControlDriver::command_t::keyNone:
 // this is a directional command
 leftMotor.setSpeed(remoteCmd.left);
 rightMotor.setSpeed(remoteCmd.right);
 break;
 default:
 break;
 }
 }
 }
 else {
 // "roomba" mode
 if (haveRemoteCmd && remoteCmd.key == RemoteControlDriver::command_t::keyF1) {
 remote();
 }
 else {
 if (moving()) {
 if (obstacleAhead(distance))
 turn(currentTime);
 }
 else if (turning()) {
 if (doneTurning(currentTime, distance))
 move();
 }
 }
 }
 }</code>
</pre>
While this new version of <code>run()</code> may seem scary at first, I assure you that only a small portion is new, a good part of it came from the previous article.
I begin by getting all the inputs that I’m going to need, which are the current time, averaged distance sensor reading and remote control command. In case I need to do debugging at some point I kept the log statement I had before, enhanced to include remote control data as well.
For the remote control I have to note if I have received a command or not. This is what<code>haveRemoteCmd</code> does. If this variable is <code>true</code> then the <code>remoteCmd</code> struct holds the command data. If the variable is <code>false</code> then <code>remoteCmd</code> has an undefined value and should not be used.
Once I gathered all my inputs I move on to control the robot behavior. In this new version of the sketch there are two different operating modes. The “Roomba” mode was introduced in the previous article, while today I’m obviously I’m adding the remote control mode.
The <code>if (remoteControlled())</code> statement takes care of differentiating between the two modes. The <code>if</code> portion deals with the remote control mode, while the <code>else</code> portion does the “Roomba” mode.
Let’s look at the part that handles the remote control in detail:
<pre class="prettyprint">
<code> if (haveRemoteCmd) {
 switch (remoteCmd.key) {
 case RemoteControlDriver::command_t::keyF1:
 // start "roomba" mode
 move();
 break;
 case RemoteControlDriver::command_t::keyNone:
 // this is a directional command
 leftMotor.setSpeed(remoteCmd.left);
 rightMotor.setSpeed(remoteCmd.right);
 break;
 default:
 break;
 }
 }</code>
</pre>
This is extremely simple. If there is a remote command available I then look at the <code>key</code> value that came with it. If the key is <code>keyF1</code> value then I enable “Roomba” mode by calling <code>move()</code> (see the previous article for an explanation of this method). If the command came without a key (<code>keyNone</code>) then it is a directional command, so all I do is move the <code>left</code> and <code>right</code> values from the remote command into the motors. That’s it! Believe it or not this short piece of code fully handles the remote control of the vehicle!
The “Roomba” mode handling is mostly the same as in the previous article, with the exception that I removed the 30 second timeout handling that I had in that version and replaced it with this:
<pre class="prettyprint">
<code> if (haveRemoteCmd && remoteCmd.key == RemoteControlDriver::command_t::keyF1) {
 // switch back to remote mode
 remote();
 }
 else {
 // ...
 }</code>
</pre>
And this code simply switches back to remote mode if a remote command is available and its key is <code>keyF1</code>. The rest of this part deals with the “Roomba” mode logic, and this did not change from the previous version of the sketch.
<h2>A more advanced remote control driver</h2>
To end this article I’m going to implement a second remote control driver. My choice is <a href="http://ift.tt/1VmU3vZ" target="_blank">RocketBot</a>, another Android app. Here is a screenshot of RocketBot:
<center><img alt="Arduino Robot" src="http://ift.tt/1S4N6JG" /></center>
RocketBot offers several different remote control interfaces:
<ul>
<li>Keypad: five buttons for forward, backward, left, right and stop. Exactly like the BlueStick app I implemented above.</li>
<li>Joystick: X and Y values obtained from the phone accelerometer.</li>
<li>Left/Right: individual controls for left and right motors, calculated from the phone accelerometer input.</li>
</ul>
The <a href="http://ift.tt/1VmU3w2" target="_blank">documentation</a> describes the communication protocol in detail. For this controller all commands have two bytes, an operation byte and a data byte. A quick summary of the control codes I will be implementing (not the full list) is below:
<ul>
<li><code>"D1"</code>, <code>"D2"</code>, <code>"D3"</code>, <code>"D4"</code>, <code>"D5"</code>: Forward, Left, Right, Backward, and Stop respectively.</li>
<li><code>"A1"</code>, <code>"A2"</code>, <code>"A3"</code>, <code>"A4"</code>: Four auxiliary function buttons.</li>
<li><code>"X<number>"</code>, <code>"Y<number>"</code>: Joystick position. Values come in the 0-200 range, with 100 being the center position, 200 being full speed backward or right and 0 being full speed forward or left.</li>
<li><code>"L<number>"</code>, <code>"R<number>"</code>: Left/Right controls. Values come in the 0-200 range, with 100 being the center position, 200 being full speed forward and 0 being full speed backward, on each of the sides.</li>
</ul>
The implementation is a bit more complex than the BlueTick remote, but follows more or less the same style. Here is the full driver implementation:
<pre class="prettyprint">
<code>/**
 * @file rocketbot_remote_control.h
 * @brief remote control driver for the RocketBot Android remote control app.
 * @author Miguel Grinberg
 */

#include "remote_control.h"

namespace Michelino
{
 class RemoteControl : public RemoteControlDriver
 {
 public:
 /**
 * @brief Class constructor.
 * @param from the value in the 0-100 range that maps to 0 in remote control units.
 Any values below from will be interpreted as 0.
 * @param to the value in the 0-100 range that maps to 255 in remote control units.
 Any values above to will be interpreted as 255.
 */
 RemoteControl(int from, int to) : RemoteControlDriver(), 
 scaleFrom(from), scaleTo(to), 
 lastKey(command_t::keyNone), lastX(100), lastY(100), lastL(100), lastR(100) {}

if (BTSerial.available() < 2)
 return false; // no commands available
 unsigned char ch = BTSerial.read();
 unsigned char data = BTSerial.read();
 switch (ch) {
 case 'D': // keypad
 switch (data) {
 case 1:
 cmd.goForward();
 break;
 case 2: // down
 cmd.turnLeft();
 break;
 case 3: // left
 cmd.turnRight();
 break;
 case 4: // right
 cmd.goBack();
 break;
 case 5: // stop
 default:
 cmd.stop();
 break;
 }
 break;
 case 'X':
 lastX = data;
 cmd.joystick(scale(lastX), -scale(lastY));
 lastL = lastR = 100;
 break;
 case 'Y':
 lastY = data;
 cmd.joystick(scale(lastX), -scale(lastY));
 lastL = lastR = 100;
 break;
 case 'L':
 lastL = data;
 cmd.leftAndRightSliders(scale(lastL), scale(lastR));
 lastX = lastY = 100;
 break;
 case 'R':
 lastR = data;
 cmd.leftAndRightSliders(scale(lastL), scale(lastR));
 lastX = lastY = 100;
 break;
 case 'A': // function keys
 switch (data) {
 case 1:
 cmd.key = command_t::keyF1;
 break;
 case 2:
 cmd.key = command_t::keyF2;
 break;
 case 3:
 cmd.key = command_t::keyF3;
 break;
 case 4:
 cmd.key = command_t::keyF4;
 break;
 }
 break;
 default:
 break;
 }
 if (cmd.key != command_t::keyNone && cmd.key == lastKey) {
 // repeated key, ignore it
 return false; 
 }
 lastKey = cmd.key;
 return true;
 }

private:
 int scale(int value)
 {
 value -= 100;
 if (value >= 0) {
 if (value <= scaleFrom)
 return 0;
 else if (value >= scaleTo)
 return 255;
 return (value - scaleFrom) * 255 / (scaleTo - scaleFrom);
 }
 else {
 if (-value <= scaleFrom)
 return 0;
 else if (-value >= scaleTo)
 return -255;
 return -(-value - scaleFrom) * 255 / (scaleTo - scaleFrom);
 }
 }

private:
 int scaleFrom;
 int scaleTo;
 command_t::key_t lastKey;
 int lastX;
 int lastY;
 int lastL;
 int lastR;
 };
};</code>
</pre>
Unfortunately the code to handle this remote is pretty long.
The <code>RemoteControl</code> class constructor for this controller takes two arguments. These are used to scale the values returned by the remote. For example, setting <code>from = 10</code> and <code>to = 50</code> will make this driver report a 0 value for the first 10% of the tilt range in every direction and reach the maximum at the 50% tilt position. This helps in two ways. First, if you hold the phone in your hand it would be impossible to keep it at a perfect zero tilt to make the vehicle stop, so with <code>from = 10</code>there is a small range of tilt that will not affect the motors. Second, with <code>to = 50</code> I can reach the maximum position with the phone at 45 degrees instead of a full 90 degrees in each direction.
The constructor also initializes a few member variables that remember the last known values for the different controller values. These variables are necessary because the protocol this remote uses does not send the whole information in a single command, instead each command sends only one value, so for example, when I get an updated <code>X</code> value I need to know what <code>Y</code> to use, so I take it from my <code>lastY</code> member variable.
The <code>getRemoteCommand()</code> method is structured similarly to the previous driver, but here I need to read two bytes from the serial port instead of one and I have a larger number of commands to handle in the <code>switch</code> statement.
The handling of the <code>D</code> and <code>A</code> commands is similar to the other driver. Here is the snippet that handles the new commands in this controller:
<pre class="prettyprint">
<code> case 'X':
 lastX = data;
 cmd.joystick(scale(lastX), -scale(lastY));
 lastL = lastR = 100;
 break;
 case 'Y':
 lastY = data;
 cmd.joystick(scale(lastX), -scale(lastY));
 lastL = lastR = 100;
 break;
 case 'L':
 lastL = data;
 cmd.leftAndRightSliders(scale(lastL), scale(lastR));
 lastX = lastY = 100;
 break;
 case 'R':
 lastR = data;
 cmd.leftAndRightSliders(scale(lastL), scale(lastR));
 lastX = lastY = 100;
 break;</code>
</pre>
The driver could be sending <code>X</code> and <code>Y</code> commands, or it could be sending <code>L</code> and <code>R</code> depending on which mode it is in. Any time I get a command I save it in the proper member variable, and then I use the appropriate conversion function to set the <code>command_t</code> struct.
Note that I have an auxiliary function called <code>scale()</code> that takes care of the scaling using the <code>from</code>and <code>to</code> values given in the constructor.
Also interesting to note that when I get an <code>X</code> or <code>Y</code> command I reset both the <code>lastL</code> and <code>lastR</code>, to make sure I don’t keep any older values these two may have had before. Likewise, when I get an<code>L</code> or <code>R</code> I reset the <code>lastX</code> and <code>lastY</code>.
<h2>Final words</h2>
The updated firmware can be downloaded from github:
Download <a href="http://ift.tt/1S4N6JI" target="_blank">michelino v0.3</a>, or <a href="http://ift.tt/1VmU3Mi" target="_blank">clone it</a>.
As always, I welcome your questions. Feel free to drop a comment below if there is anything you did not understand or need clarification on.
With the last major piece of my robot firmware completed I could call the project done. Unfortunately I’m not satisfied that easily, even though I have fully achieved the goals I stated at the start of this tutorial series I now have the itch to try other vehicle designs, which I will try to incorporate into my <code>michelino</code> firmware.
You may also want to keep track of the <a href="http://ift.tt/1xS5Bq7" target="_blank">“master” branch</a> of the project on github, as that’s where updates will show up.
I’m particularly interested in supporting other motor controllers and more remote controls. If you have any you would like to see implemented let me know, or better yet, fork my project on github, implement it yourself and send me a pull request to get it included in the official project.
Thank you for following me on this tutorial, I hope my articles were of help to you. Best of luck with your Arduino based projects!
Miguel
<div id="huge-it-share-buttons-top" class="huge-it-share-buttons nobackground">
<h3>Share This:</h3>
<ul class="huge-it-share-buttons-list">
<li class=" nobackground"><a href="http://ift.tt/1LIxY7s" id="backforunical508" name="backforunical508" onclick="javascript:void window.open('http://ift.tt/1LIxY7s','1410949501326','width=700,height=500,toolbar=0,menubar=0,location=0,status=1,scrollbars=1,resizable=1,left=0,top=0');return false;" style="background-position: -0px -120px" target="_blank"></a></li>
<li class=" nobackground"><a href="https://twitter.com/share?status=http://yoursmart.mobi/feed&text=Building%20an%20Arduino%20Robot,%20Part%20VI:%20Remote%20Control" id="backforunical508" name="backforunical508" onclick="javascript:void window.open('https://twitter.com/share?status=http://yoursmart.mobi/feed&text=Building an Arduino Robot, Part VI: Remote Control','1410949501326','width=700,height=500,toolbar=0,menubar=0,location=0,status=1,scrollbars=1,resizable=1,left=0,top=0');return false;" style="background-position: -30px -120px" target="_blank"></a></li>
<li class=" nobackground"><a href="http://ift.tt/1Q5a5lo%20an%20Arduino%20Robot,%20Part%20VI:%20Remote%20Control" id="backforunical508" name="backforunical508" onclick="javascript:void window.open('http://ift.tt/1Q5a5lo an Arduino Robot, Part VI: Remote Control','1410949501326','width=700,height=500,toolbar=0,menubar=0,location=0,status=1,scrollbars=1,resizable=1,left=0,top=0');return false;" style="background-position: -60px -120px" target="_blank"></a></li>
<li class=" nobackground"><a href="http://ift.tt/1LIxZZ0" id="backforunical508" name="backforunical508" onclick="javascript:void window.open('http://ift.tt/1LIxZZ0','1410949501326','width=700,height=500,toolbar=0,menubar=0,location=0,status=1,scrollbars=1,resizable=1,left=0,top=0');return false;" style="background-position: -90px -120px" target="_blank"></a></li>
<li class=" nobackground"><a href="http://ift.tt/1VkrL4x%20an%20Arduino%20Robot,%20Part%20VI:%20Remote%20Control&mini=true&url=http://ift.tt/1LIxZZ4" id="backforunical508" name="backforunical508" onclick="javascript:void window.open('http://ift.tt/1VkrL4x an Arduino Robot, Part VI: Remote Control&mini=true&url=http://ift.tt/1LIxZZ4','1410949501326','width=700,height=500,toolbar=0,menubar=0,location=0,status=1,scrollbars=1,resizable=1,left=0,top=0');return false;" style="background-position: -120px -120px" target="_blank"></a></li>
<li class=" nobackground"><a href="http://ift.tt/1Q5a7dc%20an%20Arduino%20Robot,%20Part%20VI:%20Remote%20Control" id="backforunical508" name="backforunical508" onclick="javascript:void window.open('http://ift.tt/1Q5a7dc an Arduino Robot, Part VI: Remote Control','1410949501326','width=700,height=500,toolbar=0,menubar=0,location=0,status=1,scrollbars=1,resizable=1,left=0,top=0');return false;" style="background-position: -150px -120px" target="_blank"></a></li>
<li class=" nobackground"><a href="http://ift.tt/1VkrL4B%20an%20Arduino%20Robot,%20Part%20VI:%20Remote%20Control" id="backforunical508" name="backforunical508" onclick="javascript:void window.open('http://ift.tt/1VkrL4B an Arduino Robot, Part VI: Remote Control','1410949501326','width=700,height=500,toolbar=0,menubar=0,location=0,status=1,scrollbars=1,resizable=1,left=0,top=0');return false;" style="background-position: -180px -120px" target="_blank"></a></li>
<li class=" nobackground"><a href="http://ift.tt/1Q5a7dg%20an%20Arduino%20Robot,%20Part%20VI:%20Remote%20Control" id="backforunical508" name="backforunical508" onclick="javascript:void window.open('http://ift.tt/1Q5a7dg an Arduino Robot, Part VI: Remote Control','1410949501326','width=700,height=500,toolbar=0,menubar=0,location=0,status=1,scrollbars=1,resizable=1,left=0,top=0');return false;" style="background-position: -210px -120px" target="_blank"></a></li>
<li class=" nobackground"><a href="http://ift.tt/1LIxY7u" id="backforunical508" name="backforunical508" onclick="javascript:void window.open('http://ift.tt/1LIxY7u','1410949501326','width=700,height=500,toolbar=0,menubar=0,location=0,status=1,scrollbars=1,resizable=1,left=0,top=0');return false;" style="background-position: -240px -120px" target="_blank"></a></li>
<li class="none nobackground"><a href="http://ift.tt/1VkrL4D%20an%20Arduino%20Robot,%20Part%20VI:%20Remote%20Control" id="backforunical508" name="backforunical508" onclick="javascript:void window.open('http://ift.tt/1VkrL4D an Arduino Robot, Part VI: Remote Control','1410949501326','width=700,height=500,toolbar=0,menubar=0,location=0,status=1,scrollbars=1,resizable=1,left=0,top=0');return false;" style="background-position: -270px -120px" target="_blank"></a></li>
<li class="none nobackground"><a href="http://ift.tt/1Q5a7tu%20an%20Arduino%20Robot,%20Part%20VI:%20Remote%20Control" id="backforunical508" name="backforunical508" onclick="javascript:void window.open('http://ift.tt/1Q5a7tu an Arduino Robot, Part VI: Remote Control','1410949501326','width=700,height=500,toolbar=0,menubar=0,location=0,status=1,scrollbars=1,resizable=1,left=0,top=0');return false;" style="background-position: -300px -120px" target="_blank"></a></li>
<li class="none nobackground"><a href="http://ift.tt/1o7SuTq" id="backforunical508" name="backforunical508" onclick="javascript:void window.open('http://ift.tt/1o7SuTq','1410949501326','width=700,height=500,toolbar=0,menubar=0,location=0,status=1,scrollbars=1,resizable=1,left=0,top=0');return false;" style="background-position: -330px -120px" target="_blank"></a></li>
<li class="none nobackground"><a href="http://ift.tt/1VkrNJI%20an%20Arduino%20Robot,%20Part%20VI:%20Remote%20Control" id="backforunical508" name="backforunical508" onclick="javascript:void window.open('http://ift.tt/1VkrNJI an Arduino Robot, Part VI: Remote Control','1410949501326','width=700,height=500,toolbar=0,menubar=0,location=0,status=1,scrollbars=1,resizable=1,left=0,top=0');return false;" style="background-position: -360px -120px" target="_blank"></a></li>
<li class="none nobackground"><a href="http://ift.tt/1o7SuTs" id="backforunical508" name="backforunical508" onclick="javascript:void window.open('http://ift.tt/1o7SuTs','1410949501326','width=700,height=500,toolbar=0,menubar=0,location=0,status=1,scrollbars=1,resizable=1,left=0,top=0');return false;" style="background-position: -390px -120px" target="_blank"></a></li>
<li class="none nobackground"><a href="http://ift.tt/1Q5a5ls%20an%20Arduino%20Robot,%20Part%20VI:%20Remote%20Control" id="backforunical508" name="backforunical508" onclick="javascript:void window.open('http://ift.tt/1Q5a5ls an Arduino Robot, Part VI: Remote Control','1410949501326','width=700,height=500,toolbar=0,menubar=0,location=0,status=1,scrollbars=1,resizable=1,left=0,top=0');return false;" style="background-position: -420px -120px" target="_blank"></a></li>
<li class="none nobackground"><a href="http://ift.tt/1VkrLkV%20an%20Arduino%20Robot,%20Part%20VI:%20Remote%20Control&pic=&ralateUid=&" id="backforunical508" name="backforunical508" onclick="javascript:void window.open('http://ift.tt/1VkrLkV an Arduino Robot, Part VI: Remote Control&pic=&ralateUid=&','1410949501326','width=700,height=500,toolbar=0,menubar=0,location=0,status=1,scrollbars=1,resizable=1,left=0,top=0');return false;" style="background-position: -450px -120px" target="_blank"></a></li>
<li class="none nobackground"><a href="http://ift.tt/1Q5a7ty%20an%20Arduino%20Robot,%20Part%20VI:%20Remote%20Control" id="backforunical508" name="backforunical508" onclick="javascript:void window.open('http://ift.tt/1Q5a7ty an Arduino Robot, Part VI: Remote Control','1410949501326','width=700,height=500,toolbar=0,menubar=0,location=0,status=1,scrollbars=1,resizable=1,left=0,top=0');return false;" style="background-position: -480px -120px" target="_blank"></a></li>
<li class="none nobackground"><a href="http://ift.tt/1VkrNJM%20an%20Arduino%20Robot,%20Part%20VI:%20Remote%20Control" id="backforunical508" name="backforunical508" onclick="javascript:void window.open('http://ift.tt/1VkrNJM an Arduino Robot, Part VI: Remote Control','1410949501326','width=700,height=500,toolbar=0,menubar=0,location=0,status=1,scrollbars=1,resizable=1,left=0,top=0');return false;" style="background-position: -510px -120px" target="_blank"></a></li>
</ul>
<div class="clear"></div>
</div>
View more at: <a href="http://yoursmart.mobi/">http://yoursmart.mobi</a>

Building an Arduino Robot, Part VI: Remote Control

Welcome to the sixth article in the tutorial series in which I’m building a remote controlled Arduino based vehicle robot. Here is the lis...

Building an Arduino Robot, Part V: Avoiding Obstacles

Wall's Corners

Link Author

Title: Building an Arduino Robot, Part V: Avoiding Obstacles
Author: Wall's Corners
Rating 5 of 5 Des:

Welcome to the fifth article in the tutorial series in which I’m building a remote controlled Arduino based vehicle robot. Here is the list...

Welcome to the fifth article in the tutorial series in which I’m building a remote controlled Arduino based vehicle robot.
Here is the list of articles I have published so far:
<ul>
<li>
<ul>
<li><a href="http://ift.tt/1Q5a7tA">Part I: Hardware Components</a></li>
<li><a href="http://ift.tt/1VkrLl0">Part II: Programming the Arduino</a> (this article)</li>
<li><a href="http://ift.tt/1XtKBnT">Part III: Assembling the Robot</a></li>
<li><a href="http://ift.tt/1TPFUFR">Part IV: A (Not So) Basic Robot Firmware</a></li>
<li><a href="http://ift.tt/1XtKBnV">Part V: Avoiding Obstacles</a></li>
<li><a href="http://ift.tt/1VkrI8O" target="_blank">Part VI: Remote Control</a></li>
</ul>
</li>
</ul>
In the <a href="http://ift.tt/1S4N6Jr" target="_blank">previous article</a> I wrote a first version of my Michelino robot firmware that included a motor controller driver. Today I’m adding support for the distance sensor.
<h2>Distance Sensor driver</h2>
As I have shown in the last article, my firmware can handle any motor controller board as long as a device driver is written for it. A device driver in this context is nothing more than a class that implements the generic interface that I have defined for devices of this class.
Distance sensors are no different, the same idea can be applied to them. I’ll start by defining the interface that will be common to all distance sensor devices. This will go in file<code>distance_sensor.h</code>:
<pre class="prettyprint">
<code>/**
 * @file distance_sensor.h
 * @brief distance sensor driver definition for the Michelino robot.
 * @author Miguel Grinberg
 */

/**
 * @brief Return the distance to the nearest obstacle in centimeters.
 * @return the distance to the closest object in centimeters 
 * or maxDistance if no object was detected
 */
 virtual unsigned int getDistance() = 0;

protected:
 unsigned int maxDistance;
 };
};</code>
</pre>
My distance sensor driver is going to be extremely simple, a driver just needs to provide one method that reports the distance to the nearest object in centimeters. This is all I need for now, I can always come back and add more functionality to the driver definition later.
The constructor to the driver takes a maximum distance. This is the value that <code>getDistance()</code> will return when there is no detected obstacle.
Note that <code>maxDistance</code> member variable is in a <code>protected</code> block, not a <code>private</code> block like I used in other classes. Variables that are <code>protected</code> are still private to the outside, but they are accessible to subclasses. I want this value to be accessible to implementations of this driver, that’s why I made it <code>protected</code>.
As I mentioned in a past article, I have found that the HC-SR04 distance sensor that I’m using works really well with the <a href="http://ift.tt/1Q5a7tM" target="_blank">arduino-new-ping</a> open source library, so I’ll now implement the above driver interface for it in file <code>newping_distance_sensor.h</code>:
<pre class="prettyprint">
<code>/**
 * @file newping_distance_sensor.h
 * @brief distance sensor driver for distance sensors supported by the NewPing library.
 * @author Miguel Grinberg
 */

#include "distance_sensor.h"

namespace Michelino
{
 class DistanceSensor : public DistanceSensorDriver
 {
 public:
 DistanceSensor(int triggerPin, int echoPin, int maxDistance)
 : DistanceSensorDriver(maxDistance), 
 sensor(triggerPin, echoPin, maxDistance)
 {
 }

virtual unsigned int getDistance()
 {
 int distance = sensor.ping_cm();
 if (distance <= 0)
 return maxDistance;
 return distance;
 }
 private:
 NewPing sensor;
 };
};</code>
</pre>
Note in the <code>getDistance()</code> implementation how the <code>maxDistance</code> member variable defined in the parent class is accessible. If I had defined this variable in a <code>private</code> block this code would not compile.
<h2>Integration with the firmware</h2>
As a first integration test let’s make the robot go forward and stop when it finds an obstacle.
I will start from the firmware I wrote in the <a href="http://ift.tt/1S4N6Jr" target="_blank">previous article</a> and will just replace the <code>initialize()</code>and <code>run()</code> methods, which are my object oriented counterparts to the Arduino’s <code>setup()</code> and<code>loop()</code> functions. You may want to go back to that article to see the structure of the complete sketch if you are not familiar with it.
At the top of the sketch I include the driver using the same structure I used for the motor controller:
<pre class="prettyprint">
<code>#define ENABLE_NEWPING_DISTANCE_SENSOR_DRIVER

#ifdef ENABLE_NEWPING_DISTANCE_SENSOR_DRIVER
#include <NewPing.h>
#include "newping_distance_sensor.h"
#define DISTANCE_SENSOR_INIT 14,15,MAX_DISTANCE
#endif</code>
</pre>
In the <code>private</code> section of the <code>Robot</code> class a <code>DistanceSensor</code> object is created:
<pre class="prettyprint">
<code>private:
 DistanceSensor distanceSensor;</code>
</pre>
In the <code>Robot</code> class constructor the object is initialized:
<pre class="prettyprint">
<code>Robot()
 : leftMotor(LEFT_MOTOR_INIT), rightMotor(RIGHT_MOTOR_INIT),
 distanceSensor(DISTANCE_SENSOR_INIT)
{
 initialize();
}</code>
</pre>
In the <code>initialize()</code> method I start the motors and set the state to running:
<pre class="prettyprint">
<code>void initialize()
{
 leftMotor.setSpeed(255);
 rightMotor.setSpeed(255);
 state = stateRunning;
}</code>
</pre>
And in the <code>run()</code> method I stop the motors when the distance sensor finds a close obstacle:
<pre class="prettyprint">
<code>void run()
{
 if (state == stateRunning) {
 if (distanceSensor.getDistance() <= TOO_CLOSE) {
 state = stateStopped;
 leftMotor.setSpeed(0);
 rightMotor.setSpeed(0);
 }
 }
}</code>
</pre>
I have used two constants in all the changes above, <code>MAX_DISTANCE</code> and <code>TOO_CLOSE</code>. These constants are defined at the top of the sketch, so that they are easy to find in case they need to be modified:
<pre class="prettyprint">
<code>#define TOO_CLOSE 10
#define MAX_DISTANCE (TOO_CLOSE * 20)</code>
</pre>
I’m going to use 10cm as the distance to consider an obstacle too close. The maximum distance I need to track will be twenty times that, or 2 meters. These are numbers that I pulled out of thin air, I don’t really know if they will work or not, but I can always come back and adjust them after I get a chance to test them.
The sketch is now in a usable state. Below is the complete <code>michelino.ino</code> sketch source code:
<pre class="prettyprint">
<code>#define ENABLE_ADAFRUIT_MOTOR_DRIVER
#define ENABLE_NEWPING_DISTANCE_SENSOR_DRIVER

#define TOO_CLOSE 10
#define MAX_DISTANCE (TOO_CLOSE * 20)

#ifdef ENABLE_ADAFRUIT_MOTOR_DRIVER
#include <AFMotor.h>
#include "adafruit_motor_driver.h"
#define LEFT_MOTOR_INIT 1
#define RIGHT_MOTOR_INIT 3
#endif

#ifdef ENABLE_NEWPING_DISTANCE_SENSOR_DRIVER
#include <NewPing.h>
#include "newping_distance_sensor.h"
#define DISTANCE_SENSOR_INIT 14,15,MAX_DISTANCE
#endif

namespace Michelino
{
 class Robot
 {
 public:
 /*
 * @brief Class constructor.
 */
 Robot()
 : leftMotor(LEFT_MOTOR_INIT), rightMotor(RIGHT_MOTOR_INIT),
 distanceSensor(DISTANCE_SENSOR_INIT)
 {
 initialize();
 }

/*
 * @brief Initialize the robot state.
 */
 void initialize()
 {
 leftMotor.setSpeed(255);
 rightMotor.setSpeed(255);
 state = stateRunning;
 }
 /*
 * @brief Update the state of the robot based on input from sensor and remote control.
 * Must be called repeatedly while the robot is in operation.
 */
 void run()
 {
 if (state == stateRunning) {
 if (distanceSensor.getDistance() <= TOO_CLOSE) {
 state = stateStopped;
 leftMotor.setSpeed(0);
 rightMotor.setSpeed(0);
 }
 }
 }

private:
 Motor leftMotor;
 Motor rightMotor;
 DistanceSensor distanceSensor;
 enum state_t { stateStopped, stateRunning };
 state_t state;
 };
};

Michelino::Robot robot;

void setup()
{
 robot.initialize();
}

void loop()
{
 robot.run();
}</code>
</pre>
Under the control of this sketch the robot will run until it gets 10cm or less from a wall or other obstacle and then stop.
If you are building a robot like mine and give the sketch a try you may find that the robot functions as expected most of the times, but not always. Occasionally it may stop even though there is no close obstacle, or other times it may bump into a wall without stopping. Keep on reading to know how I figured out the problem and how I addressed it.
<h2>Logging</h2>
Running the above sketch a few times makes it clear that something unexpected is going on, but how can I find out what is it? I really need to see all the data the sketch is receiving and how it is reacting to it to understand why things aren’t going the way I expected them to go. In other words, I need to <a href="http://ift.tt/ReSEEX" target="_blank">debug</a> my sketch.
A pretty useful technique to debug embedded systems like this one is to write information passing through the application to a log that can be reviewed.
To be able to log from my sketch I’m going to write a logging function that will have the same arguments as the good old <code>printf()</code> function from the C standard library, except that since my robot does not have a screen the output will go to the serial port, which I can capture from the Arduino software running on my PC, or alternatively to my cell phone via bluetooth. I’m going to call this function <code>log()</code>. Here is an example usage:
<pre class="prettyprint">
<code>unsigned int distance = distanceSensor.getDistance();
log("distance: %u\n", distance);</code>
</pre>
One aspect to consider is that once I correct this problem I may not want to continue sending logging data to the serial port. This is really an operation that is not needed during normal operation, it is only useful for debugging. But if I remove the log statements from my sketch once I have found a solution to my problem I will have to write them all again next time I have to debug. What I want is to keep the logging calls in the sketch, but selectively be able to enable or disable them. I’m going to use a C preprocessor trick to do this. Below is the source code of my logging function, partially based on the implementation of the <code>p</code> function in <a href="http://ift.tt/1S4N6Jt" target="_blank">this Arduino playground page</a>. I’m going to put it in a file named <code>logging.h</code>:
<pre class="prettyprint">
<code>#ifdef LOGGING

// logging is enabled
#include <stdarg.h>

void log(char* format, ...)
{
 char line[1024];
 va_list args;
 va_start(args, format);
 vsnprintf(line, sizeof(line), format, args);
 va_end(args);
 Serial.print(line);
}

#else

// logging is disabled
#define log(...)

#endif</code>
</pre>
This code defines two versions of the <code>log()</code> function. If the <code>LOGGING</code> constant is defined the<code>log()</code> function does all the work to print data to the serial port. But if the <code>LOGGING</code> constant is not defined then the <code>log()</code> function isn’t really defined as a function but as a macro or constant using<code>#define</code>, with a completely empty definition. What this means is that if <code>LOGGING</code> is not defined in the main sketch, then the compiler will consider any calls to the <code>log()</code> function as an empty line, so no code will be generated. But when I need to debug I can just define <code>LOGGING</code> at the top of my sketch and all the logging statements will magically get included in the firmware.
To enable logging in my sketch I’ve added the following near the top of the main <code>michelino.ino</code>file:
<pre class="prettyprint">
<code>#define LOGGING
#include "logging.h"</code>
</pre>
Then I changed my <code>run()</code> function as follows:
<pre class="prettyprint">
<code>void run()
{
 if (state == stateRunning) {
 unsigned int distance = distanceSensor.getDistance();
 log("distance: %u\n", distance);
 if (distance <= TOO_CLOSE) {
 state = stateStopped;
 leftMotor.setSpeed(0);
 rightMotor.setSpeed(0);
 }
 }
}</code>
</pre>
Then I connected the robot to my computer with a long USB cable, uploaded the sketch and watched the output in the serial monitor. I had to do a few runs to get the problem to occur, but in two out of about twenty the robot stopped when there was no close obstacle.
One of the failures was immediately after the sketch started running. Here is the log for that session:
<pre class="prettyprint">
<code>distance: 63
distance: 74
distance: 5</code>
</pre>
The 63 and 74cm numbers were about right for the distance to the wall, but the 5cm came out of the blue, without nothing being that close to the robot.
The other failure I captured was also odd, the robot was several meters away from a wall, so it was logging the maximum distance value, but check out what happened at some point:
<pre class="prettyprint">
<code>distance: 200
distance: 200
distance: 200
distance: 200
distance: 200
distance: 7</code>
</pre>
Based on these two failures I was able to formulate a theory that explains my problem.
The sensor works by emitting an ultrasonic ping and waiting for the sound wave to bounce off of an obstacle and reach the sensor back. This measurement technique isn’t precise by far and is bound to produce errors from time to time. Sometimes the wave may bounce on the floor and somehow make it back to the sensor, other times it may bounce off of a surface that absorbs sound, so the bounced signal is weak and the sensor misses it. The fact is, the readings from the distance sensor aren’t always reliable.
<h2>Averaging</h2>
With the help of logging to the serial interface I found out that the sensor isn’t 100% reliable. So what can I do? One way to greatly improve its accuracy is to not react to a single reading, it’s better to take several readings and make sure they are consistent before causing a state change in the robot.
The technique I’m going to use to filter out errors or noise is pretty simple, I’m just going to take a few readings and average them.
But doing multiple readings each time I need to check for obstacles will make the robot response slower, so ideally I want to find a way to get the benefit of averaging multiple readings without having to sacrifice performance. The <a href="http://ift.tt/VzwNd6" target="_blank">moving average</a> algorithm solves this problem nicely.
A moving average works incrementally. Let’s say I decide to use an average of three readings. Each time I need to obtain data from the sensor I take a single reading, but I don’t use that result directly. Instead, I compute an average between that reading and the previous two. The next time I need to read the sensor I get another reading, just one like before. Now I drop the oldest of the three readings I averaged the previous time and add this new one. So I’m always adding the new reading and dropping the oldest from the average.
To make it more clear let’s look at an example:
<table class="data">
<tbody>
<tr>
<th>Sensor readings</th>
<td>200</td>
<td>200</td>
<td>200</td>
<td>200</td>
<td>7</td>
<td>200</td>
<td>200</td>
<td>7</td>
<td>7</td>
<td>5</td>
</tr>
<tr>
<th>Moving Average with N=3</th>
<td></td>
<td></td>
<td>200</td>
<td>200</td>
<td>135</td>
<td>135</td>
<td>135</td>
<td>135</td>
<td>71</td>
<td>6</td>
</tr>
</tbody>
</table>
Without the moving average the robot would have stopped at the first <code>7</code>, like it did for me in one of the failures I captured logs for. But with the moving average the numbers only get down to below<code>TOO_CLOSE</code> when three consecutive readings are low, so the robot ignored that first <code>7</code> as an abnormality, but after three readings came up low the average finally reflected that.
This technique can be pretty useful, so instead of hard coding it into the distance sensor driver I will create a generic moving average class that I can then apply to other types of samples. I will put this class in file <code>moving_average.h</code>:
<pre class="prettyprint">
<code>/**
 * @file moving_average.h
 * @brief Helper class that maintains a moving average over a set of samples.
 * @author Miguel Grinberg
 */

template <typename V, int N> class MovingAverage
{
public:
 /*
 * @brief Class constructor.
 * @param def the default value to initialize the average.
 */
 MovingAverage(V def = 0) : sum(0), p(0)
 {
 for (int i = 0; i < N; i++) {
 samples[i] = def;
 sum += samples[i];
 }
 }

/*
 * @brief Add a new sample.
 * @param new_sample the new sample to add to the moving average.
 * @return the updated average.
 */
 V add(V new_sample)
 {
 sum = sum - samples[p] + new_sample;
 samples[p++] = new_sample;
 if (p >= N)
 p = 0;
 return sum / N;
 }

private:
 V samples[N];
 V sum;
 V p;
};</code>
</pre>
The <code>MovingAverage</code> class is different than classes I wrote before. This class begins with a<code>template</code> declaration, which basically makes this class a sort of model from which many other classes can be constructed. The reason to make it a template class is that moving averages can be computed on samples of different types. For the distance sensor I’m going to be using<code>unsigned int</code> values, but in the future I may need to use the same algorithm for values of type<code>float</code>, <code>double</code> or even a user defined type. The template argument <code>V</code> declared right after the template <a href="http://ift.tt/1UQBgqN" itemprop="url" target="_bank" title="keyboard">keyboard</a> takes care of that. Anywhere in the class where I use the <code>V</code> type the compiler will replace it with an actual type provided when an object of the class is created. The second template argument <code>N</code> is used to declare how many samples need to be kept in memory to do the average. In my example I will use three, but I may need more for other purposes. So instead of making the class use a fix size of three I can call the size <code>N</code> and once again the compiler will replace it with the proper value for each instance. If I wanted to create the instance for the distance sensor I would do it like this:
<pre class="prettyprint">
<code>MovingAverage<unsigned int, 3> average;</code>
</pre>
Note that the class constructor takes an argument that by default is 0. This is the default sample value, the value that will be used to do the average before I have seen three samples.
The implementation uses a <a href="http://ift.tt/otr1YI" target="_blank">circular buffer</a> with size <code>N</code>, which is initialized to the default sample value in the constructor. I also have a <code>sum</code> member variable that keeps the sum of the <code>N</code> samples that are in memory, and a <code>p</code> member varialble that indicates what is the entry in the circular buffer where the next sample will be stored.
When a new sample is obtained it is added to the moving average via the <code>add()</code> method. The implementation stores the new sample in the circular buffer and moves the pointer <code>p</code> to the next entry. The <code>sum</code> is reduced by the value of the oldest sample (the one that is getting replaced) and increased by the value of the new sample. Finally, the new average is calculated and returned.
How is this class used in the robot firmware? First I need to include the header file in the main sketch:
<pre class="prettyprint">
<code>#include "moving_average.h"</code>
</pre>
Then I need to declare a <code>MovingAverage</code> object in the <code>private</code> section of the <code>Robot</code> class:
<pre class="prettyprint">
<code>private:
 MovingAverage<unsigned int, 3> distanceAverage;</code>
</pre>
Then I need to initialize it in the <code>Robot</code> constructor:
<pre class="prettyprint">
<code>Robot()
 : leftMotor(LEFT_MOTOR_INIT), rightMotor(RIGHT_MOTOR_INIT),
 distanceSensor(DISTANCE_SENSOR_INIT),
 distanceAverage(MAX_DISTANCE)
{
 initialize();
}</code>
</pre>
Note that I initialize the moving average with my <code>MAX_DISTANCE</code> constant, to make sure I don’t detect an obstacle when I start.
The <code>initialize()</code> function does not change. The <code>run()</code> function changes as follows:
<pre class="prettyprint">
<code>void run()
{
 if (state == stateRunning) {
 int distance = distanceAverage.add(distanceSensor.getDistance());
 log("distance: %u\n", distance);
 if (distance <= TOO_CLOSE) {
 state = stateStopped;
 leftMotor.setSpeed(0);
 rightMotor.setSpeed(0);
 }
 }
}</code>
</pre>
And with this simple enhancement the readings from the distance sensor are a lot more reliable!
<h2>Turning</h2>
Stopping when finding an obstacle is not much fun. Real robots don’t just stop in front of obstacles, they find ways to avoid them and keep moving.
This robot has very simple vision and motion systems, so its obstacle avoidance algorithm will also be pretty basic. What I’m going to do when the robot detects an obstacle ahead is to rotate in place for a while until no more nearby obstacles are detected and then move forward in the new direction.
In essence this algorithm should make my little robot behave like a <a href="http://ift.tt/17LK61p" target="_blank">Roomba</a>. I can just attach a brush to it and have it swipe my floors!
<h2>The algorithm</h2>
I have used the concept of a <code>state</code> to make my robot have an idea what it is doing at any given time. Now that I’m also going to make the robot turn I need to define different states:
<pre class="prettyprint">
<code> enum state_t { stateStopped, stateMoving, stateTurning };</code>
</pre>
The “stopped” state will be for when the robot is not moving at all. The “moving” state will be for when the robot is moving forward. Finally, the “turning” state will be used while the robot is turning.
The algorithm that I’m going to use in the <code>run()</code> method of my turn enabled firmware will be as follows:
<center><img alt="Arduino Robot" src="http://ift.tt/1VmU3vT" /></center>
In the above diagram diamond shapes represent decisions and boxes represent processes or state changes.
The robot will begin in <code>stateMoving</code> state and will run for a limited amount of time, after which will change to the <code>stateStopped</code> state. The first two decisions in the flowchart address that part of the logic.
If the robot is in <code>stateMoving</code> it will check for obstacles, and if one is found it will turn, which changes the state to <code>stateTurning</code>. If no obstacles are found then it will not change its state.
If the robot is in <code>stateTurning</code> it will check if it is done turning, at which point it will change back to<code>stateMoving</code>. If the turn isn’t complete then it will remain in the same state.
Pretty simple, right?
Recall that this is going to be inside the <code>run()</code> method, so as soon as this algorithm completes a pass the method will be called again, so this algorithm will run repeatedly.
Since I feel pretty strongly about writing readable code I’m going to try to map the above diagram into code as directly as possible. Here is a first attempt to write my <code>run()</code> method:
<pre class="prettyprint">
<code> void run()
 {
 if (stopped())
 return;
 else if (doneRunning())
 stop();
 else if (moving()) {
 if (obstacleAhead())
 turn();
 }
 else if (turning()) {
 if (doneTurning())
 move();
 }
 }</code>
</pre>
What do you think? This is very readable code, right? I don’t think I would have any trouble understanding this code if I come back to it after a long time away from the project.
Now you may say that I’m cheating, that I just created an outline of the algorithm but in essence all I’m doing is calling functions that don’t exist.
I’m not cheating. This is called <a href="http://ift.tt/1geueWj" target="_blank">top down design</a>, I start with the big pieces and then move on to the smaller ones. I will implement all the functions referenced above one by one, and by the end of the article I will have a fully functional sketch with a <code>run()</code> method that looks very close to the above.
Let me start by describing what each supporting function does.
<ul>
<li><code>stopped()</code> returns <code>true</code> if the robot is in <code>stateStopped</code> state or <code>false</code> otherwise.</li>
<li><code>doneRunning()</code> returns <code>true</code> if the robot was up and running for a predetermined amount of time, which in my case I’ll set to 30 seconds. <code>false</code> is returned otherwise.</li>
<li><code>stop()</code> changes the robot state to <code>stateStopped</code>.</li>
<li><code>moving()</code> returns <code>true</code> if the robot is in the <code>stateMoving</code> state or <code>false</code> otherwise.</li>
<li><code>obstacleAhead()</code> returns <code>true</code> if there is an obstacle in close distance or <code>false</code> otherwise.</li>
<li><code>turn()</code> initiates a turn. The state of the robot is changed to <code>stateTurning</code> as a result.</li>
<li><code>turning()</code> returns <code>true</code> if the robot is in <code>stateTurning</code> state or <code>false</code> otherwise.</li>
<li><code>doneTurning()</code> returns <code>true</code> if the turn maneuver is complete or <code>false</code> otherwise.</li>
<li><code>move()</code> changes the robot state to <code>stateMoving</code>.</li>
</ul>
<h2>Implementing the turn enabled robot firmware</h2>
I now have nine auxiliary functions used by my <code>run()</code> method that I need to implement. I will start with three really easy ones:
<pre class="prettyprint">
<code> bool moving() { return (state == stateMoving); }
 bool turning() { return (state == stateTurning); }
 bool stopped() { return (state == stateStopped); }</code>
</pre>
I could have checked the <code>state</code> variable directly in the <code>run()</code> method, but these make the code in <code>run()</code> more readable. The <a href="http://ift.tt/1VmU4Qs" itemprop="url" target="_bank" title="C++">C++</a> compiler is pretty smart and will generate the same code either way.
There are two more functions from the above list that are pretty easy to implement:
<pre class="prettyprint">
<code> void move()
 {
 leftMotor.setSpeed(255);
 rightMotor.setSpeed(255);
 state = stateMoving;
 }

void stop()
 {
 leftMotor.setSpeed(0);
 rightMotor.setSpeed(0);
 state = stateStopped;
 }</code>
</pre>
Five functions done, four more to go!
Let’s look at <code>doneRunning()</code>.
This function needs to return <code>true</code> after 30 seconds have passed or <code>false</code> otherwise. I have discussed how to time out actions in the previous article, so this presents no challenge.
I will start by adding a member variable to the <code>Robot</code> class to store a time. I could choose to store the start time of the sketch and then in this function check that the current time is that variable plus thirty seconds, or else I could store the end time, in which case I just need to compare the current time against the variable. This last option seems more efficient, so that’s what I’ll do.
I begin by adding the member variable:
<pre class="prettyprint">
<code> private:
 unsigned long endTime;</code>
</pre>
Then I define a constant at the top of the sketch with the total run time in seconds:
<pre class="prettyprint">
<code>#define RUN_TIME 30</code>
</pre>
In the <code>initialize()</code> method I set <code>endTime</code> to the proper value and then set the robot to<code>stateMoving</code> state:
<pre class="prettyprint">
<code> void initialize()
 {
 endTime = millis() + RUN_TIME * 1000;
 move();
 }</code>
</pre>
Now I can easily implement <code>doneRunning()</code>:
<pre class="prettyprint">
<code> bool doneRunning()
 {
 return (millis() >= endTime);
 }</code>
</pre>
But this implementation bothers me a bit. The <code>millis()</code> call does not feel right to me. I know I’m going to need to use the current time in some of the other functions I have yet to implement. For example, turning the robot will also be based on current time to some extent. One can imagine that obtaining the current time by calling the <code>millis()</code> function must have some cost, so it isn’t very efficient to call the function multiple times, knowing that all these calls will be made very close to each other and will return the same value or close. It seems more efficient to obtain the current time once and then have all the functions that need it use it.
The immediate solution one would think is to add another member variable to the <code>Robot</code> class and then at the top of the <code>run()</code> method set it to the current time, then this variable will be accessible to any method in the class.
But is that really a good solution? Think about it. Member variables are used to keep state in the object. The current time can’t be considered state, it is only valid for the execution of the <code>run()</code>method, the next time <code>run()</code> is called it will have to be obtained again.
It seems more logical to me to have the current time as a local variable inside the <code>run()</code> method, and then passed as an argument to <code>doneRunning()</code>:
<pre class="prettyprint">
<code> void run()
 {
 unsigned long currentTime = millis();

if (stopped())
 return;
 else if (doneRunning(currentTime))
 stop();
 // ...
 }</code>
</pre>
Then the <code>doneRunning()</code> method becomes:
<pre class="prettyprint">
<code> bool doneRunning(unsigned long currentTime)
 {
 return (currentTime >= endTime);
 }</code>
</pre>
And this feels a lot better.
Now I have three functions left. Let’s do <code>obstacleAhead()</code> next.
To check for obstacles I need to read the distance sensor. I could read the sensor inside the<code>obstacleAhead()</code> method, but the same reasons that made me choose to get the current time once and pass it down to functions as an argument apply to the distance sensor. So I’m going to get a single (averaged) distance reading at the top of <code>run()</code> and then pass it down to any auxiliary functions that need it:
<pre class="prettyprint">
<code> void run()
 {
 unsigned long currentTime = millis();
 int distance = distanceAverage.add(distanceSensor.getDistance());
 // ...
 }</code>
</pre>
The <code>obstacleAhead()</code> method will then take the distance reading as an argument:
<pre class="prettyprint">
<code> bool obstacleAhead(unsigned int distance)
 {
 return (distance <= TOO_CLOSE);
 }</code>
</pre>
The two auxiliary functions left to do are the most complex, because they deal with turning the robot when it comes close to an obstacle.
Here is a basic question. Should I make the robot rotate to the left or to the right?
To avoid having a robot that always moves in a predictable way I’m going to make it choose left some times and right some other times. To create this unpredictability I’m going to use the<a href="http://ift.tt/1uOjuX7" target="_blank"><code>random()</code></a> function from the Arduino library. This function takes a range of numbers as input and returns one of those numbers randomly, each time a different one. For example, <code>random(2)</code> will sometimes return 0 and sometimes 1. I can then turn left or right based on the result of the function.
Another question. For how long does the robot need to turn?
This question is harder to answer. I can easily get the robot to rotate in place by making one wheel go forward and the other go backwards, but the robot has no way to know how fast it rotates, or when it did a complete turn, this kind of feedback can only be obtained from an onboard magnetometer or compass.
Without adding more hardware the best I can do is use more random numbers. The algorithm that I will implement comes up with a random number that determines for how long the robot will rotate. Once that time passes the robot will start checking the distance sensor, while still rotating. The rotation will end only when the distance sensor finds no obstacles in the way.
Armed with the above ideas I can write <code>turn()</code> as follows:
<pre class="prettyprint">
<code> bool turn(unsigned long currentTime)
 {
 if (random(2) == 0) {
 leftMotor.setSpeed(-255);
 rightMotor.setSpeed(255);
 }
 else {
 leftMotor.setSpeed(255);
 rightMotor.setSpeed(-255);
 }
 state = stateTurning;
 endStateTime = currentTime + random(500, 1000);
 }</code>
</pre>
The first <code>if</code> statement decides to turn left or right based on the result of <code>random(2)</code>. To make the robot turn the wheels of the robot are set to run in opposite directions. And after updating the state to <code>stateTurning</code> I just need to make the robot stay in the turning state for a random amount of time. This is yet another timed action like the 30 second timeout I implemented above, so I need another member variable to keep track of when the turn is complete. I’m going to call that member variable <code>endStateTime</code>. The idea is that any robot state that needs a timed action can use this member variable to indicate the time when the action ends:
<pre class="prettyprint">
<code> private:
 unsigned long endStateTime;</code>
</pre>
The value I store in <code>endStateTime</code> is the current time plus a random value between half and a full second (recall that all the times are in millisecond units). I chose the range of the random arbitrarily, knowing that I can always fine tune these numbers if they don’t work well.
And now I have one function left to do.
I said above that a turn is over when two conditions are met. First, the time for the turn must have passed. Second, the distance sensor must not see any obstacles ahead. Based on the above description it is clear that <code>doneTurning()</code> will need two arguments, the current time and the sensor distance reading:
<pre class="prettyprint">
<code> bool doneTurning(unsigned long currentTime, unsigned int distance)
 {
 if (currentTime >= endStateTime)
 return (distance > TOO_CLOSE);
 return false;
 }</code>
</pre>
To complete the task I’m going to review my <code>run()</code> method and make sure I’m sending the proper arguments to each auxiliary function:
<pre class="prettyprint">
<code> void run()
 {
 if (stopped())
 return;

unsigned long currentTime = millis();
 int distance = distanceAverage.add(distanceSensor.getDistance());
 log("state: %d, currentTime: %ul, distance: %u\n", state, currentTime, distance);

if (doneRunning(currentTime))
 stop();
 else if (moving()) {
 if (obstacleAhead(distance))
 turn(currentTime);
 }
 else if (turning()) {
 if (doneTurning(currentTime, distance))
 move();
 }
 }</code>
</pre>
Since the <code>stopped()</code> function does not require any arguments I moved it to above the lines that set <code>currentTime</code> and <code>distance</code>.
Also note that I threw in a logging statement that prints the current state, time and distance reading. Since I have the functionality to log already in place there is no reason not to use it!
<h2>Final words</h2>
You may feel that there is something missing, that I haven’t done anything terribly complex and that with just a bunch of short and simple functions the robot will not have enough behavior built in it to move and turn.
You expected something dark and complex needed to happen somewhere because the problem is complex, but the beauty of partitioning a problem into smaller pieces is that each piece by itself isn’t as hard as the whole problem.
Of course you don’t have to take my word for it. The code is free and open source and is available on my github page. You can download it as a zip file below:
Download <a href="http://ift.tt/1VmU4Qu" target="_blank">michelino v0.2</a>.
Or if you prefer you can <a href="http://ift.tt/1S4N5p9" target="_blank">clone it directly from github</a>.
And for those that aren’t building a robot along with me, here is a short video of my robot running today’s firmware:
<iframe width="678" height="381" src="https://www.youtube.com/embed/PMR-cwbZecQ?feature=oembed" frameborder="0" allowfullscreen=""></iframe>
In the next chapter of the series I will be adding remote control support to my robot and I will be using my cell phone as the controller.
Thank you for reading these articles, I hope you will be back for the next one!
Miguel
 
<div id="huge-it-share-buttons-top" class="huge-it-share-buttons nobackground">
<h3>Share This:</h3>
<ul class="huge-it-share-buttons-list">
<li class=" nobackground"><a href="http://ift.tt/1LIxY7s" id="backforunical506" name="backforunical506" onclick="javascript:void window.open('http://ift.tt/1LIxY7s','1410949501326','width=700,height=500,toolbar=0,menubar=0,location=0,status=1,scrollbars=1,resizable=1,left=0,top=0');return false;" style="background-position: -0px -120px" target="_blank"></a></li>
<li class=" nobackground"><a href="https://twitter.com/share?status=http://yoursmart.mobi/feed&text=Building%20an%20Arduino%20Robot,%20Part%20V:%20Avoiding%20Obstacles" id="backforunical506" name="backforunical506" onclick="javascript:void window.open('https://twitter.com/share?status=http://yoursmart.mobi/feed&text=Building an Arduino Robot, Part V: Avoiding Obstacles','1410949501326','width=700,height=500,toolbar=0,menubar=0,location=0,status=1,scrollbars=1,resizable=1,left=0,top=0');return false;" style="background-position: -30px -120px" target="_blank"></a></li>
<li class=" nobackground"><a href="http://ift.tt/1Q5a5lo%20an%20Arduino%20Robot,%20Part%20V:%20Avoiding%20Obstacles" id="backforunical506" name="backforunical506" onclick="javascript:void window.open('http://ift.tt/1Q5a5lo an Arduino Robot, Part V: Avoiding Obstacles','1410949501326','width=700,height=500,toolbar=0,menubar=0,location=0,status=1,scrollbars=1,resizable=1,left=0,top=0');return false;" style="background-position: -60px -120px" target="_blank"></a></li>
<li class=" nobackground"><a href="http://ift.tt/1LIxZZ0" id="backforunical506" name="backforunical506" onclick="javascript:void window.open('http://ift.tt/1LIxZZ0','1410949501326','width=700,height=500,toolbar=0,menubar=0,location=0,status=1,scrollbars=1,resizable=1,left=0,top=0');return false;" style="background-position: -90px -120px" target="_blank"></a></li>
<li class=" nobackground"><a href="http://ift.tt/1VkrL4x%20an%20Arduino%20Robot,%20Part%20V:%20Avoiding%20Obstacles&mini=true&url=http://ift.tt/1LIxZZ4" id="backforunical506" name="backforunical506" onclick="javascript:void window.open('http://ift.tt/1VkrL4x an Arduino Robot, Part V: Avoiding Obstacles&mini=true&url=http://ift.tt/1LIxZZ4','1410949501326','width=700,height=500,toolbar=0,menubar=0,location=0,status=1,scrollbars=1,resizable=1,left=0,top=0');return false;" style="background-position: -120px -120px" target="_blank"></a></li>
<li class=" nobackground"><a href="http://ift.tt/1Q5a7dc%20an%20Arduino%20Robot,%20Part%20V:%20Avoiding%20Obstacles" id="backforunical506" name="backforunical506" onclick="javascript:void window.open('http://ift.tt/1Q5a7dc an Arduino Robot, Part V: Avoiding Obstacles','1410949501326','width=700,height=500,toolbar=0,menubar=0,location=0,status=1,scrollbars=1,resizable=1,left=0,top=0');return false;" style="background-position: -150px -120px" target="_blank"></a></li>
<li class=" nobackground"><a href="http://ift.tt/1VkrL4B%20an%20Arduino%20Robot,%20Part%20V:%20Avoiding%20Obstacles" id="backforunical506" name="backforunical506" onclick="javascript:void window.open('http://ift.tt/1VkrL4B an Arduino Robot, Part V: Avoiding Obstacles','1410949501326','width=700,height=500,toolbar=0,menubar=0,location=0,status=1,scrollbars=1,resizable=1,left=0,top=0');return false;" style="background-position: -180px -120px" target="_blank"></a></li>
<li class=" nobackground"><a href="http://ift.tt/1Q5a7dg%20an%20Arduino%20Robot,%20Part%20V:%20Avoiding%20Obstacles" id="backforunical506" name="backforunical506" onclick="javascript:void window.open('http://ift.tt/1Q5a7dg an Arduino Robot, Part V: Avoiding Obstacles','1410949501326','width=700,height=500,toolbar=0,menubar=0,location=0,status=1,scrollbars=1,resizable=1,left=0,top=0');return false;" style="background-position: -210px -120px" target="_blank"></a></li>
<li class=" nobackground"><a href="http://ift.tt/1LIxY7u" id="backforunical506" name="backforunical506" onclick="javascript:void window.open('http://ift.tt/1LIxY7u','1410949501326','width=700,height=500,toolbar=0,menubar=0,location=0,status=1,scrollbars=1,resizable=1,left=0,top=0');return false;" style="background-position: -240px -120px" target="_blank"></a></li>
<li class="none nobackground"><a href="http://ift.tt/1VkrL4D%20an%20Arduino%20Robot,%20Part%20V:%20Avoiding%20Obstacles" id="backforunical506" name="backforunical506" onclick="javascript:void window.open('http://ift.tt/1VkrL4D an Arduino Robot, Part V: Avoiding Obstacles','1410949501326','width=700,height=500,toolbar=0,menubar=0,location=0,status=1,scrollbars=1,resizable=1,left=0,top=0');return false;" style="background-position: -270px -120px" target="_blank"></a></li>
<li class="none nobackground"><a href="http://ift.tt/1Q5a7tu%20an%20Arduino%20Robot,%20Part%20V:%20Avoiding%20Obstacles" id="backforunical506" name="backforunical506" onclick="javascript:void window.open('http://ift.tt/1Q5a7tu an Arduino Robot, Part V: Avoiding Obstacles','1410949501326','width=700,height=500,toolbar=0,menubar=0,location=0,status=1,scrollbars=1,resizable=1,left=0,top=0');return false;" style="background-position: -300px -120px" target="_blank"></a></li>
<li class="none nobackground"><a href="http://ift.tt/1o7SuTq" id="backforunical506" name="backforunical506" onclick="javascript:void window.open('http://ift.tt/1o7SuTq','1410949501326','width=700,height=500,toolbar=0,menubar=0,location=0,status=1,scrollbars=1,resizable=1,left=0,top=0');return false;" style="background-position: -330px -120px" target="_blank"></a></li>
<li class="none nobackground"><a href="http://ift.tt/1VkrNJI%20an%20Arduino%20Robot,%20Part%20V:%20Avoiding%20Obstacles" id="backforunical506" name="backforunical506" onclick="javascript:void window.open('http://ift.tt/1VkrNJI an Arduino Robot, Part V: Avoiding Obstacles','1410949501326','width=700,height=500,toolbar=0,menubar=0,location=0,status=1,scrollbars=1,resizable=1,left=0,top=0');return false;" style="background-position: -360px -120px" target="_blank"></a></li>
<li class="none nobackground"><a href="http://ift.tt/1o7SuTs" id="backforunical506" name="backforunical506" onclick="javascript:void window.open('http://ift.tt/1o7SuTs','1410949501326','width=700,height=500,toolbar=0,menubar=0,location=0,status=1,scrollbars=1,resizable=1,left=0,top=0');return false;" style="background-position: -390px -120px" target="_blank"></a></li>
<li class="none nobackground"><a href="http://ift.tt/1Q5a5ls%20an%20Arduino%20Robot,%20Part%20V:%20Avoiding%20Obstacles" id="backforunical506" name="backforunical506" onclick="javascript:void window.open('http://ift.tt/1Q5a5ls an Arduino Robot, Part V: Avoiding Obstacles','1410949501326','width=700,height=500,toolbar=0,menubar=0,location=0,status=1,scrollbars=1,resizable=1,left=0,top=0');return false;" style="background-position: -420px -120px" target="_blank"></a></li>
<li class="none nobackground"><a href="http://ift.tt/1VkrLkV%20an%20Arduino%20Robot,%20Part%20V:%20Avoiding%20Obstacles&pic=&ralateUid=&" id="backforunical506" name="backforunical506" onclick="javascript:void window.open('http://ift.tt/1VkrLkV an Arduino Robot, Part V: Avoiding Obstacles&pic=&ralateUid=&','1410949501326','width=700,height=500,toolbar=0,menubar=0,location=0,status=1,scrollbars=1,resizable=1,left=0,top=0');return false;" style="background-position: -450px -120px" target="_blank"></a></li>
<li class="none nobackground"><a href="http://ift.tt/1Q5a7ty%20an%20Arduino%20Robot,%20Part%20V:%20Avoiding%20Obstacles" id="backforunical506" name="backforunical506" onclick="javascript:void window.open('http://ift.tt/1Q5a7ty an Arduino Robot, Part V: Avoiding Obstacles','1410949501326','width=700,height=500,toolbar=0,menubar=0,location=0,status=1,scrollbars=1,resizable=1,left=0,top=0');return false;" style="background-position: -480px -120px" target="_blank"></a></li>
<li class="none nobackground"><a href="http://ift.tt/1VkrNJM%20an%20Arduino%20Robot,%20Part%20V:%20Avoiding%20Obstacles" id="backforunical506" name="backforunical506" onclick="javascript:void window.open('http://ift.tt/1VkrNJM an Arduino Robot, Part V: Avoiding Obstacles','1410949501326','width=700,height=500,toolbar=0,menubar=0,location=0,status=1,scrollbars=1,resizable=1,left=0,top=0');return false;" style="background-position: -510px -120px" target="_blank"></a></li>
</ul>
<div class="clear"></div>
</div>
View more at: <a href="http://yoursmart.mobi/">http://yoursmart.mobi</a>

Building an Arduino Robot, Part V: Avoiding Obstacles

Welcome to the fifth article in the tutorial series in which I’m building a remote controlled Arduino based vehicle robot. Here is the list...

Building an Arduino Robot, Part VI: Remote Control

Building an Arduino Robot, Part V: Avoiding Obstacles

Contact Form