| |
A little while ago Steve asked me to put together a T3 board in LDraw. After
some work and some discussions with Steve & Kerby, here is what I've come up
with.
http://www.brickshelf.com/cgi-bin/gallery.cgi?f=152911
I don't know why LPub rendered the green baseplate I built the board on in
yellow, but oh well.
The squares that the robot will place the T3 cubes in are 5x5 studs. The
surrounding dividers and the boarder are 1 brick and 1 plate high. The cubes
are 4x4, 3 bricks and 1 tile high. The playing area would be defined as the
area of the squares plus the 2 stud wide border. A robot would be required to
be completely outside of this area after EACH turn.
Suggestions? Questions? Concerns?
John
|
|
| |
On Wed, November 9, 2005 12:08 pm, John Brost wrote:
> http://www.brickshelf.com/cgi-bin/gallery.cgi?f=152911
>
> I don't know why LPub rendered the green baseplate I built the board on in
> yellow, but oh well.
I suspect you just put in a baseplate, and didn't specify the color...
|
|
| |
In lugnet.org.us.laflrc, John Brost wrote:
> A little while ago Steve asked me to put together a T3 board
> in LDraw.
It looks good - actually, I like the yellow.
> The playing area would be defined as the
> area of the squares plus the 2 stud wide border.
> A robot would be required to be completely outside
> of this area after EACH turn.
How much outside? For instance, does that mean when building your robot you
can *only* assume you can use the grid and surrounding two-stud area, and
nothing outside of that? Is there a a bigger "stand-off" so that a robot could,
for instance, deploy a retractable gantry for moving the pieces?
--
Brian Davis
|
|
| |
>
> How much outside? For instance, does that mean when building your robot you
> can *only* assume you can use the grid and surrounding two-stud area, and
> nothing outside of that? Is there a a bigger "stand-off" so that a robot could,
> for instance, deploy a retractable gantry for moving the pieces?
It is my understanding that the idea is to allow a builder to use as much area
beyond the 32x32 baseplate as they want on 2 sides (I don't think we ever
determined which side(s), similar to the rules for rtlToronto's C$ competition.
During their move, their robot can move inside the playing field area, but must
move completely outside of it at the end or their turn.
Make sense?
John
|
|
| |
On Wed, November 9, 2005 12:08 pm, John Brost wrote:
> http://www.brickshelf.com/cgi-bin/gallery.cgi?f=152911
>
> I don't know why LPub rendered the green baseplate I built the board on in
> yellow, but oh well.
I rendered it in LPub, and it came out the same (yellow). I changed the color from
"Light-Green" to "Green" and it looks right.
And, you may want to look into "multipart" models. It would let you draw ONE cube,
and place it in the model ten times... :)
Steve
|
|
| |
I guess you guys discussed the T3 board while at Chibots. I agree, the extra 2
studs around the perimeter would be a good thing. So after changing my
prototype robot last night to work with the extra area, I will be making the
changes to the LDraw file and rendering tonight. Which leads me to the next
questions:
What colors should we make everything? The current colors I used were basically
chosen because they were what my practice board was made from, which was
determined by which bricks were nearest me when I started putting it together.
I’m sure there are better (or more logical) choices.
I would lean toward black & white for the cubes. I think we want the plates
that mark out the crosshatch pattern to be black, but what about the other
plates? What about the bricks beneath these plates? Gray perhaps? I’ll use a
green baseplate (and not light green) this time.
Comments/Suggestions?
Thanks
John
|
|
| |
On Thu, November 17, 2005 11:58 am, John Brost wrote:
> What colors should we make everything [for the tic-tac-toe]? • ...
> I would lean toward black & white for the cubes. I think we want the plates
> that mark out the crosshatch pattern to be black, but what about the other
> plates? What about the bricks beneath these plates? Gray perhaps?
The baseplate should be green. The crosshatch plates should be gray, because that's
the most common color in the Mindstorms set (for plates), and it can be seen as
different from black & white (the cube colors).
The other parts don't really matter, because robots won't need to "look" at them.
I'd say everyone's robot MUST be able to work with the standard colors. Your board
& pieces don't have to be the 'correct' color, but your robot must work with the
right colors.
White goes first.
It would be nice to have our first round at our meeting in January (3rd Sunday).
That gives everyone the holidays to get stuff going.
Steve
|
|
| |
In lugnet.org.us.laflrc, Steve Hassenplug wrote:
> The baseplate should be green. The crosshatch plates should be gray, because that's
> the most common color in the Mindstorms set (for plates), and it can be seen as
> different from black & white (the cube colors).
>
> The other parts don't really matter, because robots won't need to "look" at them.
>
> I'd say everyone's robot MUST be able to work with the standard colors.
>
> Steve
With this being said, I've re-done the T3 board in LDraw. You can see the
latest version here (when it goes public)
http://www.brickshelf.com/cgi-bin/gallery.cgi?f=154924
The basics: baseplate-- green, cubes-- white & black, surround-- black,
crosshatch plates-- gray
If anybody sees a problem with this, by all means speak up!
|
|
| |
In lugnet.org.us.laflrc, John Brost wrote:
> I've re-done the T3 board in LDraw.
Someday I'll have to learn LDraw (or more likely LDD at this point). Very
nice work John. It looks like it's one brick and one plate high?
> If anybody sees a problem with this, by all means speak up!
I wish it was symmetric, but that can't work unless we make all the cells 6
wide. One point - we need to define what zones are "off limits". Each robot has
control of, say, their side and the edge to their left?
--
Brian Davis
|
|
| |
In lugnet.org.us.laflrc, Brian Davis wrote:
>
> Someday I'll have to learn LDraw (or more likely LDD at this point). Very
> nice work John.
LDraw is actually much easier to start using than I thought. The interface is a
little cumbersome, but nice. The lego pieces practically snap into place (but
not the technic pins & stuff, they're trickier). I have only scraped the
surface of LDraw to this point, I know it can do a lot more.
> It looks like it's one brick and one plate high?
Yes.
> I wish it was symmetric, but that can't work unless we make all the cells 6
> wide. One point - we need to define what zones are "off limits". Each robot has
> control of, say, their side and the edge to their left?
I agree, it would have been nice to get the board symmetric, but I think this is
the best design given the constraints of the 32 x 32 baseplate. 4x4 is really
tough to drop a 4x4 cube into and 6x6 is too big.
I was thinking of their side and to the right would be the zones the robot has
permanent control of, but if we want to do their side and to the left, that's
cool. I don't care. Once we decide I'll take the rendering of the board into
photoshop and color the zones so everybody understands. The other thing we need
to define is the signaling between robots when they complete a turn. I was
thinking we'd probably use the same sort of touch sensor setup as rtlToronto did
with their C$ competition. Each robot has a touch sensor that is hooked up to
their competition's RCX. The touch sensor is pressed to signal the completion
of their turn. There are other ways of doing it, but this seems to be about the
simplest and most reliable. This also makes it an easy conversion from robot
vs. robot competition to robot vs. man.
John
|
|
| |
On Tue, November 22, 2005 9:32 am, John Brost wrote:
> I was thinking of their side and to the right would be the zones the robot has
> permanent control of
I'm going to go with John on this. But only because I don't want him to have to
start over, and I doubt it will affect Brian. :)
> The other thing we need
> to define is the signaling between robots when they complete a turn.
> Each robot has a touch sensor that is hooked up to
> their competition's RCX. The touch sensor is pressed to signal the completion
> of their turn.
Sounds good.
I have a BrickOS program that I made up to keep time. If I can find it, I'll post it.
Steve
|
|
| |
In lugnet.org.us.laflrc, Steve Hassenplug wrote:
> On Tue, November 22, 2005 9:32 am, John Brost wrote:
> > I was thinking of their side and to the right would be the zones the robot has
> > permanent control of
>
> I'm going to go with John on this. But only because I don't want him to have to
> start over, and I doubt it will affect Brian. :)
> Steve
No need to do that. My prototype sits completely behind the board. It doesn't
extend along either side of the board. Speaking of which, I finished up the
controls last night. I've just got a little bracing I'd like to do then it is
on to programming. Thinking about how complicated the programming is going to
be has me thinking of going with something besides Robolab. Maybe I'll try
using LEGO's Mindscript or whatever they call it that I downloaded to program
spybots.
John
|
|
| |
In lugnet.org.us.laflrc, John Brost wrote:
> The other thing we need
> to define is the signaling between robots when they complete a turn. I was
> thinking we'd probably use the same sort of touch sensor setup as rtlToronto did
> with their C$ competition. Each robot has a touch sensor that is hooked up to
> their competition's RCX. The touch sensor is pressed to signal the completion
> of their turn. There are other ways of doing it, but this seems to be about the
> simplest and most reliable. This also makes it an easy conversion from robot
> vs. robot competition to robot vs. man.
My concern with this approach is that your robot needs to use an output port and
an input port just for communicating with the opponent. I haven't designed or
considered my solution to the competition, but I might want my ports for other
things.
I think we should consider an alternative method.
Bryan
|
|
| |
On Mon, November 28, 2005 11:17 pm, Bryan Bonahoom wrote:
> In lugnet.org.us.laflrc, John Brost wrote:
> > Each robot has a touch sensor that is hooked up to
> > their competition's RCX. The touch sensor is pressed to signal the completion
> > of their turn. There are other ways of doing it, but this seems to be about the
> > simplest and most reliable. This also makes it an easy conversion from robot
> > vs. robot competition to robot vs. man.
>
>
> My concern with this approach is that your robot needs to use an output port and
> an input port just for communicating with the opponent. I haven't designed or
> considered my solution to the competition, but I might want my ports for other
> things.
>
> I think we should consider an alternative method.
Feel free to suggest options.
This method actually only requires one open sensor port. As John pointed out, that
port can also be used for a touch sensor so a person can play against the robot. Or
you can use the port for other things, while you're not waiting for the EOT (End of
turn) signal from your opponent.
Steve
|
|
|
