What do you use for processing?

[thedude]

Hello,
I am a newbie in the world of robotics and I was wondering what people are using for the "brains" of their robotic projects.

I build a robot recently which worked fine, but since I was using one slow microcontroller to handle all of the logic and running the motors, it acted very clunky. Even after optimizing the code, it still seemed as though I was doing something fundamentally wrong.

The robot that I am currently working on is something is mainly something that can navigate mazes via polling ultrasonic sensors, with the addition of a few other sensors in order to do simple tasks.

So what I am wondering is, is what hardware I should be using? I was thinking something along the lines as using multiple microcontrollers to poll sensor data while another microcontroller would receive the data via I2C and run the motors accordingly. I was also considering the idea of programming the FPGA to be some kind of master, while using various microcontrollers as slaves on a I2C to serve the motors.

Again, sorry for the noobish question.

Any help is appreciated, thanks.

[jwatte]

A microcontroller can do what you suggest, if treated carefully.
You should never use a delay() call anywhere.
You will probably use interrupts and overlap certain operations.
Most of your code will be a big state machine that's run in the main loop:

1) Check any events/flags since last loop.
2) Read any available inputs.
3) Figure out what to do next based on available state.
4) Possibly start some new operation.
5) Update outputs.

For example, to read an ultrasonic sensor, you typically don't want to first pull the line high, and then delay waiting for the input pulse. Instead, you pull the line high, and store away the time (measured in a small unit, like microseconds, or some timer tick that runs at a speed of between 1/16 and 16 microseconds per tick.)
In your main loop, when you see that the current time is greater than the start time plus required pulse time, turn off the pulse, and record the time again.
In an interrupt handler that runs when the ultrasonic sensor input pin goes from high to low, read the value of the timer and set a flag that you got that edge.
Again, in your main loop, when you see this flag, read the "pulse started time" and the "pulse completed interrupt time," to calculate how long the pulse was. This is now a new sensor input reading available for the rest of the logic.

Note that planning out microcontroller programs like this is *hard* because it requires managing many different pieces of state, and make sure that they don't step on each other. This is why most microcontroller tutorials only show you how to do one thing at a time.
If you've never done threaded, distributed, or otherwise asynchronous programming before, you *will* get it wrong a fair bit. This is the kind of software design that may make undergraduate computer science students fail.

Welcome to robotics :-)

[waltr]

Yep, jwatt said it very well.

One bot I build used a older fairly, low end, 4MHz PIC (16F84A). But through good code design (and written in assembler) this little, slow processor was handling:
1- Software generation of PWM for two independent motors (differential drive and steering).
2- Wheel speed sensor that feed-back to the motor speed control PWM (the bot would travel straight for a very long distance).
3- several bump sensors (switches) for obstacle avoidance
4- software serial communication (bit-banged) for debug and status
5- running obstacle avoidance code to stop, back up, turn, etc

The code was a total of about 500 bytes which easily fit into the 2k program space of this PIC.
The heart of this code used the built in hardware timer that produced an interrupt every 100usec (system tick). Everything that was time critical was based on this system tick. None of the code was 'blocking' so every time critical operation was executed when needed.

As jwatt said learning this is not so easy since there is not any easy tutorials or examples to use. Microchip (PICs) does have a App Note that show the basics of how to do this (the code runs 5 software UARTS, one sending and four receiving). However, the example is in PIC assembler and this did take me quite some time to study before I understand how it worked. Once I understand this example code I was then able to apply these methods to robot code.
If your are interested read Microchip App Note: AN585. The discussion and explanation in the App Note is fairly good and applicable to any processor and programming language.