AUTONOMOUS LINE FOLLOWER

Introduction to image recognition

This project was done quite a while back to participate in a robotics competition. The objective of such contests is usually to have robots follow a white-tape road "path"as fast as possible.

This presented a great opportunity to get started on the visual recognition subject. The decision was made to create a small four wheeled robot, with a black and white camera. This would allow it to look at the path ahead and decide how to turn and change speed.

One throws the concept of "recognition" around quite too easily, but I started finding real questions that begged to be answered, and had no idea where to begin. These answers came in slowly and almost empirically, as I thought, after all, what the hell I'm I supposed to do with a collection of pixels? How do you USE that in a meaningful way?
Throughout the project, some key areas of software development became clear, but keep in mind they're all at different levels:

-Interrupt Routines
I know, I know, this is rather just a low-level 'technical' aspect, but it's worth mentioning here. Quick recap for this: When a signal of interest makes the processor jump to execute a specific subroutine, and then it returns and continues where it left off. More on this later.

-RTOS Main Looping
One of those things that you're not formally taught in school, but always end up learning 'as you go'. Pretty much the same concept as in video games: You have a refresh period for each of your "frames" (graphics or not), in which you gather your inputs, process the data, and produce some outputs. Usually done at such a fast rate that observers just see a non-stop process.

-State Machines
This concept was really not answered on this project, as the robot ended up with pretty much one single "instinct" state: that of following lines, all the time! Also, within that same idea, it could only follow lines with one single method.
The culprit here is the prevailing mentality of applying continuous functions and linear algorithms to real life problems. This is what happens when too much emphasis is placed on the MATH of it. But these are rather really multidisciplinary issues that need discreet answers. Specially with the advantage we have today of having the most versatile state-driven device out there: The Microprocessor.

-Representation
This is the one area, being at the highest level, that gets most close to philosophy. Knowing that a system is made of only inputs, processing, and outputs, and that a computer handles only numbers, it must be clear that we must be able to create a numerical representation of the relevant world around the system. As I explain in other articles, representation is the one area that's lef out for last in many VR theories out there , but IMO it should be the first thing to be answered: How do i want to numerically represent the world? If this goal is not clear, the solutions become more difficult. Further then, the collection of pixels -in our case- should ultimately become a set of meaningful values in which the robot can then operate to produce some output (steering, acceleration). As you'll see, this final numerical representation of the track "path" ended up being very very small (moravec's paradox), but was rich in information.

HARDWARE:
I'll only do a quick recap on the system, for clarity; As we are not devoted to the physicals in this article:

-Car
The 'frame' was made out of carbon fiber over an aluminum mold

-Camera
The cheapest and smallest camera at the time was this B&W from cctvwholesalers.com:
It provides an analog NTSC signal, where dark parts of the image approach 0 Volts, and light parts approach 1.0 volts. But more on that later ;)

-Circuit

-Servo
internal feedback, guaranteed position

-Motor
pwm, speed read from motor line

Next Section: Capturing relevant image information...
Page2

STATORWORKS