Path: 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 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