The first hint has been posted!
The graphic is of a bridge and a large gorge… The text is of track and field bases…
hmmm…
So it mentions two obstacles, the bridge and the hurdles. This could be literal and we might have some giant field object that makes movement difficult (a fairly safe bet, considering there’s been something that impedes movement at least a little bit every year of FTC). My guess would be something to do with hanging. You can hang off of bridges and hurdles, and we’re overdue for a hanging portion as we haven’t had one since 2006. Most FTC teams have never had to deal with hanging and so this could be a great new game challenge.
Then there’s the reference to bottles, and to shoes… perhaps something with track and field and the scoring object could be those metal sports bottles with the rings?
http://www.technoguards.org/system/files/images/FTC_Bottles.jpg
(yes, those are quickly photoshopped bottles… - No I don’t have ones like that… - yes, it would be cool if we did!)
I think Hanging would be awesome with FTC. It would allow people to see what this kit can really do. 
Don’t forget, you can jump/fall off of bridges and jump/tumble through hurdles :ahh:
The raw materials should make for some interesting winch & lock systems if the game contains a hang.
Bungee Cords!
(Maybe they really just don’t want us to take FTC for granite…)
The first time one of our team members saw the picture, their first thought was a bridge between two fields. That could definately add a new element to the game, and the matches could become 4v4!
They are going to revive and play “Bridge Battle”??? :ahh:
Field is in two parts connected by two bridges…field elements are tubes that you have to transport to your side of the field. Teams will only be able to pick up one tube at a time.
1 point for having a tube on your side of the field.
5 points for hanging a tube in some manner.
20 additional points for each robot that is sitting on its respective bridge at the end of the match.
My guess. 
It seems a bit boring…but the bridge aspect would be interesting…perhaps the bridge has no side rails or something…
He specifically mentions robotics AND unmanned vehicles. perhaps he is also suggesting a longer autonomous mode?
That… would be horrible, in my opinion. Ever had to sit there for 30 seconds with no robots doing anything??? Not really that fun or interesting, its the longest 30 seconds ever in my opinion.
Just my $0.02
Andrew
I beg differ on this point. If we can come together as a community and help make autonomous operation accessible to as many teams as possible then we will be one step closer to making robots instead of remote controlled cars. I feel that the autonomous period should be the primary period, however I accept that not all teams would be capable of this. Once the FTC game is announced I welcome anyone to pm me for help with autonomous in NXT-G, RobotC or Labview.
While I agree with you that autonomous is more valuable than tele-op (the combination of programming and engineering coming together) tele-op does require coding as well and successful teams tend to implement lots of coding into tele-op. I would be more in favor of a challenge that rewards teams that utilize more complex code in tele-op. Then, even rookie teams with no programmers should be able to do something instead of just sitting there even if they won’t be terribly competitive.
A longer autonomous really presents you with only a couple of options. You can just sit there doing nothing (which makes the game more boring and, therefore, less interesting to spectators), you can design an excellent autonomous that does any number of things and scores a hundred, thousand points, or you can write a ramming code in 5 minutes designed to stop the aforementioned amazing program. Besides, even the amazing autonomouses (autonomi?) rarely need the full 30 seconds.
In my mind, moving robots attempting to do something>rambots or non-moving robots and a longer autonomous, at this stage, would be bad for the game.
Well when it comes to helping other teams I’m all for that, of course we have done that many times in the past even for the most basic to complicated of strategies. I feel automode has always been a key part in the FTC games. Face-off and Hotshot are the only games I know all the rules for, but if you can own automode it can make it incredibly difficult for the other alliance to make up for their disadvantage. Its a great idea for a longer automode for a game aspect, if there is THAT much to do. Sometimes you need that extra 5 seconds or something like that but I think making automode longer than 45 seconds might be a little much. From a personal aspect from waiting for matches to continue on the field and watching games in the stand, it can be very uninteresting, or very thrilling depending on the matches and the teams in the matches.
Andrew
A good autonomous program should be able to avoid a auto ram-bot.
I am not calling for an elongated autonomous period, I am merely trying to give every team the capability of developing a successful autonomous mode.
a complex autonomous could be built were it not for the NXT’s horrible memory management. I don’t know about other teams, but i constantly had to tweak my teleop before i even built autonomous to fit on the NXT last year.
The key to making your NXT programs smarter jet still fit in the NXT is to make strong use of SubVI’s (or subroutines).
The code for these is shared, so they take up less room than two sets of duplicate code.
So if you find yourself adding the code to turn 90 Dec several times in your program, you can make your program smaller by creating a SubVI to do that turn.
Better yet, make a SubVI that has the turn angle as an input.
We had an Auto program last year that had 12 different move patterns.
We just kept making the SubVI’s smarter, and more generic, till we got to the point that every Auto sequence was built up from three or four VI’s (which managed moving and shooting).
To add an entire new sequence we just had to call the existing VIs. This required very little extra code or memory.
Remember. Cut & Paste is the enemy of programs. If you find yourdelf doing a cut & paste of C or LabVIEW code, it’s time for a Subroutine or subVI.
Phil.
I’m not a master C programmer yet but when it comes to programming in the language follow the KISS method is how we do it and the world championship last year proved us right in most respects. Now this year we are doing aLOT more sensor based programming to a small extent but what people didn’t realize last year I didn’t see a single team out there where that Infared sensor worked consistently. Now Line following…I liked that i have heard it was VERY reliable for autonomous espcially.
Within your code for C make sure you’re not repeating your int statements at the Tennesse regional espcially I went around helping teams alot of them had 2-3 in statements reintializing the same thing multiple times.
And going to what Phil said about in LabVIEW those subVI’s can sometimes make or break you on file size requirements.
Have fun this season:D
John Fogarty
For the record, our IR sensor worked 100% reliably.
If we ever missed a goal in Auto, it was because our shooting height fluctuated, or somene blocked the robot from getting in position. If not, we were always dead center.
It also worked really well in teleop. We had single button for aim-and-fire. If the driver got the distance right, it was always on target.
The Key to a useful IR sensors was using the required 30 degree offset (to center the narrow beam on the target) and then comparing the intensity of the two beams on either side to split the absolute center of the beam.
ps: it also helps if you don’t let the beacon battery go dead 
Phil.
I just finished the game animation a couple days ago. Wow, the Game Design Team at FIRST did a great job coming up with some fun challenges this year! I’m looking forward to seeing all the innovative robot systems the teams design to meet those challenges.
I probably shouldn’t do this, but here is a link to the last frame of the game animation.
