Let's Make Robots!

Tips for making a robot multi-task

I have a robot, and my robot has a brain. However, my robot's brain can only think about one thing at a time. I can set I/O pins high or low, and they will stay there until I change them, but that isn't going to work. Here's the deal:

  • I have an OOPIC with firmware version B.3.something+ (whatever the newest is)
  • The OOPIC is a 40-pin pic with custom firmware. It is a development board
  • It can be programmed in C, Visual Basic, Or Java
  • It only does one thing at a time due to the nature of those programming languages (I use visual basic)
  • I need to proccess 3-5 things at once

My robot has a light-bar with 8 LEDs that I want to scroll back and forth like KITT. I could use a decade counter for this, but I want the rate and sequence to change based on the robot's activity. This is something that needs to run in the background.

My robot has two tank tread and a turret to control. The driving can be done with one proccess.

My robot has sensors and outputs to manage (ultrasonic, infrared, bumpers, speakers, etc.)

My robot has an LCD that needs to display its mode, speed, activity, etc.


So here is my problem: I need to do all of this at once. The KITT LED bar thing needs to be constantly going, the sensors need to be constantly sensing, and the drivetrain needs to be responding accordingly, etc. Each of these bits are super-easy to program because of the object-oriented programming environment with a few lines of code. The only problem is that it is a PIC, and it only executes one line of code at a time. Now, taking in mind that this is after all, just a PIC with some shiny firmware, how can I make it run multiple lines of code simultaneously? I can't have it sense, then drive, then update LCD, then stop and do the KITT LED Thing, then drive again, then beep, etc. I am not familiar with programming in C, but the logic still applies. So if you know anything about making a robot do multiple things at once, please leave a comment.

P.S. - If this seems badly worded/typed/confusing, well I typed it late at night and I can't think perfectly straight.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Simple low cost MCUs of which the OOPIC sounds like a member can`t multitask. It`s a simple fact.

Of course, there are ways to fake it though :) Using timers and interrupts you can set different tasks to run every certain time period. For example, you decide all sensors need polling every 500ms and a decision made, the LCD needs an update every 1s, and 1 LED on your light bar should move every 250ms. Then you could start a timer to generate an internal interrupt every 250ms. Each time the interrupt triggers, decide which routines need attention.

They will still be run in a one-by-one fashion but running fast enough they can give the impression of a multitasking robot to the human brain.

A better way to do it is to use something like an xmos chip which is designed from the ground up to support threading.

I have researched the XMOS processors, they are reasonably priced, and have amazing capabilities. The only problem is that as far as programming them, and their architecture, I'm clueless. Some day though. On my next robot I'll use one.

So basically you're telling me to just make it skip around really fast like in a multiplexed display. My MCU has a 20MHz clock speed. Do you think that will be fast enough? I can't imagine it wouldn't be. I don't want the robot to miss a sensor reading or skip a LED on the light bar.

Yes pretty much. And depending on your processor and the language you choose, you can do a hell of a lot of skipping with 20Mhz. If there are still critical things that can`t be missed (like encoders) you can use interrupts to get the processors attention.

Ok, feeling stupid here because I used to know this, but never use them; what are interupts?

Interrupts are triggers that make the processor pause its current operations and handle the interrupt. Once thats done it returns to where it left off. Interrupts can be triggered from lots of different stuff like internal timers ticking over or when an input pin state changes.