Robotics/Design Basics/Basic Programming

< Robotics < Design Basics

Programmable devices

Microcontrollers

These days using programmable components is easy. In the early days you had to write code in assembly, burn it in an EPROM, plug the EPROM in its socket and hope you didn't make any mistake. Because if you did, you had to hunt down the error in hundreds of lines of cryptic assembly code and had to use a new EPROM. These days you've got flash memory which can be reprogrammed in circuit. You've got C and Basic compilers to write your code. Most µcontrollers have a whole lot of hardware on chip (UART, Watchdog, Real Time Clock, RAM, ROM, EEPROM,...) and libraries are available for different programming languages which make coding LC-displays or Servos very easy. Not to mention you've got emulators (A special connector plugged into the MICROcontroller socket which allows a PC to pretend to be the µcontroller) and simulators (simulates the µcontroller on a PC and allows to run its code) to hunt down the bugs.

AVR

A good µcontroller to start with is the Atmel AVR ATtiny2313 (previously: AT90S2313) or ATMEGA8535 (previously: AT90S8535) (Atmel). It's cheap, has all the essentials on chip and has a whole lot of websites dedicated to it. The 8535 is more expensive, but has more memory and has an on board ADC. An AVR combined with Bascom-AVR is pretty much the easiest way to start with µcontrollers.

See Atmel AVR for details.

See Robotics/Computer Control/The Interface/Microcontrollers for other popular microcontrollers.

See General Engineering Introduction/Arduino and Motors/Arduino Introduction for one way to do AVR development.

PC

The PC has many advantages over µcontrollers when it comes to controlling a robot. However it has 2 flaws that make it nearly impossible to use in small robot-projects:

First: it's large and heavy.
Secondly: A modern pc consumes enormous amounts of power.

This means that PCs are limited to tethered or large robots. If power isn't a problem the PC offers enormous amounts of RAM and HD space and plenty of CPU power. Plus a very handy user interface. Also network capabilities can be very useful for some applications. Providing your robot with a wireless connection (IR, radio, WiFi, bluetooth,...) and a similar interface on the PC reduces the wire-problem to a limited-distance (or in the case of IR a line-of-sight) problem.

If you intend to use a PC in your project, you might want to use one of the flavors of linux as the OS, as it allows easy access to any of the parts of the computer. Another choice for an OS is the older MS-DOS, although MS-DOS lacks multithreading (but those can be added in your software) and has ugly memory management (remember the 640Kb limit?).

Laptop

The laptop has only its size against it. A laptop provides the benefits of a PC without the enormous power consumption. The downside to laptops is their limited battery life.

PDA

The PDA (Personal Digital Assistant) is nothing more than a hand held PC (Personal Computer). Most of the time these units used scaled down RISC (Reduced Instruction Set Chip) processors to allow for fast execution times and also allow the unit to remain smaller and lighter than your average laptop. Some PDA's even have built-in GPS which makes it very interesting for outdoor robot applications. The downside is their price. The PDA is useful for play, but also serves as a great business tool especially when they are equipped with a stylus.

Gameboy

The Gameboy (the classic, advance, color and DS) can be a very powerful device. These have been used in many projects (see google). The only drawback is constructing the special PCB to act as a connector.

Gameboy Advance (GBA)

The Gameboy Advance is also excellent as a robotics platform. There are a few complete open-source development suites available (GCC based C/C++ plus ARM assember). There is also a good kit (Charmed Labs) available to interface Lego robotics motors/sensors and give much more control compared to the Lego RCX. With 4MB of FLASH and a few hundred K of RAM the kit has huge potential. The kit is not really for the complete beginner though as setting up the GNU tools can be quite complicated although the development environment is consequently very rich.

See GBA Development for tips on writing software for the Game Boy Advance.

Programmable Logic Controllers

Programmable logic controllers, PLCs, are special purpose industrial computers, made to be easy to interface with electrical circuits. Most PLC are expandable but there are some compact "all-in-one" solutions as well. They have excellent bit-manipulating possibilities, and add-on-cards for several special signals as high-speed counters, analog I/O, networks and fieldbuses (RS-232, RS422, RS-485, Ethernet, DeviceNet, Profibus...), pulse output, servo control, etc. Increasingly, special inputs are included in the PLC CPU unit. PLCs are traditionally used to control automated factories, possibly several machines per PLC. They normally use special-purpose programming languages, most commonly ladder or SFC.

PLCs are available in sizes from approximately 5x5x5 cm (there is a PLC IC available as well, but for the purposes of this book we choose to ignore that fact). The smallest ones are very limited though, with only a few I/Os and very limited memory, and also very limited instruction set with regards to data processing and calculations. PLCs are especially suitable if you have a lot of experience of electric systems, but feel intimidated by designing and soldering PCBs and programming computers (i.e., you are an electrician). They also shine in very large system with many special purpose sensors and outputs, as mostly there will be a standard solution from the manufacturer that is possible to use.

The downside with PLCs are their price - They can be quite costly, normally at least an order of magnitude higher than microcontrollers. They also draw more current than a microcontroller, however less than a computer. On the other hand, compared to a computer, they are computationally weak. They aren't suited for heavy signal-processing work.

PLC:s are best suited for large robots, but could be usable in medium-sized projects as well.

Combinations

It's common to use both a computer/laptop/PDA and (a) microcontroller(s) as those 2 complement each others limitations. e.g. The first has the advantage of large amounts of memory and processing power, however lacks specific outputs that are very handy in robotics, like PWM. Microcontrollers commonly have PWM channels that operate independently of the rest of the microcontroller, but are limited in their processing speed and memory.
Linking those 2 devices provides the best of both worlds.

Programming languages

This page discusses some of the available programming languages and provides links to download compilers for those languages.

Which language to pick?

The choice of language depends on a few points:

previous experience. If you're already comfortable with a particular programming language, you'll probably want to use that language for programming your robot.

How much time and effort you intend to invest. Not every language is equally hard/easy to use. Most of the complexity of a language comes from allowing more low-level access. Basically the more control a language gives to the user, the harder it is to use, but also the more powerful it is. In theory Assembly would allow a programmer to write the fastest and smallest code. However this is only true for an experienced programmer. Modern compilers can generate code that comes near to hand written Assembly. In most cases, using Assembly needlessly complicates a program, with the exception of using inline assembly in a C or Basic program. Usually these are a few lines of code which work directly with memory, or have to execute in a known time. For many if not most projects, a language such as Basic or C suffices. Only if you intend to push a microcontroller or PC to the limits of its capabilities is it worth the trouble of writing Assembly code.
your goals. If you want a simple robot, you wouldn't need Assembly code at all. With modern microcontroller you can easily write sloppy Basic code and still have sufficient speed and memory. If you intend to build a cutting edge robot with a few dozen sensors, image recognition and speech recognition you'll need to write perfect code and will need Assembly for some of the components in order to have enough speed and be able to fit the code in the limited memory of the microcontroller(s). Most projects will fall in between these two extremes and good written Basic or C code would be more than sufficient. Knowing (some) Assembly can be useful as it'll give some insight on how processors work. Such insights make you a better programmer.
Availability. Not all languages are available for all microcontrollers. Urbi is open source, C and Basic and Forth are common, often as freeware, other languages might be available commercially, or not at all.

Writing your software

This section doesn't intend to teach the basics of programming, just those points that aren't addressed in most programming tutorials and beginners books.

Style. "Style" is how you indent your lines, how you pick your variable and function names. Pick one and stick with it throughout your program. Especially for functions and variables you should decide when to use capital letters, underscores and when to stick words together. Doing this the same everywhere makes it easier not to miss-spell names.
Use informative names. Functions, procedures and variables should have informative names. Their purpose should be clear.
Plan before coding. In software development there are two important steps before coding: requirement analysis and software architecture. The first is about finding out what the program is expected to do, what inputs to expect, which output it should generate and what the limitations of its environment are going to be. The latter involves working out how the program is going to be structured, which data types to use, which algorithms, how the input is going to enter the program and how to make sure it's valid and how to format the output. Using a lite version of these steps will make it much easier to write a decent program. If you intend to build a more complicated robot, you'll going to need to invest more time in planning out your software. Have all your software requirements written out first. Then pick a few of the most critical requirements and refine them. Implement those first. After you're done with those (this includes throughfully testing them), pick a new set and refine and implement those. By doing it in small steps you avoid having to write out everything at the start (and making many assumptions) and get to use the insights you get by coding parts of it.
Use PDL (Program Development Language) PDL is a method to write functions. It involves writing down the individual steps of a function in plain English without referring to language-specific things, then refining these steps into smaller steps, until it's easier to write the code than to split the steps further. Afterward leave the PDL lines in as comments.
Simulation and Debugging Learn to use the simulator. It's easier to find errors there than in the hardware. Also learn to use the debugger. It's your best friend for finding errors.
If your software runs on a PC a log-file can be useful. But be picky with what you let the software log. If you intend to run it for a long time those log-files can become massive. If you want to log sensor data over time, know that these can be imported in Excel by saving the data with spaces between them to separate columns and newlines to separate rows. See w:Comma-separated values.