Programmers: I Have A Challenge For You

[kamocat]

I like the "Perceive, Plan, Control" paradigm that was mentioned earlier, and I think it's time that we break the conversation up into those three topics.
Should I take the liberty of starting a thread for each of those?

The "control" discussion is almost solely about the Autonomous Development Kit.
In essence, what is the code structure for controlling mechanisms?
It needs to be able to handle both sequential and simultaneous tasks, with a variety of control parameters for each task. (For example, a ball kick must be able to be triggered by the completion of another action, or an input, or after a time delay, or during a certain time in the match. Similarly, it must be able to be stopped by any of those.)

The "plan" discussion is the most complex of the three, as it deals with analyzing the situation, and there's a range of levels that this can be done on.
Here's a couple of examples (in first-person robot):

• Where should I move next?
• Is now a good time to kick, or will that robot get in the way?
• Should I block or score?
• Is it worth it to go over the bump?
• Will I get penalized if I go into that section of the field?

The "perceive" discussion entails what sensors should be used for what purposes.
I'll list some things an autonomous 'bot might want to know:

• Where am I on the field?
• Where are the robots around me? (what alliance are they?)
• Where are the balls around me? (on the floor, presumably)
• Where are the goals? The bumps? The towers? The walls?
• Have I flipped over?
• What are the other robots doing? Do they need help? (Inter-robot communication)

There are also simpler things, implemented into the "control" section, liked "have I completed my kick" or "is my arm fully extended", usually potentiometers or limit switches, that are used in feedback to make sure the action is completed. Unless someone's doing something exotic like using a non-contact thermometer to tell when a motor is stalled, I don't think these need to be discussed with the rest of the sensors.


As many have said, the scope is huge. I don't plan to do all of those things in "plan" and "perceive", but the first step is to consider the "how" so we can determine what is and is not feasible.

[biojae]

Originally Posted by kamocat

The "perceive" discussion entails what sensors should be used for what purposes.
I'll list some things an autonomous 'bot might want to know:

• Where am I on the field?
• Where are the robots around me? (what alliance are they?)
• Where are the balls around me? (on the floor, presumably)
• Where are the goals? The bumps? The towers? The walls?
• Have I flipped over?
• What are the other robots doing? Do they need help? (Inter-robot communication)

There are also simpler things, implemented into the "control" section, liked "have I completed my kick" or "is my arm fully extended", usually potentiometers or limit switches, that are used in feedback to make sure the action is completed. Unless someone's doing something exotic like using a non-contact thermometer to tell when a motor is stalled, I don't think these need to be discussed with the rest of the sensors.

This is where the GDC may play nice again, and bring back something like the 2 freq. IR beacons.
But, even if they don't there are simple ways for determining where you are on a field using encoders (Assuming the wheels don't slip. Hard for last year).

Using kinematic formulas:

S = (Delta Left + Delta Right) / 2
Delta Theta = (Delta left - Delta right) / wheelbase
Theta = Theta + Delta Theta
X = X + (S * cosine ( Theta ) )
Y = Y + (S * sine    ( Theta ) )

This satisfies one item on the list, but only slightly.

As far as knowing where other robots are, that would need a lot of DSP, or an external observer telling the bots where they are, or all bots to communicate with each other