Your Smart IOT

Welcome to the fourth 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:
<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/1Q5a6WJ" target="_blank">previous article</a> I completed the assembly of my robot vehicle. Today, I’m going to write an Arduino sketch for it that makes the robot go forward.
“Just to move the robot forward?”, you may ask. What’s so interesting about simply making the robot run forward?
Well, the idea is to not only make the robot move forward, but to write the sketch in such a way that allows me to later add more complex functionality without having to start over from scratch. I’m basically laying out a solid foundation on which I will stack the more complex pieces later.
Once again I want to say that it is not my intention to do a full and detailed coverage of the C++ programming language in these articles. I will share my experience and provide a few pointers, but I recommend you read up on C++ on your own if you have no experience with the language.
<h2>Goals</h2>
I mentioned what functionality I want my robot to have in past articles, but I did not discuss the goals I have for my project from a software engineering point of view.
<h3>Scalable Structure</h3>
For simple sketches the default sketch structure based on the <code>setup()</code> and <code>loop()</code> functions is sufficient. The sketches I wrote a couple of articles ago to test all the components of my robot fit in this category, I needed to test and learn to program these components and was able to accomplish both goals quickly and with very low effort.
The problem is that this structure does not <a href="http://ift.tt/W0fFQI" target="_blank">scale</a> well. For my robot project I will need to control two motors, the distance sensor and react to remote commands coming over bluetooth all at the same time. In the future I may want to extend it with even more controlled devices. Maybe additional distance sensors on the sides and back, or one looking down to detect when the vehicle reaches the end of a table. I may want to mount a wireless camera, or add sound capabilities. The possibilities are endless, and each new device added will increase the complexity of the sketch.
The <code>loop()</code> function would need to get pretty long and complex to do everything, and then making changes to it would become a nightmare, with any changes I make I could risk inadvertently breaking existing functionality. The sketch would end up being <a href="http://ift.tt/Omlkfx" target="_blank">spaghetti code</a>.
For this project I will use <a href="http://ift.tt/rwZ67d" target="_blank">object oriented</a> techniques to organize the code of my sketch and make it easier to write, test, maintain and modify.
<h3>Device Abstractions</h3>
I mentioned before that I will be releasing my sketch as open source. It is safe to assume that other people will build their own robot vehicles using different parts than those I put in mine. For example, someone may use a different motor driver board, or may want to use wi-fi for the remote control instead of bluetooth. If I build my sketch with the assumption that the components of the robot are just those that I’m using on mine then only a small few would be able to benefit right away and most will have to hack on it to make it work for them.
So instead, I will think about the functionality I want to implement in general terms, and then will write <a href="http://ift.tt/Lp3PuD" target="_blank">device drivers</a> for the modules that I need.
This will give me or others the freedom to replace parts in the robot without having to modify the main sketch. Switching from bluetooth to wi-fi will then just require writing a new remote communications driver. The main sketch will talk to either the bluetooth or wi-fi drivers and will not know the difference!
<h3>Configuration</h3>
I spoke about configuration before. The idea here is that it should be easy to configure the robot software for the actual hardware. The best example is the use of pins in the <a href="http://ift.tt/1q9AJo0" itemprop="url" target="_bank" title="Arduino board">Arduino board</a>. I will not <a href="http://ift.tt/1kvNBj6" target="_blank">hard code</a> any pin numbers. Instead, I will add <code>#define</code> constants at the top of the sketch with all the pins, so that changing the pin assignments becomes a trivial task.
But configuration is not limited to pin numbers. There are also some operational defaults (like the distance to a wall or obstacle when the robot stops and turns) that can also be considered part of the configuration and will be represented by constants at the top of the sketch for users to easily modify.
<h3>Smarter Timing</h3>
In simple sketches one tends to overuse the <code>delay()</code> function as an easy way to make actions last a certain amount of time. I’m guilty of this myself, as I’ve used <code>delay()</code> in all my test sketches.
But for a real project that needs to do many things at once this is impractical. For example, what happens if the robot approaches a wall while in the middle of a <code>delay()</code> call? I can tell you what happens, nothing happens! The robot will crash into the wall without having a chance to “see” the wall and act accordingly.
Unfortunately the Arduino board does not support multithreading, which is the ideal way to make a program do many things at once. In a multithreaded environment a thread calling <code>delay()</code> would not prevent other threads from running. But on the Arduino platform there is a single thread of execution, so calling <code>delay()</code> makes the entire program go to sleep, and that is not good for my needs.
So I will not be using <code>delay()</code> for anything except throw away tests. But how can I keep track of time without <code>delay()</code>?
Part of the secret is in making the <code>loop()</code> function do only a small amount of work and return. The <code>loop()</code> function will then get called at a really fast rate (remember that it gets called repeatedly until the board is powered off). Each time <code>loop()</code> is called I can find out what’s the <a href="http://ift.tt/1fHNT0B" target="_blank">up time</a>. Knowing the current time will enable me to implement my own non-blocking <code>delay()</code>equivalent, as you will see soon.
<h2>Enough talk… let’s write a device driver!</h2>
I said earlier that today I’m making the robot move forward, so I’m going to start by writing a device driver that knows how to control motors.
A device driver is simply an abstraction for the intended device. I’m now writing one for a motor, so the basic operation that this driver should know how to do is to set the speed of the motor.
I will store my device drivers in header files, which are files that have a <code>.h</code> extension. For small modules using a header file is a good choice. For larger modules the norm is to store the code in a source file with extension .cpp and then write a small header file that only contains the declaration of the public functions from the source file. Header files work for me at this time, if in the future a module grows to a decent size I can always move the code to a .cpp file.
The intention is that the motor device driver will allow the main sketch to work with different motor controllers using the same function calls, so the first task when defining a driver is to decide what the common functions of the driver will be.
Here is the code for my motor device driver, which I will store in a file called <code>motor_driver.h</code>:
<pre class="prettyprint">
<code>/**
 * @file motor_driver.h
 * @brief Motor device driver definition for the Michelino robot.
 * @author Miguel Grinberg
 */

namespace Michelino
{
 class MotorDriver
 {
 public:
 /**
 * @brief Change the speed of the motor.
 * @param speed The new speed of the motor.
 * Valid values are between -255 and 255. 
 * Use positive values to run the motor forward, 
 * negative values to run it backward and zero to stop the motor.
 */
 virtual void setSpeed(int speed) = 0;

/**
 * @brief Return the current speed of the motor.
 * @return The current speed of the motor with range -255 to 255.
 */
 virtual int getSpeed() const = 0; 
 };
};</code>
</pre>
If you are unfamiliar with C++ then there are a number of things here that need an explanation.
Any text that appears between <code>/*</code> and <code>*/</code> is considered a comment, so it will be ignored by the C++ compiler. There is an alternative format for comments that you may have seen, those use a<code>//</code> prefix and go through the end of the line. Both formats are valid, but in this case since I’m writing multi-line comments I’m using the <code>/* ... */</code> format.
The comments that I’m writing follow a standard comment format that can be used to produce automatic documentation with a tool called <a href="http://ift.tt/PbHtvf" target="_blank">doxygen</a>. It is always good practice to write class documentation in this format for any classes that others may need to use. This class defines the format for motor drivers, so those who want to implement other motor drivers will find the documentation useful.
I have inserted a comment block at the top to describe the contents of the file, and then one before each function to describe the function. Each comment line is prefixed with a keyword, for example <code>@file</code> for the name of the file, <code>@brief</code> for a brief description, <code>@param</code> for documenting a function parameter and <code>@return</code> for documenting the return value of a function.
The <a href="http://ift.tt/20zwuiy" target="_blank"><code>namespace</code></a> keyword groups all the definitions inside the <code>{</code> and <code>}</code> under a user defined name. This is helpful to avoid name collisions with other modules, so it is always a good idea to enclose your own code in a namespace. I will put all my code under the <code>Michelino</code> namespace.
The <a href="http://ift.tt/1coRilv" target="_blank"><code>class</code></a> keyword defines a structure that groups data and functions together into an entity called object. My motor driver class is called <code>MotorDriver</code> and just contains two functions, which in the context of a class are called methods. The <code>setSpeed</code> and <code>getSpeed</code> methods will control a motor, but note that unlike the <code>AF_Motor</code> library that I used before here I’m not defining what kind of motor controller is used for the task. The main sketch will just call these methods without knowing how they are implemented, so to switch from one controller to another one just needs to re-implement these two functions for the selected controller.
The <code>public:</code> keyword that appears before the methods indicates that the declarations that follow are accessible to anyone. You will see later that some classes have contents that are hidden from the outside world.
The <code>virtual</code> keyword that starts each method declaration indicates that these methods may beoverwritten by a subclass, and the <code>= 0</code> at the end of the declarations indicates that the methods do not have an implementation. These two attributes combined are used to make sure that the only way to provide an implementation for these methods is in a subclass. I will show what this means in a moment.
Finally, the <code>const</code> keyword that appears in the <code>getSpeed</code> method indicates that this method isconstant, meaning that this method does not change the internal state of the object.
Setting the technical details of writing a C++ class aside, the important point is that device drivers that adopt the above interface should be able to control a DC motor with two operations,<code>setSpeed()</code> and <code>getSpeed()</code>. The speed values are given in the -255 to 255 range, with positive speeds moving forward, negative speeds moving backward and zero making the motor stop.
<h2>The Adafruit motor shield device driver</h2>
Now I have a very clear idea of what motor drivers for my robot need to do, so I’m ready to write a specific implementation for my Adafruit motor shield.
I will store the Adafruit motor shield driver in a file called <code>adafruit_motor_driver.h</code>. Here is the code:
<pre class="prettyprint">
<code>/**
 * @file adafruit_motor_driver.h
 * @brief Motor device driver for the Adafruit motor shield.
 * @author Miguel Grinberg
 */

#include "motor_driver.h"

namespace Michelino
{
 class Motor : public MotorDriver
 {
 public:
 /*
 * @brief Class constructor.
 * @param number the DC motor number to control, from 1 to 4.
 */
 Motor(int number)
 : MotorDriver(), motor(number), currentSpeed(0)
 {
 }

void setSpeed(int speed)
 {
 currentSpeed = speed;
 if (speed >= 0) {
 motor.setSpeed(speed);
 motor.run(FORWARD);
 }
 else {
 motor.setSpeed(-speed);
 motor.run(BACKWARD);
 }
 }

int getSpeed() const
 {
 return currentSpeed;
 }

private:
 AF_DCMotor motor;
 int currentSpeed;
 };
};</code>
</pre>
So what’s new here? I start by including the motor driver header file. The Adafruit driver derivesfrom the generic driver definition I wrote above so that definition needs to be accessible.
The <code>class</code> definition in this file looks a bit different:
<pre class="prettyprint">
<code>class Motor : public MotorDriver</code>
</pre>
This says that I’m creating a class called <code>Motor</code> that derives from class <code>MotorDriver</code>. This means that class <code>Motor</code> will follow the protocol established by class <code>MotorDriver</code>.
The class has a <code>public</code> section that starts with a <code>constructor</code>:
<pre class="prettyprint">
<code>Motor(int number)</code>
</pre>
This is a method with the same name as the class (<code>Motor</code> in this case). Constructor methods are called when an object is created and are intended to set the initial state of the object. This constructor takes the motor number as an argument.
The <code>Motor</code> constructor has an initializer list:
<pre class="prettyprint">
<code>: MotorDriver(), motor(number), currentSpeed(0)</code>
</pre>
This is a list of items that will be initialized when an object of this class is created. The first item just invokes the constructor of the parent class, the generic driver <code>MotorDriver</code>. I did not include a constructor in this class, but the compiler will generate an empty one for me. It is good practice to always initialize the parent class even when there isn’t a constructor there, because in the future a constructor might be added.
The two remaining items in the initializer list are member variables of this class. If you look at the bottom of the class there is a <code>private</code> block that defines two variables named <code>motor</code> and<code>currentSpeed</code>. The <code>motor</code> variable is of type <code>AF_DCMotor</code>, the class defined by the Adafruit motor shield library. To initialize this variable I have to invoke its constructor, which if you recall from a previous article takes the motor number as argument. I received the motor number as an argument to my own constructor, so I just pass it on here. The <code>currentSpeed</code> variable is of type<code>int</code>, so I just initialize it to 0 so that it has a known starting value.
The body of the <code>Motor</code> constructor is empty, since the only thing I need is to initialize the member variables.
What follows is the implementation of the <code>setSpeed</code> and <code>getSpeed</code> methods for this specific motor controller, using the open source AF_Motor library from Adafruit, which must be installed separately (see my <a href="http://ift.tt/1VkrI8N" target="_blank">previous article</a> for instructions). This library requires two functions to be called to configure a motor, one to set the speed and another one to set the mode. I have defined my motor driver to use a simpler way to configure the motor, with just a speed that can be positive, negative or zero. The implementation of <code>setSpeed</code> translates my format to the one required by the Adafruit motor shield library. I also store the current speed in a member variable, so that I can then return it in <code>getSpeed</code>.
At the bottom there are the two private member variables that this class uses. These variables are declared as private because I do not want them to be accessible from outside the object that owns them. I want any changes the motor or its speed to be accomplished via the public functions of the driver (following the <a href="http://ift.tt/X0krKi" target="_blank">encapsulation</a> principle), so a good way to prevent me from accidentally using the member variables directly is to make them private. A private member variable can only be modified from methods that belong to the object, but it is not accessible from any other place in the code. A good reason to hide these member variables is that other motor drivers will need different ones, so as long as the code outside of this class only calls <code>setSpeed()</code> and <code>getSpeed()</code>swapping out this driver for another one should not be a problem.
If you are using a different motor controller than mine on your robot, then all you need to do is copy the <code>adafruit_motor_driver.h</code> file to <code><your_controller>_motor_driver.h</code> and implement the class as appropriate for your controller. The only requirement is that the new class is also called <code>Motor</code> and has the same two public functions. The two classes will then be conceptually equivalent, so the main sketch can use either one of them.
<h2>Using the device driver</h2>
Now I have a completed device driver for my Adafruit motor shield. But how do I use it on a sketch?
This is actually simpler than you may think. Here is an example sketch that starts a motor at full speed using the Adafruit driver that I just built:
<pre class="prettyprint">
<code>#include <AFMotor.h>
#include "adafruit_motor_driver.h"
#define MOTOR_INIT 1

Michelino::Motor motor(MOTOR_INIT);

void setup()
{
 motor.setSpeed(255);
}

void loop()
{
}</code>
</pre>
The <code>#includes</code> at the top bring in the Adafruit motor library and my driver for it.
Note how the motor object is created:
<pre class="prettyprint">
<code>Michelino::Motor motor(MOTOR_INIT);</code>
</pre>
The notation <code>Michelino::Motor</code> tells the compiler to locate the <code>Motor</code> class inside the <code>Michelino</code>namespace.
Once the motor object is created it can be controlled using the driver functions <code>setSpeed</code> and<code>getSpeed</code>.
Now let’s assume that later you want to make the above sketch work with another motor shield, say one that is called “x”, for which you have written a device driver. Then you can just add a few lines of code to the sketch, as follows:
<pre class="prettyprint">
<code>// enable one of the motor shields below
//#define ENABLE_ADAFRUIT_MOTOR_DRIVER
#define ENABLE_X_MOTOR_DRIVER

#ifdef ENABLE_ADAFRUIT_MOTOR_DRIVER
#include <AFMotor.h>
#include "adafruit_motor_driver.h"
#define MOTOR_INIT 1
#endif

#ifdef ENABLE_X_MOTOR_DRIVER
#include <XMotor.h>
#include "x_motor_driver.h"
#define MOTOR_INIT 2
#endif

void loop()
{
}</code>
</pre>
At the top I’m defining two <code>#define</code> constants, but one of the is commented out. This is a pretty easy way to provide configuration, you just uncomment the one constant that corresponds to the part that you have.
An <code>#ifdef ... #endif</code> block will only be seen by the compiler if the constant that follows the<code>#ifdef</code> is defined. Since only one of the motor shield constants will be defined I’m effectively loading only one of the device drivers into the sketch.
In the example above the sketch can be switched between the Adafruit shield using motor #1 and the X motor shield using motor #2 just by changing which of the <code>#define</code> statements at the top is used!
<h2>The main sketch</h2>
Now that I have a really good solution for controlling my hardware parts I need to think about how the main sketch will be structured.
As I mentioned before, having a large piece of code in the <code>loop()</code> function is not ideal because large and complex functions difficult to maintain. If I created a class to represent a motor, then why not also create a class to represent the whole robot?
Here is a sketch that defines a starting point class for the robot. This file will be named<code>michelino.ino</code> (Arduino sketches use the <code>.ino</code> extension):
<pre class="prettyprint">
<code>/**
 * @file michelino.ino
 * @brief Arduino robot vehicle firmware.
 * @author Miguel Grinberg
 */

#define ENABLE_ADAFRUIT_MOTOR_DRIVER

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

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

/*
 * @brief Initialize the robot state.
 */
 void initialize()
 {
 leftMotor.setSpeed(255);
 rightMotor.setSpeed(255);
 }

/*
 * @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()
 {
 }

private:
 Motor leftMotor;
 Motor rightMotor;
 };
};

Michelino::Robot robot;

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

void loop()
{
 robot.run();
}</code>
</pre>
The sketch should not present any surprises. I begin by loading my motor shield driver, using the<code>#ifdef</code> technique I showed before. When and if I write new motor drivers I will add new constants and <code>#ifdef</code> blocks to load them.
My robot class will be appropriately named <code>Robot</code> and will be inside the <code>Michelino</code> namespace. It will initially have two private data members that represent the two motors named <code>leftMotor</code> and<code>rightMotor</code>. These will be initialized in the <code>Robot</code> class constructor’s initializer list. The class has two public methods, <code>initialize()</code> and <code>run()</code> that will be the class counterparts to <code>setup()</code> and<code>loop()</code>. In this early version of the class the <code>initialize()</code> method starts the two motors at full speed forward, and <code>run()</code> does nothing.
After the class is defined an instance is created in the global scope, and the <code>setup()</code> and <code>loop()</code>methods simply call the <code>initialize()</code> and <code>run()</code> methods of this object.
What do you think will happen when you run this sketch? The robot will move forward! I took a few turns and twists, but I finally delivered on my promise.
<h2>How to implement delays</h2>
Before I end this article I’m going to show you how delays can be implemented without actually using the <code>delay()</code> function, so that the robot can do other things while it waits, like receiving and executing remote commands.
To show you how this is done, I’m going to modify the above sketch to make the robot start by waiting for five seconds, then moving forward for eight seconds, then repeating the cycle.
First, I’m going to add the concept of state to the robot. For this example I will have two possible states, stopped and running. To define these states in the sketch I’m going to use a C++<a href="http://ift.tt/1VmU3vP" target="_blank">enumeration</a>:
<pre class="prettyprint">
<code>private:
 enum state_t { stateStopped, stateRunning };
 state_t state;</code>
</pre>
The <code>enum</code> statement creates a user defined enumerated type named <code>state_t</code>. The second statements defines a new member variable named <code>state</code> of that type. The <code>state</code> member variable wil have one of two possible values, <code>stateStopped</code> or <code>stateRunning</code>. I could have easily used an <code>int</code> variable and call state 0 the stopped state and state 1 the running state, but after you see me using this variable I’m sure you will agree with me that using enumerated types makes the code a lot more readable and easier to understand.
I’m going to add yet another member variable to the <code>Robot</code> class that will help me count time:
<pre class="prettyprint">
<code>private:
 unsigned long startTime;</code>
</pre>
The type of the <code>startTime</code> variable is <code>unsigned long</code>. This is the type in which time units are returned by the function <a href="http://ift.tt/1sekCGp" target="_blank"><code>millis()</code></a> provided by the Arduino software libraries.
Next, in the <code>initialize()</code> method instead of starting the motors I’m now going to initialize the robot state and record the current time:
<pre class="prettyprint">
<code> void initialize()
 {
 state = stateStopped;
 startTime = millis();
 }</code>
</pre>
And finally, in the <code>run()</code> method is where all the magic happens:
<pre class="prettyprint">
<code> void run()
 {
 unsigned long currentTime = millis();
 unsigned long elapsedTime = currentTime - startTime;
 switch (state) {
 case stateStopped:
 if (elapsedTime >= 5000) {
 leftMotor.setSpeed(255);
 rightMotor.setSpeed(255);
 state = stateRunning;
 startTime = currentTime;
 }
 break;
 case stateRunning:
 if (elapsedTime >= 8000) {
 leftMotor.setSpeed(0);
 rightMotor.setSpeed(0);
 state = stateStopped;
 startTime = currentTime;
 }
 break;
 }
 }</code>
</pre>
The <code>run()</code> method is repeatedly called through the <code>loop()</code> function, so here I can easily check how much time has passed by substracting the <code>startTime</code> that I initialized in <code>initialize()</code> from the current time provided by the <code>millis()</code> function. I’m storing both the current and elapsed time in two local variables that I named <code>currentTime</code> and <code>elapsedTime</code>.
What’s left is to check if I’m done waiting, and if I am, then change the state of the robot. Since the wait period is different depending on which state the robot is in, I’ve decided to use a <a href="http://ift.tt/1VmU4A6" target="_blank"><code>switch</code></a>statement, which looks at the value of an expression and then executes the block of code that begins at the matching <code>case</code> statement and ends with the <code>break</code> statement.
So, when the robot is in the stopped state the following code will execute:
<pre class="prettyprint">
<code> if (elapsedTime >= 5000) {
 leftMotor.setSpeed(255);
 rightMotor.setSpeed(255);
 state = stateRunning;
 startTime = currentTime;
 }</code>
</pre>
This code is hopefully self-explanatory. If the elapsed time did not reach five seconds then nothing will happen, the <code>run()</code> function will return without making any changes, and a little bit later will be called again. Eventually, the <code>elapsedTime</code> will become 5000 milliseconds or more, so the code inside the <code>if</code> statement will execute. And those statements start the motors, change the state to<code>stateRunning</code> and reset the <code>startTime</code> to the <code>currentTime</code>, so that elapsed time is reset to zero.
The next time <code>run()</code> executes the state will be <code>stateRunning</code>, so the other block in the <code>switch</code>statement will execute:
<pre class="prettyprint">
<code> if (elapsedTime >= 8000) {
 leftMotor.setSpeed(0);
 rightMotor.setSpeed(0);
 state = stateStopped;
 startTime = currentTime;
 }</code>
</pre>
And this works exactly like above but waits eight seconds instead of five.
Doing things in this certainly more complicated than using <code>delay()</code>:
<pre class="prettyprint">
<code> void run()
 {
 leftMotor.setSpeed(0);
 rightMotor.setSpeed(0);
 delay(5000);
 leftMotor.setSpeed(255);
 rightMotor.setSpeed(255);
 delay(8000);
 }</code>
</pre>
But the <code>delay()</code> solution pictured above is limited in that nothing happens during those five and eight second waits. With the elapsed time solution it will be easy for me to make the robot do other things while waiting, like stopping when it gets too close to a wall or responding to remote commands sends over bluetooth.
<h2>Final words</h2>
To close this article, here is a video that shows my robot running the above <code>michelino</code> sketch:
<iframe width="678" height="381" src="https://www.youtube.com/embed/kPUN-GPCXJ4?feature=oembed" frameborder="0" allowfullscreen=""></iframe>
<center>In the next article I will incorporate the distance sensor into the firmware to prevent the robot from running into walls or other obstacles.</center>
As always, you are welcome to send me your questions in the comments below. If you wish to download or review my sketch I have uploaded it to github as version 0.1 (<a href="http://ift.tt/1S4N3NQ" target="_blank">download</a> or <a href="http://ift.tt/1VmU4Qk" target="_blank">browse</a>).
I hope to see you in the next article!
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="backforunical503" name="backforunical503" 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%20IV:%20A%20(Not%20So)%20Basic%20Robot%20Firmware" id="backforunical503" name="backforunical503" onclick="javascript:void window.open('https://twitter.com/share?status=http://yoursmart.mobi/feed&text=Building an Arduino Robot, Part IV: A (Not So) Basic Robot Firmware','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%20IV:%20A%20(Not%20So)%20Basic%20Robot%20Firmware" id="backforunical503" name="backforunical503" onclick="javascript:void window.open('http://ift.tt/1Q5a5lo an Arduino Robot, Part IV: A (Not So) Basic Robot Firmware','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="backforunical503" name="backforunical503" 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%20IV:%20A%20(Not%20So)%20Basic%20Robot%20Firmware&mini=true&url=http://ift.tt/1LIxZZ4" id="backforunical503" name="backforunical503" onclick="javascript:void window.open('http://ift.tt/1VkrL4x an Arduino Robot, Part IV: A (Not So) Basic Robot Firmware&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%20IV:%20A%20(Not%20So)%20Basic%20Robot%20Firmware" id="backforunical503" name="backforunical503" onclick="javascript:void window.open('http://ift.tt/1Q5a7dc an Arduino Robot, Part IV: A (Not So) Basic Robot Firmware','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%20IV:%20A%20(Not%20So)%20Basic%20Robot%20Firmware" id="backforunical503" name="backforunical503" onclick="javascript:void window.open('http://ift.tt/1VkrL4B an Arduino Robot, Part IV: A (Not So) Basic Robot Firmware','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%20IV:%20A%20(Not%20So)%20Basic%20Robot%20Firmware" id="backforunical503" name="backforunical503" onclick="javascript:void window.open('http://ift.tt/1Q5a7dg an Arduino Robot, Part IV: A (Not So) Basic Robot Firmware','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="backforunical503" name="backforunical503" 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%20IV:%20A%20(Not%20So)%20Basic%20Robot%20Firmware" id="backforunical503" name="backforunical503" onclick="javascript:void window.open('http://ift.tt/1VkrL4D an Arduino Robot, Part IV: A (Not So) Basic Robot Firmware','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%20IV:%20A%20(Not%20So)%20Basic%20Robot%20Firmware" id="backforunical503" name="backforunical503" onclick="javascript:void window.open('http://ift.tt/1Q5a7tu an Arduino Robot, Part IV: A (Not So) Basic Robot Firmware','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="backforunical503" name="backforunical503" 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%20IV:%20A%20(Not%20So)%20Basic%20Robot%20Firmware" id="backforunical503" name="backforunical503" onclick="javascript:void window.open('http://ift.tt/1VkrNJI an Arduino Robot, Part IV: A (Not So) Basic Robot Firmware','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="backforunical503" name="backforunical503" 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%20IV:%20A%20(Not%20So)%20Basic%20Robot%20Firmware" id="backforunical503" name="backforunical503" onclick="javascript:void window.open('http://ift.tt/1Q5a5ls an Arduino Robot, Part IV: A (Not So) Basic Robot Firmware','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%20IV:%20A%20(Not%20So)%20Basic%20Robot%20Firmware&pic=&ralateUid=&" id="backforunical503" name="backforunical503" onclick="javascript:void window.open('http://ift.tt/1VkrLkV an Arduino Robot, Part IV: A (Not So) Basic Robot Firmware&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%20IV:%20A%20(Not%20So)%20Basic%20Robot%20Firmware" id="backforunical503" name="backforunical503" onclick="javascript:void window.open('http://ift.tt/1Q5a7ty an Arduino Robot, Part IV: A (Not So) Basic Robot Firmware','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%20IV:%20A%20(Not%20So)%20Basic%20Robot%20Firmware" id="backforunical503" name="backforunical503" onclick="javascript:void window.open('http://ift.tt/1VkrNJM an Arduino Robot, Part IV: A (Not So) Basic Robot Firmware','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 IV: A (Not So) Basic Robot Firmware

Welcome to the fourth 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 IV: A (Not So) Basic Robot Firmware

Contact Form