jkonrath@silver.ucs.indiana.edu (jon) (10/18/90)
Ok here's a discussion that may turn to war, but...
I'm a compsci major interested in the operating system side of things,
but I've been looking at ideas for my masters thesis (which isn't
for a while, but..)
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...
jon
-------------------------------------------------------------------------------
JKONRATH@silver.ucs.indiana.edu
if youre old fashioned (VMS) @rose.ucs.indiana.edu
if just plain archaic (prime) @sbway.iusb.indiana.edu
and if you can't even log in: 58319 Ironwood, Elkhart, IN 46516
disclaimer: these cannot be my thoughts, as someone still claims me on their
taxes: furthermore, all comments were an act of God: sue your church
-------------------------------------------------------------------------------kube@cs.UAlberta.CA (Ron Kube) (10/18/90)
There was an interesting paper in the IEEE Journal of Robotics & Automation about two years ago that described the need for a good standard programming environment with which to write robot control software (how's that for a verbose sentence?). It seems systems are being constantly re-invented. I think I remember reading that the FORTH language is commonly used in writing manipulator control systems. What about mobile robots?
mgsmith@hplabsb.HP.COM (Michael Smith) (10/18/90)
>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... I am a strong believer in standards. I feel that if you develop YARL (Yet Another Robot Language), you will follow the footsteps of many who have failed to have a significant impact. At Hewlett-Packard we have found robot languages have significant limitations so we do virtually all of our robot programming in C. You might therefore think that this is a good reason to develop a better robot language. The problem with this reasoning is that by the time you develop a better robot specific language, C will have also been improved. In the last few years for example, C++, Concurent C, and Saber-C have been introduced. There are great number of people working on standard languages such as C because the use of these languages is so widespread. The robot industry is relatively minuscule. Therefore I don't think that we will see a good robot specific language in the near future. This doesn't mean that there is no work to be done in computer science for robotics though. Robots continue to be difficult to use regardless of the language involved. Work needs to be done creating libraries for robot control using languages such as C and C++. Work also needs to be done in user-interfaces and databases for robotics. I think that effort concentrated on these subjects might actually reach fruition. I will be publishing a paper at the 1991 IEEE Conference on Robotics and Automation on what we are working on at Hewlett-Packard. This is 6 months from now so you out there in net-land will have to wait a while longer before you can fully denigrate our work. Mike Smith HP Labs
ericco@ssl.berkeley.edu (Eric C. Olson) (10/18/90)
I wrote some code for a gantry arm robot that now lives in LA. This is one of those "back in the old days" stories. The arm had 4DOF and a grip on the hand. The control language was BASIC! on an 8088 board. The language had a few extention words to do i/o to the controler. The machine had a whopping *64K* of memory, 32K of which was used by the *interpreter*. I did get it to work, but the interpreter was too slow. I had a hell of a time convincing the operators that they should buy the compiler. When they did buy it (several weeks *after* the installation) they were amazed that it was so much faster and that the timing in the code had to be re-written. BASIC was not good at all for robot control software. Too slow, too primitive. The only good idea was imbedding the controler commands directly into the language. Eric -- Eric ericco@ssl.berkeley.edu
hollombe@ttidca.TTI.COM (The Polymath) (10/19/90)
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
miller@intvax.UUCP (Dave Miller) (10/20/90)
At Sandia we have developed a Robot Independent Programming Environment (RIPE) which is object-oriented and implemented in C++ for Unix-based and VxWorks-based environments. If you are interested in obtaining further info on this, there is a paper describing the environment in the Proceedings 1990 IEEE International Conference on Robotics and Automation, or I can FAX or mail you a copy of the paper.
rob@innovus.UUCP (Rob Sciuk) (10/22/90)
In article <65275@iuvax.cs.indiana.edu> jkonrath@silver.ucs.indiana.edu (jon) writes: >Ok here's a discussion that may turn to war, but... [stuff deleted ... ] >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... [ stuff deleted ... ] Check out the group comp.lang.forth ... FORTH is a threaded interpreted language much faster than the average BASIC, can be embedded, extended and has a proven track record in the area of embedded controllers and robotics. The incremental compilation allows a LOAD & GO rather than EDIT, COMPILE, LINK DOWN-LOAD TEST EDIT ... cycle which will save eons of development time ... ( yes, I like it ... can you tell? ) rss.
unhd (Roger Gonzalez ) (10/24/90)
I was interested in implementing this idea for use on our EAVE AUV's, but the problem seems to be that many architectures (ours included) are heirarchical and the "robotic language" only is useful at one strata of the heirarchy, mainly for controlling the real-time low level areas of the vehicle. Since the management here at the lab thinks that the robotics aspects of our vehicle are old news, they are only interested in research related to "high level" things, like planning, data fusion for analysis, etc. (Mainly because its trendy and they know it can get funded.. Does this attitude exist everywhere, or are we the only ones coping with this.. This looks like a good topic for another article, so I'll continue discussion there.) What I'm trying to say is that its a great idea, and that there is interest in it in industry, but that it doesn't sell well 'cause its not big and flashy with neat graphics. If you can get the money to research it, go for it. -Roger (stay tuned for posting #2 on attitudes of management) -- "The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsgar W. Dijkstra rg@unhd.unh.edu | UNH Marine Systems Engineering Laboratory r_gonzalez@unhh.bitnet | Durham, NH 03824-3525
cb1p+@andrew.cmu.edu (Chris Beasley) (10/26/90)
Sorry to post this but I can't seem to route a repply to intvax.UUCP I am trying to find this paper but the latest copy of IEEE Rob. & Auto. here is the August. Which volume was this paper in? If Dave Miller is reading this, you can mail or fax me: louie!beez@sunpitt.east.sun.com Chris Beasley RedZone Robotics, Inc. 401 Bingham St. Pittsburgh, PA 15203 Voice: 412-481-5326 FAX: 412-481-8920 Thanx. B
mgsmith@hplabsb.HP.COM (Michael Smith) (10/30/90)
>Sorry to post this but I can't seem to route a repply to intvax.UUCP > >I am trying to find this paper but the latest copy of IEEE Rob. & Auto. >here is the August. Which volume was this paper in? > I believe you are looking for the proceedings of the 1990 IEEE International Conference on Robotics and Automation, not the IEEE Rob. & Auto. Journal. Page 352, volume 1 by the way. Mike Smith HP Labs