Newsgroups: comp.robotics
Path: brunix!news.Brown.EDU!qt.cs.utexas.edu!cs.utexas.edu!zaphod.mps.ohio-state.edu!darwin.sura.net!haven.umd.edu!decuac!pa.dec.com!engage.pko.dec.com!nntpd.lkg.dec.com!dbased.nuo.dec.com!labrea.zko.dec.com!man
From: man@labrea.zko.dec.com (Richard Man)
Subject: beta-testers for real-time executive wanted!
Message-ID: <1993Feb23.205659.7461@dbased.nuo.dec.com>
Lines: 232
Sender: news@dbased.nuo.dec.com (USENET News System)
Reply-To: man@labrea.zko.dec.com (Richard Man)
Organization: Digital Equipment Corporation
Date: Tue, 23 Feb 1993 20:56:59 GMT


The following is a brief description of a subsumption architecture
based preemptive multitasking system that I am working on. I am looking
for beta testers (*). To be eligible, you must:

1. use 68HC11 target with at least 24K of RAM
2. have a ANSI-conformant C cross compiler for the 6811 (i.e. Dunfield's
   Micro-C is not enough).

If you are interested and qualified, send me mail at man@labrea.zko.dec.com.
Please describe what board and compiler you are using, and what systems
you are working on. Thank you.

BTW, originally I was going to call this BRET, for
Behavior-based Robot ExecuTive, or
Behavior-based Real-time ExecuTive

I am now leaning toward
RTX/is, for Real-Time eXecutive for Intelligent Systems.

Let me know which one you prefer ;-) 

(*) I am still awaiting approval from DEC for me to sell this as
shareware (will be very low cost to hobbists and students), but presumably 
this will not be an issue.

===================
RTX/is - real-Time eXecutive for Intelligent Systems V 1.0

What is RTX/is?

RTX/is is a small multi-tasking preemptive executive for
implementing control programs for intelligent systems such as
robotics and distributed networks. It provides functions for
managing tasks, memory allocation, message ports, timers, and
event processing.

Why use RTX/is instead of a traditional real-time executive?

RTX/is provides functions found in other traditional rel-time executives.
In addition, by using its unique message passing calls, a control program
may be constructed as behavioral tasks; with the high level ones
subsuming the functionalities of the lower ones. Typically, the
lower level behaviors are reactive in nature - dealing with
real-time stimuli as they happen, and the higher level behaviors
are deliberative in nature and contain data processing code.

What is the basis of the "unique" message passing semantics in
RTX/is?

The message passing semantics is loosely based on the
subsumption architecture invented in the MIT Mobot Lab for
controlling autonomous robots. However, RTX/is does not contain
any code or algorithms from the MIT subsumption languages. Extending
a real-time executive design with subsumption architecture based 
messaging brings additional power to the executive.

Explain these message passing calls.

Briefly, a task contains message ports which are connected to
other tasks' message port(s). The type of connection determines
how messages are written from a source port to a destination
port:

Write Normal

The message is written to the destination port.

Write Exclusive

The message is written to the destination port and no other
message may be written to that port for a period of time.

Write Through

The message acts if it is written from the destination port and
the message is propagated from the destination port to all ports
that are connected to it. This process repeats for all Write
Through connections. In addition, no message may be written from
the destination port for a period of time.

Summary of RTX/is executive functions

Version 1.0 contains the following functions.

Task Management 
TaskCreate
TaskKill
TaskResume
TaskSleep
TaskSuspend

Message Management
PortConnect
PortNameToID
PortPeekExternal
PortRead
PortWrite
OUT_PORT_DECL
IN_PORT_DECL

Event Management
WatchPort
WatchResume
WatchSuspend
WatchTimer
WatchWait
WatchWaitForEvent

Executive and Memory Management
ExecAllocMem
ExecDisable
ExecEnable
ExecFreeMem
ExecNewHeap
ExecSetSchedulingRate
ExecStart

Requirements for running RTX/is

You must have an ANSI C conformant compiler to compile the
executive. Specifically, function prototypes, structures, and
preprcoessor stringization operator (this is not absolutely
necessary) are used. In addition, there
is a small assembly module (~50 lines) for task switching and
management.

Currently, RTX/is is targeted for MC68HC11 microcontrollers with
24K bytes or more of RAM. The executive is approximately 12K and
is ROMable. Additional targets are under investigation or can be
arranged.

What is the scheduling rate and policy? What about interrupt
latency?

Scheduling is preemptive round-robin at a system default rate of
~4 milliseconds on a 8 MHz 68HC11. Scheduling is controlled by
the Real-Time Interrupt (RTI) function and is selectable to be
~4, ~8, ~16, and ~32 milliseconds. Since the executive is
non-reentrant, interrupt latency is bound by how long an
executive function runs. Most executive functions run at
constant time, few take time proportional to their input. All
executive functions use optimized algorithms to make the
interrupt latency as short as possible.

An example of a robot control program

This example is excerpted from the control program of Ripley I,
an autonomous rover based on a modified Radio Shack RC van
chassis. The drive motor can be signalled to stop, go forward or
backward. A servo controls the direction of the drive wheels,
and another servo controls a rotatable platform holding a sonar
module. This sonar module is used to detect distance to objects
and the rotatable platform provides the rover with a larger
degree of view. The only other sensors are a front bumper switch
and a back bumper switch. This is an open loop system - there is
no feedback from the drive motor to the control system.

The block diagram of Ripley' program looks like this:


Driver-Motor                 Drive-Steering         sonar hardware
      ^                             ^                     ^
      |                             |                     |
      | <- WeX ---------|           | <- WeX --- Collision Recovery
      |                 |__________ | _________________  task
      |                             |                     ^
      |                             |                     |
      -----------------------       |                    WeX
                            |       |                   ^   ^
 Wander Task -- Wthru ------>       |                  /     \
      |___________________ WThru --->                 / Bumper Switch
                            |       |                /  Detection task
                            |       |               /               |
                            |       |       Collision Detection     |
                           Forward Move            task             |
                               task                  |              V
                                                     |      bumper switches
                                                     V
                                              sonar hardware
legend:
WeX     - Write Exclusive connection
WThru   - Write Through connection
<--     - Write Normal connection, or hardware device control

There are 7 tasks, Drive-Motor, Drive-Steering, Forward-Move, 
Bumper-Switch-Detection, 
Collision-Detection, Collision-Recovery and Wander.

Drive-Motor and Drive-Steering controls the motion of the drive motor
and the direction of the steering servo respectively.
Drive-Motor sends the appropriate bits to the L293 TTL motor controller
chip based on the input message value. Drive-Steering controls the servo
position by generating the correct PWM (Pulse WIdth Modulation) signal.
Both of these tasks sleep until a message arrives for them.

Forward-Move wakes up periodically (~3 seconds) and makes sure the rover
travels straight forward by sending messages to the Drive-Motor and
Drive-Steering tasks.

Collision-Recovery waits for a message to arrive on its input port.
When it is awaken, it tries to recover (presumably because the rover
is stuck or colliding with another object) by
doing some computation and send the appropriate messages
to the Drive-Motor and Drive-Steering tasks.
Since it uses WRITE EXCLUSIVE connections
to the hardware driver tasks, it shuts out any other commands to them
(presumably from Forward-Move). This task uses a subroutine to choose
the best new direction to travel, which is defined to be the
direction with the largest distance to objects.

The tasks Bumper-Switch_Detection and Collision-Detection both detect
collision, or stuck situations. Bumper-Switch-Detection task wakes up
periodically (~1 sec) and check the status of the bumper switches. If
either is closed, it sends a message to Collision-Recovery for it to
take corrective action. Collision-Detection task also wakes up periodically
(~1 sec) and use the sonar to check distance to objects in front. If they
are too close, then it sends a message to Collision-Recovery for
it to take action. Both of these tasks use WRITE EXCLUSIVE connection
to Collision-Recovery so that Collision-Recovery will work on one
situation at a time.

Finally, the Wander task wakes up periodically (~20 secs) and calls the
same subroutine that Collision-Recovery uses to choose best new
direction to see if other direction of travel is better than
going straight forward. It uses WRITE THROUGH connection to Forward-Move
to bypass Forward-Move's actions.

--
- Richard F. Man (man@labrea.zko.dec.com)
"Small Rovers, Big Dreams"

