So we finally got around to taking a couple videos of autonomous doing its thing… id say we are satisfied for now. It makes a full lap (sometimes 5 lines depending on the ball positions), and knocks off two balls.
consistently.
If you scroll around in the playlist bar, you can find more videos/pictures of our robot.
See you at the CT Regional!
How is it driven? All autonomous?
how are you detecting where your colored ball is? because the opposite team will get the points if you knock down their ball.
are you using the ir sensor.
Why is this robot ‘almost a year old’ according to the description?
Looking fancy shmancy guys… can’t wait to hear some more details.
-q
There is a ‘theoretical’ all autonomous mode where it uses a custom made camera to locate the balls.
however, this is not implemented as of yet, and so probably will never be (in the spirit of tools/laptops down).
We tell it where the balls are with the IR remote, and basically push those positions onto a stack. As the robot makes laps, it pops these set positions off of the stack, and corrects to them using a closed loop driving system.
Trial A Demonstrates its ability to hit balls in other positions.
The wheel that broke was almost a year old. This is our practice robot, and we were too lazy to build a new one, so we basically slapped the gripper mechanism on top of last years practice robot, along with the dual shifters.
It isn’t that bad, just wait until there are 5 other robots out there that could possibly get in your way
Weve thought about that… and i don’t think we made a video of what our robot does to those who decide to get in its way.
The adjustment the robot makes to get to the other ball position is absolutely beautiful.
The quality of autonomous modes this year seems to be quite amazing. I wonder if it is due to the slightly reduced complexity (driving is easier than driving and using an arm) or if teams are just adding to their repertoire of knowledge.
Either way, I would love to see teams come out and release well commented and organized copies of their code so that others can learn from what they have done.
Also, can you expound on the “Custom Made Camera”?
i think it’s because autonomous is worth investing a lot of time in this year, unlike 2007.
2006, if you remember, had many great auto modes as well, and 2006’s auto was less points-valubale then this year’s…
Thanks 
‘expand’ you mean? well it was a CMUCAM3 which we bought from seattle robotics, and i basically reprogrammed it to do a sampling of 3 predetermined locations, and using an HSV tolerance system it would return the position of the desired ball.
we had the camera working, we just never got the code implemented on the robot, so we cant really use it.
First off, nice work. It’s definitely not the easiest thing in the world to drive that far with that kind of accuracy, so I commend you for your hard work.
I don’t want to stir up a controversy, but I would like to know what people think about this topic. Billy explained the functionality of their robot as:
My question is simply is this legal? My answer is I don’t know because I see both sides.
On one hand, I would say this is legal because the action taken when one of three buttons are pressed, the ball location corresponding to that button would be pushed onto a stack. That has the same repeatable outcome every time…a button is pressed, a position goes on the stack. How the robot interprets this is irrelevant.
On the other, I would say this is illegal because based on what I’ve read in Update 3, an action is something that the robot physically does (I don’t agree with this, but it is what it is). For the sake of argument, there are 9 possible actions that are taken (i.e. left then left, left then middle, left then right, etc…). This is clearly more than the 4 allowed actions.
If your buttons told the robot where both balls were at the same time, I would agree that this represents “a single snapshot of information about the state or condition of the field”. Queuing up snapshots, I fell, is not a single snapshot because the same button has changed its meaning to represent a different state.
I also see issues with this being a message sequence because the robot’s actions are dependent on the order that you press the buttons in. The update clearly says that message sequencing/encoding is not allowed
Please don’t take this as an attack towards the work that you’ve done. I definitely appreciate the work that you’ve put in to make this system actually work. In light of some of the recent rulings at competitions, I think that you should put a Q&A in so that you don’t run into problems and have to back out all of your hard work at the competition.
Dave,
I had the same doubt a few weeks ago (before we realized our auto mode was great for the first ball but didn’t leave time to go for the second 
) and asked this question on the Q&A forums.
I knew the intent of the rules allowed it, because high-level suppervisory commands are exactly what the GDC wanted us to do. The letter of the rules, as we agree, seem to disallow this.
Even the GDC answer is not mentioning the letter of the rules but, based on the link I posted above, they should be fine if questioned at an event.
By the way, 1124, we really hope to play with you guys next week in Connecticut - will you please let us knock off that first trackball?
Manoel
The way I read the Q&A response that you’re referring to is that it’s legal to do what you’re described after the first ball was knocked down. I completely agree with that. It’s a single action “knock down the ball from the next overpass” and could be rerun just as a “turn left” command could be.
If that’s what the Uberbots are doing, then I think that answers my question from above.
However, if they are sending the two commands before that first ball is knocked down, I think my question still stands.
Dave
Easy fix:
Press the second button after the first ball is knocked down.
We are debating whether we should use this approach or if we should simply have the RoboCoach drive the robot. I’ve seen success with both.
Our first approach was to simply push a button according to which position the ball was in. That was inconsistent and had like a 30-40% chance of hitting the ball off. For the eliminations we just switched to the robocoach driving the robot forward backward right left and its much nicer
Agreed, providing that
What kind of range/reliability did you have with that approach? I’m assuming that you had commands like “Drive forward for N loops” and repeatedly had to press the button.
I dont take any of this as an attack to my work, because i am completely aware that it is borderline legal/illegal. The reason we have it like this, though, is that we can justify that it does the same action every time, which is store a specific number to a variable, push that variable onto the stack, and then wait a half a second so that the robocoach doesn’t inadvertently set invoke another press due to the nature of the IR signal.
We do realize the potential problems, and have backup code that does exactly the same thing, its just a bit riskier. the theory of this mode is the coach has 4 buttons, a1 a3, b1 b3. a and b are the different sides of the fields, and the numbers are the positions of the balls. the robot defaults to a2 b2, until the robocoach sends it a command that alters its default.
how do you drive it while still remaining within the rules?
Of course! Sharing is great.
I can’t wait to see all the neat stuff other teams have to offer at the CT Regional.