The Robotic Competition Framework Chuck McManis August 1994 1.0 Introduction and Purpose The Robotic Competition Framework (RCF) is designed to provide the basis for standardized competitions between autonomous robots. The most significant requirement for the framework is that it should always give the advantage to the more "capable" robot. This means robots with bet- ter sensors should do better than robots with poorer sensors and robots with sophisticated software should do better than robots programmed with simplistic algorithms. The second requirement is that the environment should be adaptable to a wide variety of contests on relatively short notice and yet sufficiently simple that competitors should be able to build their own version for testing. Finally the framework should rich enough to allow for a wide range of complexity. It must be pos- sible to construct competitions that high school students would be successful competing in as well as being able to create contests appropriate for post graduate robotics researchers. 2.0 The Arena 2.1 Floorplan The arena for the competitions is defined to be a rectangle that is 3l units tall by 5l units wide. The constant value l takes on different values depending on the class of robots participating. I expect the "standard" value to be 60 centimeters (approximately 24"). Doorways are proposed to by .75l wide or 45 centimeters. Robots in the arena are expected to fit within a box that is .6l X .6l. FIGURE 1. Top view of the arena area. The three bonus rooms have three removable sides, one of which may be removed during a con- test. This is to add an interesting place to navigate to without preplanning on the part of the algo- rithm designer. Each of the target, but not the bonus rooms have rings on their floor that subdivides them into quarters and four three concentric rings. This is designed to support goals that include not only the target room, but a specific place within the target room. As designed, if a robot can sense the center of the target room it can navigate to any of the goal regions by dead reckoning. 2.2 Tokens - things to get In many contests the Arena is populated by tokens. These represent the "things" that a robot must use to accomplish its "task". Tokens are physically constructed of closed cell foam and have four attributes. These attributes are listed in the table below. The requirement for token attributes are that each should be orthogonal from the rest and there should be sufficient diversity to inspire cre- ative sensor design. TABLE 1. Possible values of token attributes Shape Size Weight Color ------------------------------- Sphere Small Light Red Cube Medium Medium White Pyramid Large Heavy Blue Note that all of the attributes are divided into three values so that the goal regions of the target rooms may be used for sorting. 2.3 Navigation Support Within the Arena Each of the target rooms' rear panel will be of a unique color. The potential colors are red, white, and blue. The colors red and blue were chosen for their separation in the visible light spectrum. It is believed that a red sensor will detect only red, blue only blue, and either will detect white. Addi- tionally the Bonus rooms may have a color associated with them, if they do that color will be shown on the panel that is part of the external wall of the arena. 3.0 Contest Design As I mentioned before it is hoped that a wide variety of contests could be supported in this frame- work. In this section I outline several that I have thought of with an estimate of their difficulty in achieving. Some have natural difficulty variables, an example of this is shown in the first one. 3.1 Go Fetch This is probably the simplest contest that can be constructed that is also challenging enough to pre- vent some of the simpler algorithms from prevailing. The rules of this contest are simple, find the token and return it to a target room. The following could be used as a complexity enhancer: o The arena has many tokens, find one and return it to any target room. o The arena has exactly one token, find it and return it to any target room. o The arena as many tokens, find one and return it to the red target room. o The arena has many tokens, find one and return it to the target room that matches the color of the token. 3.2 Token Collector Given an arena with two competing robots running simultaneously, get more tokens than your opponent your target room. All of the same complexity enhancers that are available to "Go Fetch" above are available here, some examples: o Collect only red tokens o Collect only tokens where is one of the attribute/values. o Bonus points for stealing your opponent's tokens. 3.3 Robot Sorter This contest would be based on a robot's ability to discriminate tokens and to navigate into target rooms. This could be the most complicated of the contests available in this frame work. The basic rules would be to collect tokens and sort them by attribute into the three target rooms. Basic points would be awarded by a single level sort (i.e. cubes in one room, spheres in another, and pyramids in the third room) and bonus points by sorting on a second attribute such as large spheres on the left, medium spheres in the middle, and small spheres on the right. More bonus points for an even finer grain sort, maximum points for sorting over all attributes. 3.4 Robot Assembler This contest would closely model a real world process where a robot would be given a "parts" list and a target room and it would have to assemble the parts into the target room. This list would con- sist of token descriptions and quantities. Clearly different parts lists would make for harder or eas- ier problems. 3.5 Robot Analyst This incredibly difficult contest would put one token in each target room, the contestant's robot would have to identify the token in each room and the attribute that was unique between the tokens in the three rooms. It would then be required tokens with the appropriate attribute and put them into correct target room. For example the target rooms might each have a sphere in them of the same size but different weights. The robot would identify that the attribute they were sorted on was weight and put all of the heavy tokens in the heavy room, all of the medium tokens in the medium room, and all of the light tokens in the light room.