Ideal FRC Game

[ToddF]

How about a game where the robots are the playing pieces, and the difficulty is navigating the playing field? The object is to touch the far side wall, for 10 points, then your own side to reset. The obstacle is that there is a 6 foot high wall in the center of the field. The wall has two openings (red and blue), 1'x2', three feet off the floor, where the red and blue ramps were this year. Robots may go through the slots or over the wall. Only robots that match the slot color may pass through the slots, and preventing a robot from going through a slot is a penalty. Autonomous scores are worth 30 points. End game is to be 5 feet above the floor, supported only by yourself and the wall (no other robots), 30 points. Coopertition points scored by assisting other robots to return to their side of the wall, 10 points. Halfway through the match, a section of the wall drops in the center (where the coop bridge was this year), leaving a 3 foot wide opening, 3 feet off the floor.

This game would encourage differentiation in robots. It would be difficult, but not impossible, to score yourself. There would be lightweight scoring robots that go over the wall or through the slots. There would be helper robots that help the scorers get through the slots or over the wall. Some might be able to do both.

Interesting twists could be made by playing with which side of the field is the scoring side (near or far). You could also play with making the wall either transparent, or opaque (or some combination).

To make it most interesting, robots start on the far side of an opaque wall. Robots are allowed to carry one video camera each, and the video feed from all the cameras on an alliance goes to all the operator stations on that alliance. So, even robots that never move during a match would at least provide valuable video to their partners. The video scoreboard would display the video feeds from all the robots on the field, so the spectators have the advantage of seeing both sides of the field, and also all the video feeds. Kind of like televised poker. If a drive team were good enough, they could watch the big board instead of their operator station, to see all six video feeds.

Defense is legal once a robot is on the floor, but would be difficult, since the defenders would only have video to drive by, and the scorers would have eyeballs on their robot.

In the simplest version of the game, with everyone playing nice, two ramp bots on each side sit by the slots and a scoring bot from each side races up and down the ramps, back and forth through the slots, scoring points. There would be lots of strategy around when to help your opponent return to their side of the field. Scoring robots that could score on their own have a big advantage.

Because of the size of the slots, previously developed, "stock" drivetrains won't be the biggest scoring bots. Robots which are small, light, fast, and can get through the slots on their own would be the best. If you stick with a previously developed drivetrain, you have to go over the 6 foot wall, help other bots through the slots, or wait until the center section drops, and fight to get through.

Edit: While we are dreaming, robot rules would allow the Arduino Controls Package (am-2316), to replace the CRIO, and robot electrical power to be provided by any 3C LiPo battery, as long as it was fully enclosed by a battery box of minimum 1/8" aluminum construction.

[apalrd]

Originally Posted by ToddF

Because of the size of the slots, previously developed, "stock" drivetrains won't be the biggest scoring bots. Robots which are small, light, fast, and can get through the slots on their own would be the best. If you stick with a previously developed drivetrain, you have to go over the 6 foot wall, help other bots through the slots, or wait until the center section drops, and fight to get through.

I think you're completely missing the point about developing drivetrains, and using designs from the design shelf.

When we build prototype drivetrains pre-season, we have several goals:
-Design exercise for everyone involved
-Better performance in any number of categories (turning performance and weight are most commonly optimized) than what we have now
-Find a way to manufacture it easily using our resources
-Create a list of lessons learned that we would change the next time we built a similar drivetrain.

We built a nice development platform in the 2010 off-season. We ended up with an 8wd Dual Drive articulating rear wheel cantilever live axle chassis, with fully automated articulation (all written in C on the IFI processor) and Toughboxes that went around 11fps. We used kit wheels (2008 gray style) because we had a lot of them. We had a lot of things we wanted to learn, so we designed it to test all of them:
-Could we get away with thinwall (1/16th") box tube?
-Would our 2-plate bearing carrier work?
-Would the dynamic performance of the articulating drivetrain be better than a flat 8wd? We also wanted to develop algorithms for this since it worked well in initial tests.
-Would our method of chain tensioning work? We were slightly concerned about the lack of dynamic tensioning on the articulating wheels, and wanted to prove it.

We learned a lot. If, in 2011, we wanted to build a wide robot, it would not have been very hard to use the lessons learned from previous designs to build something good. We put the test chassis on our design shelf (figuratively, it was physically left in the basement), and decided it might be useful in the 2011 season (which it was). When we took the design off the shelf for season use, we also had a list of things we didn't like that we would change, changed them all, and modified it to fit our design goals for that season.

Most of the design in a design from the design shelf is not the exact length and width of the chassis. Had we been required to build a smaller or larger robot, we could have taken the wheel module assembly and located it anywhere along the frame rail, and adjusted the frame rail as necessary, or even added or subtracted wheels easily. To change the length and width, a total of four pieces would be made differently. All of the 'tough' design work was already done, in designing the wheel module assemblies. Those would not change, even as the robot dimensions change.

What's cool about that is we already have the 'stock' engineering done. For a specific game, once we decide we are building a skid-steer robot, and we make a general mechanism package model (large rectangles of space reserved for mechanisms, and optimal hard mounting points), we can CAD the frame rails or panels, and drop in the wheel module model we already have, and make it.


Basically, what I'm saying is that it's not hard to change the dimensions of a shelf design to fit another set of requirements.

[ToddF]

apalrd,
You raise some great points. If you don't mind, I'd like to paste your response into a new thread topic, as not to hijack this thread.