Real Time Executives

 

While a robot can generally be programmed to do a task with in line code,  better performance can usually be achieved by using PID type equations.  And PID equations must be executed at a consistent time rate since some of the equations have the time interval between executions as a variable.

Fortunately, a real time executive does not HAVE to be complicated.  Basically it has the same architecture as a normal in-line program; except, it adds a new feature, the interrupt handler, which is given the responsibility of running all the real time critical software.

IN-LINE PROGRAM   (in pseudo-C layout)

    FunctionA();    a real time critical task

    FunctionB();    a task in which timing is not critical

   Main()
       {  While (1)
               { FunctionA();
                  FunctionB();
               };
        }

REAL-TIME PROGRAM

    FunctionA();    a real time critical task

    FunctionB();    a task in which timing is not critical

    RealTimeInterruptHandler();    //this causes FunctionA to be executed at a consistant rate
      {FunctionA();
      };           

   Main()

        Initialize RTI timer and enable interrupts;

       {  While (1)
               { FunctionB();            //this allows FunctionB to be executed at an arbitrary rate in the
               };                              //time remaining.
        }

Another advantage of the real time program is that since it usually executes at a relatively high repetition rate, a task that might normally require waiting until it is completed can be initiated in one real time cycle and the results read in a subsequent cycle.  For instance, a sonar sensor would require software to send out a pulse and time until the return of the pulse.  A target 15 feet away would take about 30 milliseconds to get the echo back.  With the RTexec, the pulse can be sent out and a timer started and the software can continue with other tasks.  Subsequent executions of the RTexec can then check the timer to see if the echo has been received.  Hence, there is seldom any need to use a wait loop, or a pause statement; so your software can spend the available time actually calculating rather than waiting.