EAJUAN@TOP.UPC.ES (11/20/89)
At our Institute we have lots of headaches trying to tackle real time
applications with a SUN 4/260 (SunOS 4.0.1, 32 Mb main memory) and I would
greatly appreciate that somebody gave me a clue about how to solve them.
Our main problem is the following one : we have a PUMA 560 robot (with a
MK-II controller) connected through a serial line to the Sun workstation.
To maintain the dialogue with the robot we must make sure that the host
will answer the messages sent by the robot controller (each 28 ms.) before
receiving the following message (that is, within the next 28 ms.). We
have tried working with the Sun as single user, raising the priority of
the process, etc... but it seems that there is no way of making sure that
the workstation will answer the message of the controller within the
alloted time. In fact, the program maintains the dialogue during a
variable number of intervals. Then, it fails to answer within the 28 ms.
period and the communication is broken.
Has anybody some idea about how to guarantee an answer of the workstation
within a given time period ?
Thanks in advance and best regards from Spain.
Joan Ilari i Valenti EAJUAN%EBRUPC51.BITNET@CUNYVM.CUNY.EDU
Assoc. Professor EAJUAN%TOP.UPC.ES@CUNYVM.CUNY.EDUsxm@philabs.philips.com (Sandeep Mehta) (12/03/89)
In article <3299@brazos.Rice.edu>, EAJUAN@TOP writes: >Our main problem is the following one : we have a PUMA 560 robot (with a >MK-II controller) connected through a serial line to the Sun workstation. >To maintain the dialogue with the robot we must make sure that the host >will answer the messages sent by the robot controller (each 28 ms.) before >receiving the following message (that is, within the next 28 ms.). We >have tried working with the Sun as single user, raising the priority of >the process, etc... but it seems that there is no way of making sure that >the workstation will answer the message of the controller within the >alloted time. In fact, the program maintains the dialogue during a >variable number of intervals. Then, it fails to answer within the 28 ms. >period and the communication is broken. > >Has anybody some idea about how to guarantee an answer of the workstation >within a given time period ? > We control our PUMA using Sun 3/160s. The main difference is that we don't rely on Sun/SunOS for anything real-time -- the usual UNIX and real-time are mutually exclusive scenario :-). We have a VME cage memory mapped into the Sun. The VME cage has numerous 68020 single board computers and 8 Mb of common memory on the bus. There is a run-time library that provide all the (UNIX like) primitives necessary for writing real-time applications on the multiprocessor cage. We talk to the PUMA via the sbc's serial (RS-232/422) port which is connected to the VAL controller. We are planning on running some timing experiments to determine a bound on how fast a real-time OS on the VME cage should run for smooth control of the PUMA. The r-t OS is currently under implementation. I know my answer hasn't really addressed your problem but I think by stressing the inability of UNIX to handle "true" real-time in the robotics domain I've tried to address the root of your problem. Given the vanilla UNIX environment, particularly the stock SunOS scheduler I don't know if you can ever guarantee meeting *hard* deadlines reliably. sandeep sxm@philabs.philips.com uunet!philabs!bebop!sxm ...to be or not to bop ?
EAJUAN@TOP.UPC.ES (12/04/89)
I have received several e-mails from different people all around the net,
all of them pointing out the unfeasibility of our approach and suggesting
alternatives to do what we are trying to do :
=1= Ladson Hayes (AP08@PRIMEA.DUNDEE.AC.UK) suggests using a PC-front end
to maintain the dialogue with the robot and then feeding the data
into the Sun via PC-NFS.
=2= David B. Stewart (David.B.Stewart@FAS.RI.CMU.EDU) suggests using
a M68020 single board computer (~5000$) in the VME backplane, running a
real time OS (CHIMERA~II) developed in its lab, allowing the control
of several processors.
=3= Bo Thide' (bt@irfu.SE) suggests using a HP9000 station with HP-UX,
a UNIX version with real time capabilities and "hammer on Sun to make
rewrite their UNIX kernel so it can support Real Time Unix".
=4= Charles ??? (unisoft!cander@ucbvax.Berkeley.EDU) pointed out the
possibility of using a real time system running on Sun and distributed
by Wind River Systems (Emeryville, California) which, even if it is not
UNIX, it has a lot of Unix features. (--> VxWorks ??)
=5= Dan Messinger (dan@rose3.Rosemount.COM) suggests adding a Mizar MZ 7170
board --a SPARC based processor made to run real time applications-- to
the Sun, with VxWorks OS (Wind River).
=6= ?? (rowan@quandary.Central.Sun.COM) suggests using a real time single
board computer such as the Heurikron to do the time-critical stuff,
passing summary event information to the Sun host via some kind of bus
technology.
=7= ?? (buky@cs.rochester.EDU) faced the same problem as us and they tackled
it by making use of INTERNAL ALTER instead of EXTERNAL ALTER (this is
PUMA jargon), that is, facing the problem from a more affordable
perspective which does not involve the time critical requirements of
the original problem.
=8= Jean-Christophe Kougoyan (sun!sunehq!sunfra!jckougo), Support Engineer
of Sun in France confirmed me the non-appropriateness of SunOS to this
kind of work.
=9= Elliott McCrory (mccrory@mdtf05.fnal.GOV) suggests using real time
Unix workstations and cites two of them : Concurrent (formerly
Masscomp) and HP. He has tried a Concurrent WS which seems to
be able to guarantee an average response time of 2 to 3 ms.
=10= Alistair Conkie (adc@edai.ed.ac.UK) sent me the reference of two
works somewhat related to the real time control problem of robots
from Unix :
Robot Manipulator Control under Unix - RCCL: A Robot Control "C" Library
By: Vincent Hayward, Richard Paul
In: The International Journal of Robotics Research v5n4 (1986)
and
Implementation of a robot control development environment
By: Lloyd, J.
In: M.Eng. thesis, McGill University, Dept of Electrical Eng. (1985)
In the first one of them, "...they use a PUMA 600 and talk about modifying
Unix (on a VAX) to provide real time control, but in a rather general way,
as follows: the control software is executed in kernel mode at elevated
priority. A special locking mechanism and linking procedure for keeping the
control software in real memory were developed..."
I wish to sincerely thank all these people for their helpful suggestions.
After evaluating all their answers, what we shall do will be to compare
the performance of the system 1) when using the INTERNAL ALTER approach
suggested by =7= and 2) when using a microcomputer as front end for
guaranteing the dialogue with the robot controller, and then using the
most performant of both approaches.
Joan Ilari i Valenti EAJUAN%EBRUPC51.BITNET@CUNYVM.CUNY.EDU
Assoc. Professor EAJUAN%TOP.UPC.ES@CUNYVM.CUNY.EDU
Institut de Cibernetica
(Universitat Politecnica de Catalunya-
Consejo Superior de Investigaciones Cientificas)
Diagonal 647, Barcelona 08028, Spain
Tel: +34 3 249.28.42