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.

[Kyle Fenton]

Scouting before the competition is highly inaccurate and most likely just a waste of time. I tried one but it failed because it was too much work. And plus robots could change performance and configurations during the time they ship to the time they come to the competition field. The best way to Scout is to go out on practice day and look at all the teams. But don't judge a book by its cover, just because it is not working, doesn't mean it won't be good for the next day. I mean heck, we have nothing else to do during practice day, why waste time before hand.

For nationals, get the robots you are going to compete with first, and keep your eye out for people who may want to bring you in for the finals or getting picked for the finals.

[Mike S.]

Adrian,
Interesting idea, i thought it was funny because it reminds me of one of my math teachers. It would be a great system. I was just wondering, what if someone accidently converted wrong or something happend and then came out with the wrong conversion?

On my team, we use field and pit scouting, when we scout field wise we don't ask questions, but in the pit we do, using a simple guide (that everyone can handle, no conversions or binary) and we go through the whole national pit in a day and our strategy/scouting team has never let us down.

just my thoughts
-mike

[Adrian Wong]

There was one more that I didn't mention. I had an idea that we could use a checksum similar to a credit card checksum. This could be a digit tacked onto the end of the code just to make sure it isn't written down incorrectly. Hopefully, no one would write down four letters incorrectly.

[Tom Schindler]

I'm not sure what the point of this would be, unless you have very very limited space. What the bobcats do is we have 4 or 5 palm pilots that we set some students loose with loaded with a program that allows us to input directly into a microsoft Access database. It is called Pendragon Forms, http://www.pendragon-software.com/

Since the records are only stored on the palm pilots and computers, we have no need for compression of teh data. We tried an algorithm like that, but it got too confusing for even the people who designed it to work with, so it was never implemented.

[Adrian Wong]

This was meant more for the methods of scouting, not the storage. I just thought that it would be easier for both the scouter and the scouted to have an agreed upon method of exchanging information that would be quicker than drilling through a list of questions.

With the reception it's receivd, I'm thinking it would be too abstract and difficult to adopt to gain acceptance.

[Tom Fairchild]

Just want to give a big Amen for PenDragon Forms. I was incharge of setting the Palms this year (the first year that we have ever used them) and PenDragon was a breeze to use. Along with some digital camaras that plugged into the top of our Handspring Visors, we were good to go for scouting!

~Tom Fairchild~, who was gald 166 had such good scouting and found us (122)!!

[Wetzel]

From my experience last year scouting at nationals.
A agree with you on the objective/subjective questions.
Some of what we did was to have 4 people at (most) every match to watch one of the teams. They would sit and watch 4-5 or more matches, and runners took the papers to our ‘command post’ out in the food. This data was then manually transferred to a laptop database. This is a fairly mind numbing task, data entry, and I like the idea of the Palm program. How easy was it to use. As in make a customized data table?
The paper was nice though, because we kept it all in a binder in order (a big one). So when there where major discrepancies, we could pull the paper and compare them. Sometimes we paid more attention to one or another because of who did which one.

But over all, depending on how flexible the Penddragon software is, it may be something to use. We already used a Palm program during matches to keep score, and I think we could rustle up a couple of palms...

Practicing sleep depravation now, for when January comes....

[Mike Soukup]

When I started looking around for good Palm programs to use for WASH scouting last year, I found Pendragon and thought it looked excellent. But then I saw the price. Because we wanted to let other teams use our software, we needed something free. So we used HanDBase. We bought the licensed software ($30 or so) for development and handed out the trial version to other teams who scouted with us. It required extra effort to get the data in our database and to avoid conflicts or duplicate data, but it was a great project for 2 students and myself to work on.

Hopefully we'll get rid of third party Palm databases all together this year. I've been teaching myself Palm OS programming off & on for the past couple of months. Initial proof of concept work looks promising, and I hope to have a simple database done within a few weeks.

Mike

[Nate Smith]

Originally posted by Mike Soukup

Hopefully we'll get rid of third party Palm databases all together this year. I've been teaching myself Palm OS programming off & on for the past couple of months. Initial proof of concept work looks promising, and I hope to have a simple database done within a few weeks.

Depending on the format on the PC, I can work on a WinCE equivalent...I can get it to talk to Access quite easily...anything else, on the other hand, is a little trickier, but it can be done...