August 1993 issue of The DPRG Newsletter

Contest Update

At the July meeting, many members came together to cuss and discuss the robot contest rules and regulations. If you have the June 93 newsletter, the contest proposal was submitted. The first issue raised was the idea of a point system. This would allow a robot that was slow for example to accumulate points for accuracy for some other strength to compete better with units that just had lightning speed. Extra points would be given for units that actually turned around instead of just reversed, or never touched the wall, or sang happy birthday, etc. This is a great idea but we fell short of agreeing HOW this system would be implemented. We all did agree that the starting and ending area (see the diagram in the June issue) would be increated to at least 5 feet for those of us with refrigerator-sized monsters. Members also thought prizes sounded dumb. I do think we'll keep the 'Bucket of Bolts' Award for last place. We'll try to finalize these issues at the August meeting. The final contest guidelines will be published in an upcoming newsletter.

Local Vendors

Many of you know local manufacturers of hardware and software that is of interest to robot builders. The Dallas-Fort Worth area is packed full of companies that make controllers, sensors, compilers, etc. If you know someone that works at one of these companies ask them if they would be interested in giving a short demo (30 min) of their product to the club at one of our meetings.

August Meeting Events

The August meeting will be on Saturday the 21th 1:30pm at the Dallas INFOMART. The summer months tend to be slow and no one has told me what they are working on or plan to bring. I'm sure Tom will have some new 'Thing' to show us on his mobile platform. Steve may bring his 4-wheel-drive base and Bud may bring his new creation that we heard about. But this is a lot of 'may's, you neet to show up at the meeting in flesh and check out what actually appears. There are plent of Motorola data books, 8051 data books and LCD data books left that were given out at previous meetings. So stop by and see what's happening.

President's Note

Hello fellow robot enthusiast. We've had such an unusually long time span between meetings because of the Infomart schedule that I almost forgot what a robot was. I was reminded, however, by an article in "Midnight Engineering" magazine entitled 'Personal Robotics' by Robert Nancel. This is a very interesting article (must read, test on Friday) which discusses the history, the failures, and the potential successes of 'personal robots'. The DPRG was even mentioned! This magazine is one of the only ones I like enough to actually subscribe to. It's full of interesting articles about high-tech developers (as the name suggests). It's a steal at $19.95, contact them at 1700 Washington Ave., Rocky Ford, CO 81067-9900. I'll bring my copy to the August meeting, see you there! - Roger Arrick.

Why Build a Robot, Anyway?, Part I

by Steve Rainwater
Construct a robot? No problem. Sounds simple enough. No doubt Cheops' chief engineer had similar thoughts - "Construct a pyramid-shaped building out of rocks? Gee, no problem." No doubt the pyramid's builders, like myself, soon realized that the difficulty lay in the wording of the eorginal proposition. Had the Pharaoh said, "Construct a 482 foot high, pyramid shaped, solid mass of limestone blocks, covering 13 acres." the response might have been different. Had I thought the initial proposition was actually to build an autonomous, intelligent, mobile robot capable of sustained, goal-oriented behavior, I might not have jumped into it as quickly. On the other hand, most of the complexity of the project has been added by my own design decisions. Perhaps I should explain before I go any further.

I am the System Operator of the Interocitor BBS, a BBS which is oriented towards AI, Robotics, and other advanced machine technologies. Early in 1993, I was looking for ways to increase the local user base and thereby, the overall message traffic on the board. At approximately the same time, Roger Arrick, president of the Dallas Personal Robotics Group approached me about the possibility of making the Interocitor the official BBS of the DPRG. They had, it seems, decided a BBS would be helpful in recruiting new members and generally increasing interest in their group. It was a perfect match of interests and as a result, I began attending the monthly DPRG meetings.

The problem with attending meetings where people demonstrate and talk about their latest robotic experiments is, of course, that it generates the desire in the listener to do some experimenting of his own. Roger expressed an interest in my building a simple robot platform in order to do demonstrations of some of the AI techniques that constantly show up in the software uploaded to my BBS. Eventually, I gave in to the pressures from within and without to embark on this project.

I decided to record my experiences in a series of short articles in the hopes that other brave experimenters might follow in my path and, hopefully, avoid my mistakes. A further consideration in writing these articles was to satisfy Roger's frequent request that some member of the DPRG other than himself write something for the newsletter.

The Basic Design Goals
The design goals for my project sounded simple: construct a mobile robotics platform equipped with a variety of sensors and effectors for use in the development of a hardware independent robotics control system. The software itself would be the end product and would determine the success or failure of the project. Unfortunately, things became a bit more complex when I sat down and actually began writing some specifications. In order to make things simpler, I divided the goals up into three general categories: the platform itself, the sensors, and the controlling software. Some categories I have further divided into two subcategories: minimum and ideal achievement. It should be noted that behind all these goals lies an unspoken restriction. Time and money are finite resources which must be traded against one another and conserved wherever possible.

The Platform
In general, this is the least important part of the project. Its sole purpose is to provide the means by which I can develop and test the software. In reality, it does need to meet a number of requirements in order to be useful. The goals chosen for the platform, with explanations, are as follows:

GOAL 1: The platform must be small enough and light enough to be transported by one person without special equipment such as a dolly (or a fork lift!). Ideally, this would mean less than one cubic foot and less than 40 pounds. At a minimum, it means small enough to fit through the average doorway and less than 100 pounds.
GOAL 2: The platform must be able to move at a reasonable speed and be self-sustaining for a reasonable amount of time. Ideally, speeds equal to or exceeding those of a running human and a run time of greater than an hour. At a minimum, the speed of a walking human and a run time of 15 minutes would be acceptable.

The Sensors
The sensors are a critical part of the design because they will determine the ease with which the software will be able to gather information about the robot's environment. Someone who is blind and deaf may be able to understand the concept of a map, but is going to have a much harder time learning to navigate than a someone who has the advantage of sight and hearing.

GOAL 1: Some sort of active or passive sensor(s) that will facilitate basic navigation. Ideally, the capability to sense direction and distance to all surrounding surfaces to a distance of 35-40 feet, in near real time. At a minimum, the ability to use a sensor, or combination of sensors, to determine direction and distance to a surface in a selected direction.
GOAL 2: Some sort of active or passive sensor(s) that will facilitate basic collision avoidance - ideally, the capability to sense impending contact with an object at a distance of greater than the maximum stopping distance of the platform. At a minimum, the ability to sense contact with an object in any horizontal direction.

The Software
The primary focus of this project is the creation of a hardware independent, AI-based, control system that can be easily expanded to operate on robotic platforms of any type with any assortment of sensors. No minimum goals are expressed here. Any failure to achieve the ideal goal will constitute either a bug or an unfinished portion of the software.

GOAL 1: The software must provide for basic reflex acitons to protect the robot from harm by outside agents and to protect outside agents from being harmed by the robot during routine activities. Ideally, this would involve the invocation of "instinctive" responses to predictable stimuli. These responses would be available for examination, modification or suppression by the higher level functions of the AI.
GOAL 2: The software should provide a short-term, sensory memory in the form of a "stream of consciousness" which will provide both real time and short-term, historical data to the higher level functions of the AI about sensory, reflex, and introspective events.
GOAL 3: The highest level software will provide self-directing, goal oriented behavior, a small level of self-awareness, and a long term memory of selected events. The resulting intelligence will be very basic but adequate for solving navigational and survival related problems.

Conclusion
The majority of my time and effort will be directed towards the software side of the design. The hardware design and construction, for the most part, will be a mistake-filled learning experience (which will probably make it more fun to read about). As each of the three stages of the project is completed. I will be writing a more detailed article describing how it worked out. The subject of the next installment will be the platform and associated hardware. If all goes well, I will finish the project in somewhat less time than the Eqyptians took to construct the pyramids.