Re: Bump or bridge?
 

I think the bridge is a viable option because of the damage that going over the barrier could cause to components, as well as the problems of tippy-ness and designing a frame and manipulator around a bump. Here is more video of the bridge (built by my team today) :http://www.youtube.com/watch?v=zG01r...KrS8tzFvtklp1w

Re: Bump or bridge?
 

That's true, but I think that the 2010 game had a much different dynamic than this game. Zone game play was preferred, and strategies centered on teams staying and controlling a specified zone.

Here, one might have to take multiple trips back and forth in order to retrieve balls. That is, of course, if long range feeder/shooter bots don't become a norm.

But I suppose it's only speculation at the moment. I'll say better to be safe and be able to do both.

- Sunny G.

Re: Bump or bridge?
 

The bridge is a safe-haven from defending/opposing robots. As long as you are traversing the bridge of your color, your robot is "completely protected" from any defensive or opposing robots. One side of the bridge leads to your alley, which is also "safe" from opposing robot interaction (unless the opposing robot wants to get fouled). These are guaranteed by rules G28 and G25.

I could not say the same for the bump. A good defensive robot could theoretically pin you anywhere near or on the bump, which causes problems.

Re: Bump or bridge?
 

Simply put, if your only option is the bridge, you are stuck with the bridge. But, if our system can do both, you don't have to worry about it, and can surprise the competitors. Most systems to cross the bump can also be made to cross the bridge. Just do both.

Re: Bump or bridge?
 

Both. Even if you can get over the bridge swiftly and smoothly every time, another robot can fall off and block it or take half the match to negotiate it.

Wetzel

Re: Bump or bridge?
 

we didnt either

Re: Bump or bridge?
 

I want to do both why isn't that a poll question.

Re: Bump or bridge?
 

Go run game simulations and remember the lesson of Breakaway. You are maximally efficient at scoring when you reduce time spent traveling to a minimum. It seems to me like many people on CD are vastly overestimating the number of times a given robot will need to cross the field to be effective. Go look at the name of the game...

Basically, we think that there will be next to no bridge traffic among alliances that are good at playing Rebound Rumble. Designing a robot to cross the bump adds additional design constraints for both your intake and your drive, and saves you... not that much time. The decision you have to make is whether or not the fairly small amount of extra time is worth designing an intake and drive to cross the bump.

Re: Bump or bridge?
 

My team has currently determined that it shouldn't be overly hard to get over the barrier with kitbot West Coast Drive (without any testing mind you), and if we find that we can't do it with the kitbot drive, we will create a mechanism to get over. Designing the intake to deal with that is going to be a challenge, especially going into this planning to not use pneumatics.

5 Weeks and 4 Days 'till Stop Work Day. Good luck Ladies and Gentlebots.

Re: Bump or bridge?
 

I think it comes down to how many times you plan on crossing the the middle of the field in a match. I am currently thinking that this game will become more like 2010 where many robots had no reason to cross the bumps many times during a match. Some have said that you might as well make your robot able to cross the bump and bridge, but I think there are designs out there that could make the bump a reasonable sacrifice in order to make other parts of your bot better.

But, like I said, it will depend mainly on how many times you think you will need to cross the midfield. If crossing the midfiled is going to be a main part of your strategy, then I think the robot will need to be able to do both.

I created a pole for the number of times expect to cross mid-court to get an idea of what others are expecting. See:
http://www.chiefdelphi.com/forums/sh...ad.php?t=99676

Re: Bump or bridge?
 

I believe the balls are so different from 2010 that you will have to be relatively close (my guess would be the farthest most teams can get it in from is the key). Soccer Balls are designed to bounce, and were meant to be used in a field about 2-4 times larger than the FIRST field. The balls this year are foam filled; it's going to be interesting to see how many teams can get them to travel halfway across the court.

Re: Bump or bridge?
 

This may have been mentioned earlier, but our team is thinking that one robot in each alliance will most likely want to be a guard and pass balls to their alliance's scoring side. This means that the guard bot would only have to cross over once. Using the bridge once per game does not seem like a good enough reason give your robot the ability to jump the bump.


Also anyone planning on just going over the bump is forgetting a very important thing. You will have to have a way to get onto the bridges for end game. For these reasons the people who are planning on doing both seem like their doing the right thing. Personally I feel that it's unnecessary to jump the bump, and that doing so could cause you more problem (ex. tipping, router getting jostled and loosing connection, and potential for damaging the robot just from impact.)

Re: Bump or bridge?
 

Good points. A counter question I would have for you is what do you think your estimated time for crossing the bridge will be? Meaning, approach the bridge, tilt it, cross it.

Even if you save 4 or 5 seconds, and you only cross 2 or 3 times in a match, thats saves you around 12 seconds. That could be over 10% of the entire match.

The tradeoff everyone will need to make a decision on, is that time worth saving by complicating other aspects of your design?

-Brando

Re: Bump or bridge?
 

After a long meeting on sunday and running the 2012 Catalyst; we have decide to go over the bridge but still be able to go over the bump if the bridges are being used.

Re: Bump or bridge?
 

to be honest both would be good for flexablity