Using Base 36 "Compression" For Easier Scouting and Other Interesting Tidbits

[Adrian Wong]

As a rookie, I do not know if this has been attempted in the past. However, I believe it is a sound idea and should be discussed. Thus, I am writing it up for the ChiefDelphi board community to see. The ideas I state are based upon what I have seen during my limited time (one year) as a FIRST team member, so please correct me if I am wrong. I'd appreciate your feedback and opinions as to how receptive FIRST teams would be to this method of scouting.

Scouting

FIRST scouting usually comes in two forms. The pre-competition format usually consists of teams trading information about their robot through mediums such as web forms and databases. Information is stored prior to a competition date and can be retrieved at any time, through the web or locally on a computer. The benefits of this are speed and convenience. Possible drawbacks of this method is the timeliness and accuracy of the information as well as missing information where teams have not chosen or were unable to participate.

The second method is scouting at a competition. Teams go about the pit area asking for information on robots and recording it on computers or papers. This provides more accurate reporting (in most cases) and the data is as up-to-date as possible. However, scouting all the teams is a time-intensive task and extremely repetitive.

A Scouting Interview

The point of gathering these scout reports are understand its abilities as well as to gauge how well a robot may perform. To get this information, a series of objective questions about the robot. Basic statements of ability are the standard fare. Occasionally, an improperly phrased question can turn an objective question into a subjective question, such as "how fast can your robot move". Unless one has a measurement of speed of their robot, it's hard to answer this question factually. However, I'm getting off track.

The answers to these questions are usually yes or no. In fact, the majority of the questions asked are in this format. To use last year's competition as an example:

• Can your robot go over the bridge?
• Can your robot go under the barrier?
• Can your robot go over the barrier?
• Can your robot pick up small balls?
• Can your robot pick up large balls?

Some questions, while more complex, can be broken down to produce a yes or no answer.

• Can your robot balance the bridge with one goal while on the bridge?
• Can your robot balance the bridge with one goal while off the bridge?
• Can your robot balance the bridge with two goals while on the bridge?
• Can your robot balance the bridge with two goals while off the bridge?

What is left are usually unique questions such as "what does your robot do best" or "rate the speed of your ball pickup". The latter answer can be represented as a number from one to ten. As for the former question, that is out of the scope of this little project.

Base 36 Compression/Conversion

Yes or no answers can be represented by the digits one and zero. As most of you know, this is called binary or base 2. A number from one to ten can also be represented in binary, as we will address later. So, in effect, we can convert all the answers to the above questions to a long string of ones and zeros.

What advantage does this give us? None at the moment. It'd be extremely inconvenient to use that string of ones and zeros as a unique "model number" for your robot.

However, what if we made it "shorter"? Let's convert the answers to the above questions from base 2 to base 36. To recap, the questions were (with three additions):

• Can your robot go over the bridge?
• Can your robot go under the barrier?
• Can your robot go over the barrier?
• Can your robot pick up small balls?
• Can your robot pick up large balls?
• Can your robot balance the bridge with one goal while on the bridge?
• Can your robot balance the bridge with one goal while off the bridge?
• Can your robot balance the bridge with two goals while on the bridge?
• Can your robot balance the bridge with two goals while off the bridge?
• Rate your speed from one to ten.
• Can you wedge under the bridge?
• Can you tow one goal?
• Can you tow two goals?

Using the answers from my team's robot this year as an example, the output would be:

100110000(9)100

If we convert the speed ranking to binary, the end result is 1001100001010100.

What an unwieldy string of numbers. Let's convert it to something more manageable. We could convert to base 10, but let's go further. If we include letters as a valid "digit", we can shorten the string even more. If we include lowercase letters, the base goes up to 62. However, I believe that converting to base 62 becomes troublesome (confusion between lowercase and uppercase letters). So, going with a conversion to base 36:

1001100001010100 (Base 2)
U38 (Base 36)

Wow! Isn't that great? We have managed to answer 13 questions with just three letters: U38.

Convenience

Base converters are extremely easy to write programs. One can easily be developed as a standalone application, or it can be written into one of the scouting applications already available. The smart ones will even split the information up to appropriate fields.

With a method like this, a new number format could be released each year and adapted to the corresponding questions. For those teams that don't like to keep their scouting records in the computer and prefer to have a paper copy, a standalone application can write out the "Question / Answer" to the screen or a printer.

If enough teams generate a "Robot Scouting Code" for their robot to bring with them to a competition (you can easily remember something such as U38, right?), other teams when doing their scouting can ask "Do you have a RSC for your robot?" and easily get an answer to thirteen questions in the time of one. Or for the paper-based teams, they can write it down and when they go back to home base, convert them on the fly.

Scouting time is reduced and you can get to more teams. In fact, an unexpected side effect of this may be a standard set of information that the different scouting programs can agree on. (You can include many more fields for such a product code, with those teams not using that field just discarding the superfluous bits.)

Standardization, I love it.