Basic Robotics


As a general rule, a robotics system consists of three parts: Sensing, Planning, and Acting. If you're missing one of those parts, it's technically not a robot, but for many people, that doesn't really matter. Even if it's only a subset of being a whole robot, you need to know whatever's in the silos of knowledge for those parts. 

Sensing. To sense, you need sensors. Sensors come in all kinds, but you'll have things like light meters or optical sensors to sense light, galvanic skin sensors to sense how conductive your skin is, sonar to sense how far something not that far away is, and so on.

Planning. To plan, you generally need something Turing complete like a microcontroller or computer. The planner takes the input, figures out what it means, decides what to do, and tells the actuators to do that thing.

Acting. To act, you need actuators. These are motors, servos, linear actuators, and so on. Most of them are variations of the same thing (i.e. a motor), though some are radically different, such as wire that changes from one shape to another depending on if electricity is running across is.

Your basic rolling robot, like a Roomba, will do something like this: Am I hitting something? If no, go forward. If so, back up, then go forward.

Sense - Am I hitting something? 
Plan - If not, 
Act - go forward. 
Plan - If so, 
Act - back up, turn, then go forward. 

Everything else is, essentially, a more or less complicated version of that. There are dishwashers now that have enough smarts to be robots.

The hard part with robotics is selecting and acquiring parts. If you have lots of time and money, then it's easy. The faster/cheaper you need something, the harder it becomes. Getting something in town becomes even more difficult. You'll rarely find exactly what you need (well, until you're months past when you need it, in which case someone will just start carrying it), so understanding what kinds of flexibility you have in your design will be key. Also, I'm a firm believer in iterating prototypes, so you start out with one thing, see how it succeeds and how it fails, and then make a couple more versions until you are quite happy with it.

Finally, you have different challenges with doing one-offs or short runs versus medium- to large-scale production. Some parts available for one stage of creation will be completely unavailable for other stages (one way or another).


Sensing the world around you, or even the world that is you, is in some ways easy and other ways complicated. I'll probably start every part of this series with a variation of that sentence, now that I think of it. Still, for sensors that means that you have a few standard ways of interfacing with them, but interpreting that data becomes complicated. 

Analog sensors. Some sensors have an analog interface. These generally have three pins: supply voltage, ground, and output. You have to check the data sheet for what kind of supply voltage you give it, but let's pretend like everything you use will be a 5V device. A simple example of a sensor like this is a potentiometer, which is a resistor that changes the amount of resistance it gives based on how far you turn/push it. These are what are commonly used for turn dials, slider controls, and so on. If you feed that 5V, at one end of the dial, your output will be 5V. At the other end, it will be much lower (maybe 0V, maybe 1V, or something of the sort). 

Advantages of analog controls are the variability you get with their output. Disadvantages are that reading analog input is one of the harder things for your planning devices to use, because they have to convert those signals to digital before you read them. Also, the resolution of the device reading the input will limit the infinite potential of the device to something that is maybe 10, 12, or 16 bits (meaning you have, between 0V and 5V, no more than 2^10 values, 2^12 values, or 2^16 values, respectively). 

Devices like photocells, photoresistors, varistors, potentiometers, and various distance sensors like sonar will give you analog outputs. The galvanic skin response, because it's measuring conductivity, is also likely going to be an analog sensor.

Digital sensors. Other sensor have digital outputs. These will come in the form of either a single bit of information, such as a simple switch being on or off (a.k.a high or low), or information over time, such as a frequency or Pulse Width Modulation (PWM; see below). There's a third class of digital signal, but we'll get to that in a bit, because it's complicated enough to be it's own. 

Your single bit, simple digital sensor is the easiest thing to implement. You can make them either control power to your whole project, which is easy but means you'll likely have some startup time whenever you activate, or you can wire them into digital inputs on your sensing device, which are cheap and plentiful and usually only limited by space on the device (to a point). 

Pull-up and Pull-down Resistors. The hardest thing to deal with on simple digital signals is that you frequently have to add a resistor into the mix. They are called pull-up resistors and pull-down resistors, depending on how they're used. Although you would think that digital sensors might have two states, on or off, that's not exactly true. There's kind of a third state: floating. 

Floating input is when you haven't properly grounded your sensor, so it picks up on whatever current is floating around your circuit. If your current is grounded, then all of the excess current is going into the ground, and none of it goes into your sensor. If you apply a proper current, then the current flows through your sensor and raises it to its on state.

You fix this by adding in a resistor of the pull-up or pull-down variety. For more on this, check out this handy pull-up / pull-down resistor tutorial

You don't really need this until you start implementing things, but it will be very important when you do. These resistors are also useful for analog sensors. 

Frequency and PWM are two different ways of achieving similar goals. Instead of sending you a continuous 2.5V signal out of your potential 5V maximum as the analog signals do, these will send you, for example, 5V only 50% of the time. Frequency signals divvies the up and down more or less symmetrically, though there are different shapes to different types of waves (square waves go from 0 to 5V immediately, hold on 5V for a period of time, then drop immediately back to 0. Looks very rectangular if you plot it out. There can be saw-tooth waves, sine waves, and similar, but they're always symmetrical).

PWM is a different beast. Very few sensors output PWM unless it's for a specific type of application. But the way PWM widens the high signal rather than keeping things symmetrical. 

Generally, your sensors will output a straight frequency if anything, and you will need to use a pulse-counter module to take advantage of that. If it's a slow enough signal, or you want to get fancy with your programming, you can make your microcontroller count for you, but that does get to complicating the programming significantly. Some microcontrollers are better at that than others.

Speed sensors are a common frequency-type digital sensor. One of the more common is a bicycle speed sensor, which has one or more magnets on the wheel and a sensor just off the wheel. Every time a magnet passes by the sensor, you get a pulse. The faster you go, the more pulses you get. A little math will let you convert the number of pulses per second into miles per hour. Or kilometers per hour. Or furlongs per fortnight. Whatever it is you want to know for speed.

Other digital sensors. The other type of digital sensors are the kind you are, in some ways, more familiar with: they just send out their data over a common communication protocol. You'll have things like Serial (RS-232, RS-422, RS-485, or TTL), ethernet, WiFi, and so on. You need to have support on your device for these, and some of them require specialized hardware and software to deal with. TTL and 232 are pretty easy, but ethernet, WiFi, Bluetooth, and USB get progressively more complicated. Maybe WiFi and Bluetooth should be switched. There are also several simple protocols meant to be easy for things like micrcontrollers and using many, many sensors, such as I2C and SPI. The great thing about those is that they are lightweight. The bad thing is that implementation is often inconsistent, so you have to find out how each device implements it. 


Planners are relatively straightforward, because you have used computers for a while and they are essentially, or actually, computers. Your two main divisions are: computers and microcontrollers.

Computers. The thing with the CPU and the keyboard and the screen and stuff. Although generally, once it's in the robot, you won't bother with the keyboard and the screen and most of the stuff. Runs programs. With most computers, you will have a lot of processing power, but you'll likely have to add something (USB accessory, PCI Card, or whatever) to get your digital and analog ins and outs, but things like WiFi, Ethernet, and USB will be easier to deal with. Most of the complexities of programming a robot with a computer comes from the interface with your sensors. On the plus side, you usually have the option of a full IDE with cool things like a debugger.

There are several frameworks for programming robotics on a computer, from the simple Processing Java framework (usually paired with an Arduino, see below) to offerings from Microsoft, NASA, and others. I'm most familiar with MAX from Perrone Robotics, because that's my day job, but it's not widely available right now, and is currently best for going from prototype to scale, autonomous vehicles, or certain kinds of sensor projects.

For a project with low processor needs but a desire to use a proper computer, the most exciting thing around right now is the Raspberry Pi. It's very inexpensive ($35, give or take), has a bunch of I/O, has a huge community, and runs Linux. I have one, but haven't used it yet. One of the nice things about these is that you can power them relatively easily; some computers require AC power unless you are going to do some hardware hacking.

Microcontrollers. The big difference between a computer and a microcontroller is that a computer has an OS and a microcontroller doesn't. This means that everything you do on a microcontroller you have to implement yourself. On the one hand, this is great, because that means that your stuff is more likely to be Real Time, meaning that you will have a predictable amount of execution time between the sensing and the acting. On the other hand, that means you have to do a lot more programming to make something happen. Microcontrollers are generally slower than full-sized PCs, consume far less power, and tend to have a decent amount of digital and/or analog I/O on board. They also generally don't have Ethernet, WiFi, Bluetooth, or whatever on board without some sort of bridge. Serial, either TTL or RS-232, is often included one way or another. Microcontrollers also boot pretty close to instantly, but computers rarely do without a lot of work.

One of the best things about a microcontroller is that you have really quick access to the digital and analog I/O. Like, really, really quick access. A few lines of code will get you something that can blink an LED when you press a button, and a few more lines of code will let you control how quickly it blinks when you turn an analog potentiometer. 

If you're starting for the first time, I highly recommend the Arduino breed of microcontrollers. Available in a range of sizes, capabilities, and prices. Lots of people use them. They are dead-simple to get started with. They are Open Hardware, so they won't be going away even if the Arduino organization goes under. I own about 30 of these in various forms and love them ever so. LilyPads are sewable versions of the Arduino, so if you're planning to do a lot of textile work, it's a really good option. You program those in C.

If you're in the mood for a hybrid project, you can use Processing (above) on a computer, then have it communicate with an Arduino, so you could do complex logic and communications on the computer and I/O on the microcontroller. There are some people who have combination devices that are part linux computer and part Arduinos, though I've never used one.

If you are doing a project with a lot of concurrent I/O, then you might consider a Propeller. They're a little odd, as they have several independent programs that each execute in their turn. So program one gets an instruction, then program two gets to run an instruction, then three, and so on until it loops around again. It keeps you from having to create your own threading system or otherwise manage all of that concurrency, but it's a weird mindset.

There are other options, of course. Many other options. Arduinos run on ATMega chips, which could be run without the Arduino software on top. It's harder to do, and requires different toolsets, but it's a lot faster. If you need the speed but don't mind the form factor, there are ways to bypass the Arduino overhead and just program it using the environment. There's the BASIC Stamp, the JStamp, and many more. 


There are surprisingly few methods of causing something to move. With a couple of exceptions, everything starts out going around and around, and then that circular motion gets turned into some other path as needed. That being said, there is often some other thing you might want your robot to do that isn't, strictly speaking, movement related, and all that goes into actuation.

Motors - Motors are the things that spin around a lot. The common types of DC motors are: brushed, brushless, stepper, and servo. There are variations of each type, but let's not worry about that right now.

DC Motors come in a couple of major flavors, namely brushed and brushless. Brushed motors are simpler than brushless, but brushless are more efficient than brushed. For a detailed explanation, check out this article on the difference between brushed and brushless motors. The most important issue is how you control them.

With both the brushed and brushless motors, you need to control how quickly they move. Your planner will likely not have the ability to do this on its own, because motors use a lot of current, and computers and microcontrollers are designed to move small amounts of current. To get past that, you'll need either an H-bridge or a motor controller. Both are methods of applying a small-current signal and a large-current source and using the signal to proportionally output high current to the motor. The H-bridge is a simpler and less expensive device than a motor controller, but a motor controller will have more features, often including the ability to reverse, over/undercurrent protection, and maybe even some feedback.

You are not likely to be able to control a modern brushless motor with an H-bridge, and you will need to match your motor controller to the type of DC motor you are using. 

Stepper motors, instead of going round and round continuously, are made to go in discrete increments. They are actually brushless motors, but they have some internal gearing in them to get them to stop in regular increments. Useful for things that need to go to discrete positions when you don't want to actually have to attach a sensor to see where it is at all times.

Hobby servo motors are another limited-style motor that takes a specific type of command signal, the Pulse Width Modulation signal discussed in Sensors, and uses that to go to a specific position. These are most often seen in RC cars and planes to handle the steering angle. The great thing about servos is that you can send them a very specific type of signal and, without keeping any other track of what's going on, know essentially where the motor will end up rotationally. There is a quirk because of this, though: when you first start up a servo motor, you have to go from having no PWM signal on the line to having some sort of PWM signal on the line. As a general rule, a 50% duty signal, meaning you are spending half your time up and half your time down in the waveform, is "center" for any given application.  100% duty cycle, or up all the time, will take you full one direction, and 0% takes you full the other direction. You can't immediately jump from nothing to 50% and expect to go to your center position, so applications that use servos for steering will usually twitch when they are first started up, while the signal goes from nothing to 50% duty cycle. 

Note that industrial servo motors will be a different beast, so ignore all of that above if you are thinking of working with an industrial servo.

Feedback loops - There's something I implied in the stepper and servo motor notes, which is that it's hard to know what's going on with a motor if you aren't sensing what's happening to it. If you are trying to use a motor to move something to a specific position, or you are trying to go a specific speed, you can't just expect to send it a particular signal and expect it to do what you want. Well, you can, but you will be terribly frustrated after. Motors are very dependent on real-world conditions; friction, air resistance, people, rocks, dust, and so on will get in the way of whatever you're doing, and will make your motor not travel as far as it might have otherwise. Even barring all that, motors will change characteristics over time, and you will likely want to compensate for that. Therefore, adding some sensing and changing what you're doing based on the data you're getting back is usually a good plan. Unless you're using a stepper, in which case you can count the steps you give it, or a servo, in which case you just send it the right type of PWM signal.

One way of sensing a motor's position is by using an encoder. Encoders can be digital or analog, absolute or relative. Absolute encoders will tell you what your position is, and are usually analog or expensive and not a simple digital signal. A potentiometer is a type of absolute analog encoder. Relative encoders will tell you how fast you're going and sometimes what direction. If you've seen speedometers for bicycles, they are about the simplest type of relative digital encoder. They use the Hall Effect to let a magnet pass an electromagnet coil. When the magnet passes the coil, if it's going fast enough, it generates a pulse. You could have one or more magnet placed equally around the wheel, and every pulse tells you the wheel has gone whatever fraction of a turn around. Keep count of that, and you can calculate the speed of your wheel. Other digital encoders work essentially the same, but the method used for keeping track will be based on different physical laws (light, sound, and so on).

To make a proper feedback loop, you have to consider what you're sensing, what kind of precision you need for knowing what's going on, and you need to be ready to handle it. If you are counting pulses with your microcontroller for a high-speed application, for example, you'll want to keep the number of counts on your encoder low, so you don't get too many pulses for your microcontroller to handle. If you had a commercial counter-frequency digital acquisition device, you could have it do the counting, then just send you a serial signal telling you what your current speed is. If you're doing low-speed, highly precise work, though, you want something that can give you a lot of pulses per revolution, and you want to not use a hall effect sensor, because those work better at higher speeds. That sort of thing. Learn the details of your application and look for the strengths and weaknesses of your components.

There are two major types of control loops: open and closed. Open loop means you send a signal and pretty much accept that what you want is what you're going to get. Closed-loop feedback means you are actively monitoring the speed or position while you are commanding it, and you are using smarts to change how you are going from one state to another in-between the major commands. So if you want to go 5 MPH in an open loop, you know that 1.2V on your analog input to the H-Bridge will get you pretty close, and (optionally) if you don't reach 5 MPH after a while, you can try a higher value. Or not, depending. In closed-loop control, you will plan every step of the way, including the rate at which you increase speed, and you will make adjustments along the way. The usual algorithm for this is called the PID loop. I'm not going to tell you about the PID loop right now.

Strictly speaking, open-loop control doesn't take any feedback. Strictly speaking. But a simple system that I described above is lacking enough in control that it might as well be open-loop. People will likely argue with that, so if you're talking with pedantic people about what I said, be prepared for them to say I'm dumb. 

Gearing - There are two major reasons to gear your motor. The first is to change the speed and torque of your motor. Using gears one way, you can take a motor and make it faster but weaker. Using them the other way, you can make them slower but stronger. You are looking for the gear ratio in this case. A gear ratio higher than 1 means that you will get more torque and less speed out of the motor in the end. A gear ratio lower than 1 means you get more speed and less torque. 

The second reason to use gears is to change the motion of your motor. If you need a wobble, or a flutter, or you need your motor to move in a straight line, different gear combinations will give you different effects. 

As a general rule, you will buy your gearbox to do what you want. You can make gears, or even pick sets of gears that your put together yourself to do what you want, but it's usually unnecessary and something that will take a lot of learning to get right. 

Linear Motion - As I mentioned, motors go round and round. If you need them to go straight, you need to attach something to the shaft to cause the rotational motion to go linear. You can buy motors that already have this work done for you, and they are called Actuators. There are a bunch of different methods to cause actuation to happen, and most of those are very interesting and well worth looking into, but not terribly useful to know off the top of your head. Mostly you want to know how quickly the actuation will happen, how far it can go, and how much force it can apply.

Solenoids - There is one type of motor that doesn't really go in a circle, but instead goes in a straight line: a solenoid. It's a simple device that quickly moves from one position to another. You don't have a lot of control with solenoids. They are the actuator version of the simple switch. They are on or off, one position or another. I have seen electric, pneumatic, and hydraulic solenoids.

Muscle wire - And now the oddball actuator. Memory wire will move small distances with a little force when an electric current is applied. I've not used it, but if you need something subtle and silent, this might be a good way to go. 

Non-movement actuation - Of course, there are so many ways to interact with the world than moving. Lights. Sounds. Smells. Jets of water. Electromagnetic pulses. The possibilities are endless. Each method of actuation will take a signal of some kind and convert it to an interaction with the real world. Some will require more power than you can provide with your planner, others you can run straight from your outputs.