Using microcontrollers in your robot

3.4 Sequencers and operating systems

At the very top of the program, controlling which module gets called when, there is a controlling module. This may be as simple as a loop which calls each module in turn, up to the most complex operating systems such as Windows NT or Linux! Let's describe these in turn starting from the simplest. All examples will be in C:

3.4.1 Very simple main control loop

void main(void)
{
    int RxError;

    while (RxError == FALSE)
    {
        RxError = GetRadioCommands();
        ControlMovement();
        ControlWeapons();
        DoOtherStuff();
    }

    EmergencyPowerDown();
}

The three modules are called as fast as the processor can spin round the while loop. The three modules just get the current radio command. If the radio is just PWM from a normal RC receiver, this module will decode the PWM signal which then maybe will set global variables for the steering, movement, and weapons requests.
Notice the RxError variable which is set by the GetRadioCommands() function. If there is a problem with the radio data, this allows the variable to be set to FALSE which will cause an emergency shutdown in the PowerDown() function.

3.4.2 Timed control loop

The way to combat this is to use a timer in the controller (whether it be a microcontroller or a single board computer) to generate a timer-interrupt:

void main(void)
{
    /* Setup the timer interrupt */
    SetupTimerInterrupt();
    GoToSleep();
}

void interrupt [T1] TimerInterruptServiceRoutine()
{
    int RxError;

      RxError = GetRadioCommands();

      if (RxError == TRUE)
      {
        EmergencyPowerDown();
      }
      else
      {
        ControlMovement();
        ControlWeapons();
        DoOtherStuff();
      }
    GoToSleep();
}

In this example, the main function just sets up the timer interrupt and sends the processor to sleep. Most embedded controllers will have a low-power sleep mode where it just idles using very little power until an interrupt occurs. When the interrupt is detected, the interrupt service routine (ISR) is called. This function declaration uses a format used by IAR embedded compilers. The 'interrupt' word tells the compiler this is an ISR, and the word in square brackets tells it which interrupt vector this function is for. I've just called it T1 to mean 'Timer 1', but it will be different depending on what processor is being used.

Let's go through the operation. First, in main(), the timer is set up to interrupt every 'n' milliseconds. Then the processor goes to sleep. After 'n' milliseconds the interrupt will arrive and the TimerInterruptServiceRoutine() ISR will be called. This gets the radio command, and performs the movement and weapons as reuqested, then goes back to sleep again. The process is repeated each time the interrupt arrives.

What happens in the code in TimerInterruptServiceRoutine() takes longer than 'n' milliseconds? Generally, a disaster! Most processors will not respond to another interrupt if they are already in that interrupts ISR. This means that the interrupt will be ignored. This may not be a problem if your code can cope with that, but generally it is better to make sure that the ISR will always complete before the interrupt next arrives.

3.4.3 State machines

If this cannot be guaranteed, we can use a state machine to control what gets run each time the interrupt is called. For example, we can do the motion control one visit, then the weapons the next, then the motion control again, etc. However many modules need calling, a state machine can control the order and frequency in which they are called. Let's add a state machine. The main() function remains the same so is not shown:

/* These are the possible states */
enum {RADIO, MOVEMENT, WEAPONS, OTHER_STUFF};

int StateVariable = RADIO;

void interrupt [T1] TimerInterruptServiceRoutine()
{
    int RxError;

    switch (StateVariable)
    {
        case RADIO:
            RxError = GetRadioCommands();
            if (RxError == TRUE)
                StateVariable = EMERGENCY_POWER_DOWN;
            else
                StateVariable = MOVEMENT;
            break;

        case MOVEMENT:
            ControlMovement();
            StateVariable = WEAPONS;
            break;

        case WEAPONS:
            ControlWeapons();
            StateVariable = OTHER_STUFF;
            break;

        case OTHER_STUFF:
            DoOtherStuff();
            StateVariable = RADIO;
            break;

        case EMERGENCY_POWER_DOWN:
            EmergencyPowerDown();
            break;

        default:
            StateVariable = RADIO;
            break;
    }
    GoToSleep();
}

In this example, only one function is run for each interrupt. Which function is run depends on the state variable. That function then decides what the next function to be run will be. We can draw a simple state machine to describe the behaviour of this code:

In this manner, very complex state machines can be created. Each function (movement, weapons, etc) can also have state machines inside them. For an example of this, see the demo code later in this chapter.

If the state variable is every anything but one of the states, the 'default' command will set it back to into the state machine. This is important in safe programming to control crashes. If the RAM holding the variable got a glitch and got set to 255, then this default action will restore the state machine to proper functionality within one interrupt.

3.4.4 Counter controlled sequencers

You may want the functions to be called at certain intervals and at certain times with respect to each other. One way to perform this is using a counter sequencer:

void interrupt [T1] TimerInterruptServiceRoutine()
{
    static int Counter = 0;

    switch (Counter)
    {
        case 0:
            RxError = GetRadioCommands();
            if (RxError == TRUE)
                EmergencyPowerDown();
            break;

        case 1:                     break;
        case 2: ControlMovement();  break;
        case 3: ControlWeapons();   break;
        case 4:                     break;
        case 5: ControlMovement();  break;
        case 6:                     break;
        case 7:                     break;
        case 8: ControlMovement();  break;
        case 9: ControlWeapons();   break;
        case 10: DoOtherStuff();    break;
        default: Counter = 0;       break;
    }
    Counter++;
    GoToSleep();
}

In this example, the action repeats every 12 interrupts. In that time, the movement action is performed four times (every 3 interrupts), the radio is read once, and the weapons controlled twice. This allows us to set the priorities, and the order in which the actions occur. When the counter reaches 11, the sequence restarts. If the counter gets corrupted, the sequence will also restart.

3.4.5 Real Time Operating Systems (RTOS)

The main function of the RTOS is to control what modules get called when. In RTOS terminology, the modules are called processes. This is the same as what the sequencers above were doing, but RTOSs allow a lot more flexibility. Common features of them include:

• Pre-emptive multitasking. This means that a process may be running along happily, but when a more important process wants to run, it stops the first process and takes over until it has finished, whereupon the first process starts where it left off again.
• Process priority setting. Each process can be assigned a priority, often from 0 to 255. If a lower priority process is running when a higher one wants to start, the low priority process is suspended until the higher one has finished (or until the higher one suspends waiting for something else - see below).
• Inter process messaging. Each process can send and receive user-defined messages between each other. These may be in the form of queues, pipelines, or FIFO stacks. If a process is expecting a message but the message has not arrived yet, it can suspend on that message, This means it will stop running (thereby allowing other lower priority processes to run) until the message arrives. Processes can also suspend waiting to send a message to a process which has a full mailbox
• Full timing control. Each process can be set to run at regular intervals using timers. They can also use timers just to read, or to suspend on until the timer reaches some value. Any number of timers can be used because these are under software control of the RTOS, which uses the hardware timers to control them.
• Interrupt control. The RTOS will generally take care of the hardware interrupt actions, making use of these rather easier.
• Peripheral drivers. Some RTOSs include drivers for disc drives, FLASH memory, IIC devices, TCP/IP stacks, etc.

Some RTOSs have more features (and are more expensive!) than others, so the choice is yours. At least two are entirely free as long as you don't use them for commercial products. The table below shows a few and where to get them:

Writer	RTOS	Comment / Processor platforms	Free?
Wind River Systems	VX Works	One of the industry standards. Many platforms.	No
Accelerated technology	Nucleus	One of the industry standards. Many platforms.	No
QNX	QNX	Based on UNIX many years ago. Has developed into a separate product now. PC platform.	Yes
Jean Labrosse / Micrium	MicroC/OS-II	Comes with the book MicroC/OS-II RTOS (see link in books section below). Many platforms.	Yes
RTEMS	RTEMS	Open source RTOS	Yes
	AvrX	An RTOS for the Atmel AVR family.	Yes
Seoul National University	ARX	PC platform	Yes
Red Hat	eCOS	x86, PowerPC, & Intel StrongARM platforms	Yes
University of Pennsylvania	EROS	x86 platforms.	Yes

There may be more listed on this site.

3.4.6 Computer operating systems

A while back, Microsoft decided to try to enter the RTOS market by stripping down Windows NT. They boldy claimed that the Embedded Windows NT would run in only 8 Mb of RAM. Most proper RTOSs will run in about 4kbytes! Unfortunately for them, it wasn't exactly real-time either. An RTOS must strictly obey the timing constraints set by the program, and must never miss an interrupt. It is important that the time betweem an event and the response must have a definite maximum. All proper RTOSs do this.

What about Linux? Again, this is not an RTOS. However, RTOS versions of it have been written, and of course they are all free under the Linux license. An article all about them appeared in Linux User issue 9, and is available in PDF format here

3.5 What can I do in software?

• Initialisation of radio chip – channel and gain selection.
• Reception and decoding of serial data stream from radio chip.
• Monitoring of wheel speeds.
• Setting of wheel speeds, including motor PWM levels and current limiting.
• Determination of which way up robot is, and consequent swapping of motor directions.
• Dual hammer weapon control, including firing and docking.
• Rail-gun spear control, including spear position detection and coil sequencing.
• Pneumatic valve control for flipper.
• Pneumatic reservoir charging with compressors, including pressure sensing.
• Control and pattern driving of 99 (3-phases of 33) LEDs around robot periphery.
• Emergency shutdown (failsafe) based on radio code error detection, watchdog, and fault conditions.
• Emergency escape – retract all weapons, turn off compressors, turn off current limiting, switch ot open loop speed control of wheels, and send all power to the wheels.
• Tricks involving flipping over, spinning, weapon brandishing etc.

3.6 Radio messaging

If you have a 2-channel radio set and use a microcontroller with twu UARTs, you can send the same data through both channels. Then at the receiver, direct each channel to each of the UARTs. If one channel is suffering from too much noise, the data from the second channel can be used. This sort of redundancy can increase the reliability of the robot a great deal.

As an example of a radio message, or packet, that can be used, here is the format of the data stream that I use in my robot. Commands come in a continuous stream of packets from the handset. Each packet is a fixed length and is of the following format:

START (16 bits)

This is a constant 2 byte message 0xA55A. This two-byte sequence cannot occur elsewhere in the datastream, so if the robot starts looking for data half way through a sequence, when it sees this pattern it knows it is at the start.

SPEED (8 bits)
Required speed. 0 to 99.
DIREC (8 bits)
Required direction in 2 degree steps. 0 degrees is straight ahead,
90 degrees is exact left, 270 exact right, and 180 full reverse. The
value is half of the angle required.

WEAPON (16 bits)
A bitfield to indicate required weapon operation:
0: Front hammer forwards
1: Front hammer reverse
2: Rear hammer forwards
3: Rear hammer reverse
4: Spear forwards
5: Spear reverse
6: Spear multi-throw
7: Reserved (0)
8: Flipper operate forwards
9: Flipper operate reverse
10: Extend flipper forwards
11: Extend flipper backwards
12: Retract flipper
13: Operate flipper
14: Spare
15: Reserved (0)
The reserved positions are there to ensure that the two-byte data can never be the same as the start pattern = 0xA55A.

SPECL (16 bits)
Special requests:
0: Light sequence b0
1: Light sequence b1
2: Light sequence b2
3: Leg assist
4: Emergency
5: Brandish weapons
6: Speed Control Method (0=Open loop, 1=Closed loop)
7: Reserved (0)
8: Lights - reset sequences
9: Lights - Auto repeat
10: Spare
11: Spare
12: Spare
13: Spare
14: Spare
15: Reserved (0)

CRC (16 bits)
16 bit CRC for packet. This is a Cyclic Redundancy Code, and is like a checksum. It is a complicated mathematical function of all the previous bytes in the message. The robot recalculates this from what it received, and if the two are equal, it is highly likely that the message was received correctly. If they are not equal, the whole message is ignored. If there are enough sequential bad messages, the radio link is assumed to be faulty and an emergency power down sequence is initiated.
 
 

3.7 Debugging

• emulators
• simulators
• diagnostics
• datalogging
• display indicators

• Ideally, you would have an emulator which you can plug in the microcontroller socket, and perform single stepping, set breakpoints, display memory and I/O states etc. However, emulators are very expensive.

• The next best thing for working out where your software is going is a simulator. These run on the PC and allow you to single step, look at memory, and program variables, but becuase they are not connected to the target system, you will have to set the I/O lines as you think they may have been set in the robot. They are good for debugging all your higher level functions in your code which don’t depend on low-level I/O states. Some simulators are better than others for allowing you to set I/O and peripheral devices. Some will even simulate timers that are set up to be clocked internally to the processor, and may have script file interpreting to drive I/O lines.

• A diagnostic link is great boon. If you are implementing a boot download facility, you can use the same serial port line to implement diagnostics. The basics is to implement memory read and memory write features, which can run in the main sequence loop of the software. This allows you to read variable values (as long as you know their memory address), and setup other values. You can implement "softbutton commands" which perform certain actions if the softbutton code is sent. The softbutton code may be a write to a reserved memory location.

• On a new design, it is always a good idea to have the ability to perform datalogging of important parameters. A reasonable size store will be required, for example, a 4kbyte serial EEPROM, which only requires 3 control lines. If you are having trouble with a certain part of the code, you can insert LogEvent(EventCode) type function calls which may log various parameters along with a date/time code to the log store. This can be looked at afterwards to try to determine what happened.

• Display indicators may range from a dot-matrix LCD display (not fitted in real battles!) down to a simple LED that you can flash if your code gets to a certain point. The latter is just about the minimum amount of debug feature you can add, and will strain your debugging skills and patience to the limit!

3.8 Compilers

3.9 An example

The code is not debugged yet, but it does compile and build. It is written in C, and compiles under the MCS C Compiler for the Hitachi H8S 2148 microcontroller.
 
 

Onboard.c
Onboard.h

This is the top level sequencer.

Lowinit.c

This is the microcontroller initialisation function.

Radio.c
Radio.h

This sets up and performs radio communication, using the Motorola MC13111 FM radio chip.

Commands.c
Commands.h

This accepts the commands from the radio link and decodes them

Motion.c
Motion.h

This detects the wheel speeds, and controls the wheel speeds and direction in either closed loop or open loop mode.

Sensors.c
Sensors.h

This reads the onboard sensors, just a mercury switch at the moment.

Weapons.c
Weapons.h

This controls all the weapons.

Display.c
Display.h

This controls the optional 2-line LCD display. The display controller chip is the ST7066, a compatible chip with the Samsung KS0066, (aka S6A0069).

ShiftReg.c
ShiftReg.h

The H8S does not have enough inputs and outputs, so a shift register chain has been added to extend this. Access to inputs and outputs through this chain is a lot slower, so is only used for non-speed-critical functions. The shift registers used are 74HC165 and 74HC595 (for datasheets see the Philips HC shift registers page).

Lights.c
Lights.h

This controls the LEDs around the periphery of the robot. An Acrobat PDF article about dimming LEDs is available at
http://www.infineon.com/cmc_upload/migrated_files/document_files/Application_Notes/inganled.pdf

Shutdown.c
Shutdown.h

This controls the emergency failsafe power shut down and pneumatic purge.

Binary.h

Definitions so I can use binary numbers in C.

Hardware.h

Hardware specific defintions. This is all placed in one file so if I ever change to a differenct processor, hopefully only this file will need changing.

Ioh82148 .h

This comes with the IAR compiler and is the definitions for all the on-chip peripherals.

cstartup.s37

This is generated by the development tools and is the assembly language functions to initialise all the variables declared in the C code.

Unfortunately I can’t supply the compiler and simulator for download since they are proprietory products!
 

4. Links