As you'll know if you've read the preceding articles in this series a ROV is a remotely operated vehicle and here we are going to look at two ways to introduce controlled dirigibility into your moving bots. ROVs have no autonomy in where they go, they go only where you tell them to, and so they need a method of communicating with you. The most common ones are cable, infra-red and radio controlled systems, of which the latter two are the only options for most as a tangle of cable is not only unsightly and awkward but can, due to losses or interference, lead to a corruption of data over a long run.

Consequently the latter two are the ones we shall look at here, but before we do any attaching of control systems we first have to give Goliath a brain. Here he is with my favourite microcontroller, an Arduino Uno, attached.

Robots- ROV Controlling

Go Back Philosophies Steering a Robot Driving Motors CCOG/Wheelbase Powering a Robot Introduction Battery Concerns Scrapbots Brains Practical 1 goliatharduino

Those of you who have followed other articles on this site will know that my usual breadboarding technique is in the manner of the "Aftermath of an Attack by a Squadron of B52s" school of thought and it's no different here. The Arduino is powered by the same batteries that supply the motors and fed by attaching a DC socket  to the power input jack of the Uno and then sticking the other ends of the wires into the breadboard. In this case I've done it by sticking two old component leads into the power rails of the breadboard and using some small croc clips at the other end of the wires. It's surprisingly effective. The the Uno is broken out to a motor driver IC (L293D) which controls the spin of the motors according to the output of the Uno.

Why do we need the Uno? Because we need a processor on board for the sytems to work. It doesn't have to be an Uno, it can be anything as long as it's capable of taking in pulse or TTL logic and reacting accordingly, but the Uno is a ready-built device that can do it all. You can build an Arduino clone yourself quite cheaply using some tripad board but the fact that the Uno can communicate directly with USB and thus your computer makes it for me the best option, no building just click and go which is ideal for prototyping and general messing about.


The first thing we are going to do with Goliath is to get him to move using that Arduino and L293. At this stage, he still won't be dirigible; all we're doing here is making sure the system is feasible. Here's a Fritzing diagram of the wiring:


This is the setup used to control the L293D which is the little black chip you can see nestled at the end of the breadboard there. I've shown the 9V supply as a square battery, but it isn't, it's six AA types because a square 9V (PP3) would in fact drain in next to no time. Nor have I shown the Arduino power connections; the power comes from the 9V supply that's feeding the motor. (Which in the case of this diagram case is a PP3 that isn't a PP3 but six AAs but never mind.)


Here's the pin out for the L293D chip:


Attach to positive rail (+)

Attach to positive rail (+)

Attach to positive rail (+)

Attach to positive rail (+)

Attach to pin 4

Attach to pin 13

Attach to negative rail (-)

Attach to negative rail (-)

Motor Lead 1

Motor Lead 1

Motor Lead 2

Motor Lead 2

Attach to Arduino pin  2

Attach to Arduino pin  3

Attach to Arduino pin  4

Attach to Arduino pin  5

In point of fact it' ll not matter how you attach the motor and Arduino leads (with the proviso that you attach motor to output and Arduino to input) since the Arduino is code driven and not dependent on electronic signals. The L293D is dependent on the signals though, and the above was the easiest way to my way of thinking to code up for the Arduino to drive it. You may think of an easier way.  Here is the Arduino code for testing the setup, either copy and paste or open it as a text file to save. Before you start running, make sure the platform is jacked off the ground so the treads are in the air. Unplug the USB cable and put the platform on the ground if you want to run it as a free-runner.

byte input1state =1;byte input2state =1;byte input3state =1;byte input4state =1;

byte cycle=0;

void setup(){

 for (int t=2;t<6;t++){pinMode (t,OUTPUT);}





void loop(){


 if (cycle==0){

input1state =0; input2state =1; input3state =1; input4state =1;  }

  if (cycle==1){

input1state =1; input2state =0; input3state =1; input4state =1;  }

  if (cycle==2){

input1state =1; input2state =1; input3state =0; input4state =1;  }

  if (cycle==3){

input1state =1; input2state =1; input3state =1; input4state =0;  }

  if (cycle==4){

input1state =0; input2state =1; input3state =0; input4state =1;  }

  if (cycle==5){

input1state =1; input2state =0; input3state =1; input4state =0;  }// turn

   if (cycle==6){

input1state =1; input2state =1; input3state =1; input4state =1;  }// turn

    if (cycle==8){

input1state =1; input2state =1; input3state =1; input4state =1;  }// stop

      if (cycle==7){

input1state =0; input2state =1; input3state =1; input4state =0;  }// straight

       if (cycle==6){

input1state =1; input2state =0; input3state =0; input4state =1;  }// straight





Arduino Goliath test

Alrighty, then, those of you who have trawled through any of the other pages on this site will be aware that recurring leitmotivs pop up all over the place. As well as unflattering references to Cheryl-bloody-Cole and Radio 1, a large cup of tea and a packet of fags pops up from time to time. Here they are:


Whenever you see the large cup of tea and packet of fags, it means you need to strap yourself in for another recurring leitmotiv, which is the fact that on here we bang on for umpteen paragraphs about what each bit of the code actually does in great detail. This is because I am aware that some of you who want to go to straight to robotics will not have the grounding in programming that others have, and what may seem obvious to the experienced is shrouded in murky depths of impenetrability to those who haven't.

And now a word for our American friends:

Up above I have used the phrase "packet of fags". The word  "fag" in your country does not mean the same as it does in the UK. It actually has three meanings here:

  • To be out of breath or tired during physical exercise (verb)


  • A smaller boy in a public school who does morning and  evening duty to the older boys as a manservant


  • A slang term for a cigarette.

Which is why in Seattle it is not wise for an Englishman to go in to the shop and ask for a "packet of fags."

You never know what you might get.  Arrested, most probably.


Anyway, back to the code.


The first thing is to set up some global variables. We don't actually need to here but if the sketch (which is the correct term for an Arduino program) is short as it is here it's a worthwhile practice as it saves a local variable having to be made each time. Variables are where information is temporarily stored. Variables can be changed by the run of the sketch (aha! VARIABLE values) and broadly come in two types: those that hold numerical values and those that hold text.  Let's look at what we have here:


byte input1state =1;byte input2state =1;byte input3state =1;byte input4state =1;

byte cycle=0;


There are five of them, input1state, input2state, input3state, input4state and  cycle. You'll notice that in front of all of them is the phrase byte  and at the back an equals sign and a numerical value of either 1 or 0.

Every time you set up a variable anywhere you have to give it a type. The type you give it defines its behaviours in the sketch. A byte variable will hold numbers, but only from 0 to 255, and it can't hold negative numbers or decimal fractions. There are other number-holding variables. There is an int, which will hold any value from -32,768 to 32,767, but only in integers (i.e whole numbers, no decimal parts); there is an unsigned int which can hold values between 0 to 65,535 but no negative numbers or decimal values. This is also known as a "word" and indeed you can define a word instead of an unsigned int. Next there is the long, which holds values between -2,147,483,648 to 2,147,483,647 but again no decimals, and an unsigned long which has a range of  0 to 4,294,967,295 but no negatives or decimals.

Decimals are kept in a float variable and these have huge ranges but only six digits of precision and so float maths may not be exact. It's usually best to avoid them if possible.

So now you may ask "why not just use a long all the time?" and if we had the resources available on a PC we certainly would. On a microcontroller RAM is very limited. Back in 1982 when I began programming we had computers with very little spare space (16k was not uncommon) and so we had to economise in our programming, keeping variables and code (which compete for space) as tight as possible. It's an art that's been lost to computer programmers as they now have vast acres and can spread out a bit but microcontroller programmers still have to abide by it. An Uno has 32k available and some of that is occupied by the bootloader, so a complex sketch can fill it up pretty quickly. A variable of type byte requires

eight bits. Type int requires sixteen. Longs and floats require thirty-two. So if you have a numeric that will never exceed 255, or go negative, then a byte is the ideal variable to use to save memory space. Of course you could set as a local and save more memory space. We'll get to this later, but locals pose problems that are solved with globals. In general if space permits you are better off declaring your variables as globals than you are locals. (A local variable by the way, can only be seen by the function or routine that creates it; if you don't know what that means don't worry, we're coming to that. Just remember for now that all the ones at the top of this sketch are global, which means they can be seen by the whole sketch and not just a part of it.)


The names of your variables are not important but you soon learn to make them relevant to your intentions.

The four that start with the phrase "input " are going to be used to control the pins of the Arduino which in turn control the inputs of the motor driver, and cycle is going to be used to count which cycle we are on and act accordingly.