Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!cbnewse!cwpjr
From: cwpjr@cbnewse.att.com (clyde.w.jr.phillips)
Newsgroups: comp.robotics
Subject: Re: "Easy" way to put "AI" in realtime embedded systems?
Summary: Vouch For Forth
Message-ID: <1991Apr16.155547.7638@cbnewse.att.com>
Date: 16 Apr 91 15:55:47 GMT
References: <5478@mindlink.UUCP>
Distribution: na
Organization: AT&T Bell Laboratories
Lines: 29

In article <5478@mindlink.UUCP>, Nick_Janow@mindlink.UUCP (Nick Janow) writes:
> Forth might be a good choice for adding AI to embedded systems.  Forth is
> widely used in embedded systems, and is also used in robotics and AI research.
> Using Forth for all parts of the project would save time, money, system
> resources and complexity compared with using, say, C for one part and Lisp for
> the AI.

Having done sensor based mobile platforms, Conveyor/changer mechanisms,
motion controls/incl ramp/dampnimg, and numerous other projects in FORTH
i can vouch for the claims made above. I've done so many projects
that relied on closing reality loops that without the interactive
real-time nature of FORTH I'd have done less than half half as well.

I let engineering guideline guide my selection and have done
some "simple" embedded controls with PC SBC's in Tubo C, but
that is the only decent alternative and matches only a narrow
range of embedded applications. It sure isn't as easy to
determine what's wrong in the C/PC environment,
but then again without a strong grounding in engineering
using FORTH can be just as hard.

FORTH as a language to *use* is really easy, but embedded
systems are not so easy and the overhead of a compiler-universe
can be another not so easy realm that complicates the solution of
embedded control realm products. This can be a classic engineering mistake.

Since it costs me I don't do it often. 8^)

Clyde