🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.robotics
Article #758

Re: robot control software

#758
From: The Polymath
Date: Thu, 18 Oct 1990 22:01
44 lines
2800 bytes
In article <65275@iuvax.cs.indiana.edu> jkonrath@silver.ucs.indiana.edu (jon) writes:

}I'm wondering what people use for interface with robots...I mean not
}the actual a/d stuff, but what languages, what type of communication.
}I think a worthwhile thesis would be a language that is modular enough
}to communicate with any interface you use/design, but doesnt require
}a mastery of C to get a robot to navigate...
}anyways, tell me what you use here, or email some stuff so I can
}get some ideas...

The robots I use (CRSPlus M1A) have their own language built into the
controllers.  It's called RAPL-II (Robot Application Programming Language,
I think) and is an odd cross between BASIC and C (mostly BASIC), optimized
for robot control, of course.  It consists mostly of special commands to
get the robot to do useful things.

The programs running on my host computer that talk to the robot controller
are written in C.  The controller has its own error free communication
protocol and comes with a library of C routines that can be used to talk
to it.  Alternatively (what I actually do) you can talk to the controller
through a terminal in interactive mode or have the host computer emulate
interactive terminal i/o.

Finally, since I need to do a limited set of things from my host, I
wrote my own custom library of routines to talk to the controller.  The
library is accessed through one master function, which is all the host
application program has access to.  Through that function it can ask
the robot to perform specific tasks, but has no knowledge of how the
request is passed to the controller or how the tasks are performed.

In summary, the host application decides what and when and passes the
request to the library routines that know how to talk to the robot
controller.  The controller decides if (sanity checking) and how.
ACKs, NAKs and status variables keep track of problems, if any.

If we switch to a different robot (as has happened once and may happen
again) only the communication library has to be altered.  The change will
be completely transparent to the application.

-- 
The Polymath (aka: Jerry Hollombe, M.A., CDP, aka: hollombe@ttidca.tti.com)
Head Robot Wrangler at Citicorp(+)TTI             Illegitimis non
3100 Ocean Park Blvd.   (213) 450-9111, x2483       Carborundum
Santa Monica, CA  90405 {csun | philabs | psivax}!ttidca!hollombe
Technical Details
Message-ID: <20608@ttidca.TTI.COM>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!wuarchive!usc!srhqla!quad1!ttidca!hollombe
References: <65275@iuvax.cs.indiana.edu>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!wuarchive!usc!srhqla!quad1!ttidca!hollombe
From: hollombe@ttidca.TTI.COM (The Polymath)
Newsgroups: comp.robotics
Subject: Re: robot control software
Message-ID: <20608@ttidca.TTI.COM>
Date: 18 Oct 90 22:01:15 GMT
References: <65275@iuvax.cs.indiana.edu>
Organization: The Cat Factory
Lines: 44