I am just a hobbyist with a question
I am looking at lisp to run a autonomous robot in a unix environment and
want to know it this is a wrong move (my previous background is lisp
routines for Autocad and I am a designer not a engineer.)
It is not a bad move, as Lisp is often used to control robots and
sometimes spacecraft:
http://www.harlequin.com/news/press/devtools_0899_1.html
Also, your Autolisp background helps a lot.
Is your robot going to do unix sysadmin work? :-)
Robert
David Whitacre wrote:
>
> I am just a hobbyist with a question
> I am looking at lisp to run a autonomous robot in a unix environment and
> want to know it this is a wrong move (my previous background is lisp
> routines for Autocad and I am a designer not a engineer.)
When you say Real-Time response what time frame are you using ???
milliseconds ?? seconds ??? My robots limbs are solid-state so have a somewhat
slow movement rate but very high possibilities on possible positions of the
tentacle arm it's self.
"Howard R. Stearns" wrote:
> Check out ISRobotics, I think at at http://www.isrobotics.com. (search
> for it if necessarry, or call them. They were at 617-629-0055 several
> years ago, or you can reach Professor Rod Brooks through M.I.T.)
>
> They make a Lisp system for embedded robotic systems.
>
> You will have to take a look at your real-time response requirements.
> Although there may be issues with Lisp garbage collection, you might
> have even more problems with Unix (unless you are planning to use some
> sort of realtime Unix variant).
>
> David Whitacre wrote:
> >
> > I am just a hobbyist with a question
> > I am looking at lisp to run a autonomous robot in a unix environment and
> > want to know it this is a wrong move (my previous background is lisp
> > routines for Autocad and I am a designer not a engineer.)
You might consider Forth to embed Mind.Forth PD AI in your robot.
David Whitacre, ·········@appworx.com, wrote on Fri, 27 Aug 1999:
> When you say Real-Time response what time frame are you using ???
> milliseconds ?? seconds ??? My robots limbs are solid-state so
> have a somewhat slow movement rate but very high possibilities
> on possible positions of the tentacle arm it's self.
>"Howard R. Stearns" wrote:
>> Check out ISRobotics, I think at at http://www.isrobotics.com .
>> (search for it if necessarry, or call them. They were at
>> 617-629-0055 several years ago, or you can reach Professor
>> Rod Brooks through M.I.T.)
>>
>> They make a Lisp system for embedded robotic systems.
>>
>> You will have to take a look at your real-time response requirements.
>> Although there may be issues with Lisp garbage collection, you might
>> have even more problems with Unix (unless you are planning to use some
>> sort of realtime Unix variant).
>>
>> David Whitacre wrote:
>> >
>> > I am just a hobbyist with a question
>> > I am looking at lisp to run a autonomous robot in a unix
>> > environment and want to know it this is a wrong move
No, but a better move might be to learn Forth by starting with
http://Landau1.phys.virginia.edu/classes/551/primer.txt "A Beginner's
Guide to Forth," then download and adapt for your own purposes the
http://www.geocities.com/Athens/Agora/7256/mind-fpc.html PD AI code.
>> > (my previous background is lisp routines for Autocad
>> > and I am a designer not a engineer.)
David Whitacre wrote:
>
> When you say Real-Time response what time frame are you using ???
> milliseconds ?? seconds ??? My robots limbs are solid-state so have a somewhat
> slow movement rate but very high possibilities on possible positions of the
> tentacle arm it's self.
That's the point, you will have to work out the scale of real time
requirements.
In the case of Unix (and nothing to do with Lisp):
Standard (non-"real-time") Unix variations might or might not guarantee
that a particular process gets run at a sufficiently high rate, or that
that some thread within a process gets run at a sufficiently high rate,
or that some timed activity (e.g., an alarm) will occur at some specific
time within a sufficiently tight precision. For example, alarms might
be precise only to within one second.
In the case of Lisp:
If your operating system gives you what you need, you may or may not
need to worry about the details of threads within your Lisp, or any
non-running conditions during, for example, garbage collection.
Figure out your needs, then figure out if your implementation can meet
those needs. It may or may NOT be a problem.
I believe that the ISRobotics approach is to treat the Lisp program as
embedded software in the robot -- there is no outside operating system.
(The world's tiniest Lisp machine???) Embedded Forth systems presumably
take a similar approach.
>
> "Howard R. Stearns" wrote:
>
> > Check out ISRobotics, I think at at http://www.isrobotics.com. (search
> > for it if necessarry, or call them. They were at 617-629-0055 several
> > years ago, or you can reach Professor Rod Brooks through M.I.T.)
> >
> > They make a Lisp system for embedded robotic systems.
> >
> > You will have to take a look at your real-time response requirements.
> > Although there may be issues with Lisp garbage collection, you might
> > have even more problems with Unix (unless you are planning to use some
> > sort of realtime Unix variant).
> >
> > David Whitacre wrote:
> > >
> > > I am just a hobbyist with a question
> > > I am looking at lisp to run a autonomous robot in a unix environment and
> > > want to know it this is a wrong move (my previous background is lisp
> > > routines for Autocad and I am a designer not a engineer.)
What is Embedded Forth and how much different is it from lisp ??
By Embedded do you mean that the code is hardwired in the machine as with
EPROM's???
as this is still mainly test and experimentation I do not think speed is a worry
yet.
first it needs to move then I will get it to move at a proper speed.
"Howard R. Stearns" wrote:
>
> That's the point, you will have to work out the scale of real time
> requirements.
>
> In the case of Unix (and nothing to do with Lisp):
> Standard (non-"real-time") Unix variations might or might not guarantee
> that a particular process gets run at a sufficiently high rate, or that
> that some thread within a process gets run at a sufficiently high rate,
> or that some timed activity (e.g., an alarm) will occur at some specific
> time within a sufficiently tight precision. For example, alarms might
> be precise only to within one second.
>
> In the case of Lisp:
> If your operating system gives you what you need, you may or may not
> need to worry about the details of threads within your Lisp, or any
> non-running conditions during, for example, garbage collection.
>
> Figure out your needs, then figure out if your implementation can meet
> those needs. It may or may NOT be a problem.
>
> I believe that the ISRobotics approach is to treat the Lisp program as
> embedded software in the robot -- there is no outside operating system.
> (The world's tiniest Lisp machine???) Embedded Forth systems presumably
> take a similar approach.
>
>
On Wed, 01 Sep 1999 11:33:54 -0700, David Whitacre wrote:
>What is Embedded Forth and how much different is it from lisp ??
I'm sure he means Forth running on an embedded system. Forth is like Lisp
in that it's utterly protean; the coder can shape the language to his
needs nearly effortlessly. It's also (naturally) syntacically minimal;
more so than any Lisp, since it executes strictly left to right, with no
parenthesis or syntactic operators except for 'immediate' words (like
defmacros).
Forth is unlike Lisp in that it has no GC, no parsing, very limited memory
management, is based on a pair of stacks for parameter passing rather than
lexically scoped variables... In short, Forth is generally built on a
philosophy of minimalism in the runtime.
It's a good language, and I like it a lot. It learned a lot from Lisp in
its early growth (always a good thing).
>By Embedded do you mean that the code is hardwired in the machine as with
>EPROM's???
No -- an embedded system is generally a computer you don't see because
it's part of something more important. For example, the computer in your
car is embedded. Embedded systems are generally very small, since they
aren't a primary part of the product.
Developing for embedded systems usually involves writing your code on a
development computer, and uploading it to the embedded system for testing
and sometimes debugging. Thanks to Forth's philosophy of minimalism, more
functionality can be placed on the embedded system.
--
-William "Billy" Tanksley