Intramural game

[GeeTwo]

Here's the game! Ball Bot Thirty All (BBTA).

It's a bit simpler than most FRC games, but not massively so; there are only three ways to score, and about a dozen fouls. The arena and robots are both on a bit of a $$ budget $$, but the extended autonomous play and the "blind" period will encourage development of autonomous and semi-autonomous routines.

I'll be posting an upgrade with plenty more images of the field after we get our field built today! I've put about eight hours into it so far, and I'm figuring on about another three to get the field together. There's even a parts list for your trip to hour local home center to build it.

Okay, in three.. two.. one.. BOT!

[GeeTwo]

Version 2 of the rules is attached. There are plenty more images (photos of the half-court that we built this morning), and a few rule clarifications and additions:

• Many figures added, captions added, minor corrections (typos and corrections to terms used elsewhere)
• Arena: Movable barrier is 5½” tall by ⅝” thick
• Drivers box only extends 18” behind table
• G6: other human team members added to rule
• G12 through G15 rules added governing robot-to-robot interaction (adapted from Aerial Assist)
• Yellow and Red cards defined as reference to Recycle Rush section 5.5.4.
• R3 clarification of handle rules; separation of rule from explanation
• R10 Special cost rules for parts from team inventory, donated parts, and second battery.
• Added Match Pacing and Field Reset paragraph
• Minor adjustments to field construction based on experience during final construction
• Adjustments to team 3946 KoP: eliminate duplicate PDP, reduce to two VersaPlanetaries, add a length of Versaframe tubing, and specify 59” lengths

The only question asked by my team today that wasn't clarified by the update was:

Q1: What if a ball falls out of a goal during the match?

A1: Both the tote goals and the hand goals are quite deep, so this is unlikely. In the unlikely case that balls "fall out" of the goals before the time specified for them to be scored, they will not be scored. In particular, if a ball "falls out" of a hand goal between the end of autonomous and the end of the match, it will be eligible for the 10 point autonomous bonus, even though it does not receive the 10 point end-of-match "hand goal" score. If the ball "falls out" during teleop, but is replaced by the same or a different ball during the match, that goal will score at the end of the match, as there is a ball in the goal at the end of teleop.

OBTW, I wore some old working blue jeans and a 2015 CMP shirt to our kickoff. When time came to present the kickoff power point, I donned a long-sleeve denim shirt that somehow followed me from way before the divorce (in 2001).

Thanks to my reviewers: orangemoore, Chief Hedgehog, and especially AllenGregoryIV, for their PM inputs!

[jruppel]

A few scenarios that I feel need rules:

• The robot extending over the middle barrier during autonomous.
• The robot lowering the middle barrier after autonomous.
• Damaging the field/game pieces.

One smaller suggestion:

• A simpler way to move the robots to and from the field. My thought was to add a small "door" to both sides of the field.

Thank you for your hard work to make this game possible.

I'll let you know if I think of anything else.

[GeeTwo]

Originally Posted by jruppel

A few scenarios that I feel need rules:

• The robot extending over the middle barrier during autonomous.
  Yes. I wrote this; it must have been the version that I clobbered by opening an older one. This will be added to G5.
• The robot lowering the middle barrier after autonomous.
  G9 forbids this; it is in effect the whole match.
• Damaging the field/game pieces.
  Yes, I'll extend G9. I'll also add a general "hazardous construction" R11.
• A simpler way to move the robots to and from the field. My thought was to add a small "door" to both sides of the field.
  I considered both one and two door designs, but I opted for simplicity in construction while dependably keeping the robot inside the field. Between the smaller robot and the handles, I don't think moving the will be too difficult. This will be even easier in two-robot tournaments like ours; most of the transits can be made through the gap in the central barrier. For two-robot tournaments, the robots will only have to go over the wall for drilling, cutting, and jobs that really call for the robot to be on a table. When a robot is in consecutive matches, battery replacement and minor repairs/adjustments can be done on the field; that's why up to four team members are allowed on the field at a time. If we do add doors, finding some way to secure the walls to the carpet will be essential.

[GeeTwo]

Version 3 of the BallBot manual is attached. The only substantive changes are as outlined in my response to Jonathan above.

[GeeTwo]

For those who are interested in our progress (most likely people on 3946, but you never know):

The two teams have analyzed the game, determined priorities, and described (but not clearly drawn or otherwise rendered) their designs, and begun prototyping (and possibly building).

The "Nameless" team (including my son Perry) has placed a priority on scoring at least one, and preferably both "hand goals" during autonomous. They have "bought" a third gearbox, CIM, and omni wheel from team inventory (am-2598, am-0647, am-0255, am-3047, for $130 at AndyMark, or $65 as it's all in team stock and therefore half price). They plan a kiwi drive, and a rather complex pickup/placement which involves sweeping balls into a length of PVC pipe located outside the frame perimeter, locking them in with a couple of servos, and sweeping them out later with a (probably different) set of wheels, either into the hand goals or the tote. This pipe will be extended outside the frame perimeter and lifted with pneumatics. As I believe their pipe is only capable of holding three or four balls, my thought is that they will not be able to score a lot of balls in the tote in three minutes; they're going for quality at the expense of quantity. I hope they get that autonomous working, both for their own purposes, and because that knowledge will then belong to 3946. Nameless will sport red bumpers, decorations TBD.

The "Jazzy Hippos" (including my daughter Veronica) is planning a simple four-wheel tank drive (currently all KoP rubber wheels, but designing to swap to omnis on two corners if needed). Their manipulator is also very simple, but perhaps diabolically inspired. They intend to have a 10" gap in the front bumper (the widest allowed by the rules, given an 18" frame perimeter and 4" bumper setbacks from the corners) and make an 8" wide, rather tall (shooting for 30+ inches high to score hand goals) conveyor belt of velcro hooks, located at the frame perimeter. As the balls are essentially the same thickness as the bumper, they expect to be able to pick up balls against the wall as well as on the field (the need to compress the bumpers may make high traction a necessity). To score balls in either the hand goals or the tote, they will pull right up to the goal, reverse the belt, and "scrape" the ball off on the edge of the goal. (The actual language they used to describe the action isn't quite as delicate, and explains why little balls of hardened mucus can be found on school desks.) The Jazzy Hippos aren't planning much in autonomous, possibly a bit of ball pickup but probably no scoring. On the flip side, given their wide, tall belt, they will have to be careful not to control more than 12 balls at a time, and will be able to carry and score a bunch of tote balls with each trip. So far, velcro one-wrap strips are all they have "bought" with their $200 allowance (about $30 so far, if I can find the 1.5" x 30' strips at either Slidell Home Depot). JH will carry blue bumpers, decorations TBD.

I am a bit disappointed in the lack of detailed drawings for both groups, though from speaking with the lead builders, I believe they have a solid concept in mind as to what they are building. I am very definitely glad to see two distinct approaches to the game. I hope that both teams execute (roughly equally) well and that the difference comes down to strategy. Unfortunately, the Jazzy Hippos have had a significantly smaller attendance the last few weeks than have "Nameless". We shall see what we shall see, and we shall learn what we shall learn.

[GeeTwo]

Our intramural game build has been interrupted by our need to shift to a new build space. It's great news in the long run, as the room will be full-time team space, but we had to move everything over in a very few hours with no warning and then figure out how to re-organize in the space.

As I mentioned above, "team nameless" decided to build a kiwi drive, more for the practice and wow factor than real engineering requirement. Due to the KoP contents and the interesting budget rules (extra items pulled from team inventory count half towards the "extra parts" budget), they decided to build their kiwi using three AM14U2 gearboxes (TB minis with long hex shafts and an 8.45:1 gear ratio) and duraomni wheels mounted on VersaFrame. They thought they would have to make at least one of the motors a mini-CIM in order to fit the 18" square game rules dimensions. Their first attempt was sufficiently disheartening that I decided to "prove to myself" that this could be done. I drew up the following three designs in power point (never learned real CAD). All are pictured from below:

This one seemed most like what the team wanted to do. It is actually 17.5 x 17.66 (9 + 5 √2) inches rectangular. I mounted the TB-minis through the upper pair of holes in the base plate, and cut oversize holes to pass the cap screw heads through. The center really did look like that, telling me that the triangle was essentially equilateral. Do note, however, that the CoG should be located about 10" from the top of the pic, which is a bit over an inch below the geometric center of the rectangle. I also figured that if this were to be a competition robot, I would probably rivet the entire perimeter, but use bolts for the "cross beams" on which the motors are mounted. This is because of the difficulty in accessing the through holes; it was far easier to mount the gearbox to the cross beam, then install it in the chassis than to install the gearbox in place. Also, note that I only needed to drill six through holes in the vertical direction (indicated in red). If you wanted the outer frame to be a round number of inches, you could do the same thing by only drilling the holes for the 30-degree gussets needed at left center and right center. And yes, I was duly impressed with the rigidity of the resultant frame, especially with the triangles in the corners.
I also figured that with the omnis close in to the gearbox, I could get away with no end support on the axle. If a bit of support was needed, plan A was to put a hexagon of thin sheet aluminum and three short pieces of angle aluminum so that the three gearboxes pulled against each other to keep the axles horizontal. If this proved insufficient, I would have had to go with a versaframe bearing support (with the versaframe side bearing mount being the favorite).

Here was a classic kiwi drive, implemented with versaframe and the same gearbox and wheel. The black box is 18" square, to show it fits within the specification. This one was just a proof of concept; on an actual robot, I would have cut the ends of the long pieces of VF on a 30 degree miter to simplify bumper construction.

This is a design I came up with a few days later. I call it a "U" drive. It's essentially an H-drive (slide drive), but without the belts or chains, because there are only three wheels. The relative loading on the "forward/reverse" wheels vs the strafe wheel is a simple function of center of gravity management; no springs, cylinders, or torque engagers are required. As I worked through the kinematics in my head, the big wrinkle was that if you were to execute a pure strafe, the off-center wheel would introduce a torque that would cause the "forward" wheels to rotate against each other. The bottom line here is that I would not want to run this style of drive train without a gyroscope or other sensor feedback so that the programming eliminated unintended torques.

[Alex2614]

We did something similar this year, but mostly designed to help teams learn how to build effective drive trains and control systems, and more advanced teams to train their new students on building and designing.

It's called FIRST Base, check it out with the link below.

http://www.mars-first.squarespace.com/first-base/