During the explanantion of the game some of Woodie’s friends showed off their nifty robot that lobbed balls. They said in the explanation that they wrote a program which utilized the optical sensors and the retroreflective tape to track and target the goals. Does anyone know if that program really works, and if so, how? Woodie said it was only a few lines of code…
Cheers,
Matt Sorgenfrei
I’m really not sure of this, but I think that the program that was a few mere lines of code was the contraption that pointed itself at the goal as he moved it around. The magnet-looking ball lobber that Woddie’s buds made looked to be aimed manually. It would be possible to triangulate the goal’s position by using the reflection of the tape near the top of the goal and the strip around the upper platform - u have your three points and then that trig starts coming back to haunt you 
Woody’s pals wrote code to use the optics to make a sextant, calculating distance and angle using sine-cosine math and then calculating force necessary to lob the balls. Pretty neat trick, if you ask me.
it would probably be quite hard to calculate the trajectory and the force required to launch the balls into the goal. As Woodie said, each ball is inflated differently, so each ball would travel through the air a different way.
*Originally posted by XRaVeNX *
**it would probably be quite hard to calculate the trajectory and the force required to launch the balls into the goal. As Woodie said, each ball is inflated differently, so each ball would travel through the air a different way. **
I heard Woodie say that too, but in the Game PDF file, in big bold italic, it says (under 1.2.2) that “Balls will be inflated to manufacture’s specification for pressure.” I dunno if Woodie just accidentally slipped that out or what. If they’re all inflated to the same pressure, they should all be the same size too.
And I dunno about the hard math in programming a ball-shooter, you need to triangulate distance to goal, then figure out at what angle and with what velocity to shoot the ball out with some easy physics. I’m not saying I could program that by any means, just the math/physics 
Woody said that at the competitions the balls will all be inflated correctly, but at kickoff they just kind of pumped them up enough to not be flat and stuck them on the field.
- Travis
Well, no matter how well these balls are regulated for pressure, they ALWAYS be slightly different due to temperature, wear of the game, and any other out of round issues. I don’t know what the specifications of a #5 soccer ball is, but I suspect that it isn’t anything like a precision ball bearing.
As for other varuation, just think of the varying friction of their surfaces as they are used more. Thier new shiny covers will get dusty, scratched and marked as robots pick-up, scoop-up, run over, dribble, roll, and otherwise “fold, spindle and mutilate” the balls during a match.
(yes, I know, you can’t damage or destroy the playing field…but I’m talking about normal wear and tear…as you see with real soccer balls after they are broken out of their store packages.)
I love the idea of a ball shooter…but…
The code that Dean, Woody and Eric referred to was the code controlling the device on the back podium that was using the light sensors to follow the goals. It was just created to show that the light sensors were indeed capable of following the goal. I didn’t hear them say anything about it being used in the robot that shot balls, it looked to me as if that robot was seperate from Eric’s light sensor array and was able to get balls into the goal simply because the people who set it up knew where to position it. I believe the magnet-robot was just demonstrating an example strategy and an interesting use of one of the new motors, but I could be wrong, it has happened before - as those of you who saw me being the ref at the rookie workshop know. 
The code was written by Eric Rasmussen who works in the engineering department at FIRST. He said it was only a few lines long, and that he would make it available via the FIRST website sometime following kickoff, so look for it on their site in the next few days.
Other information about programming the robot can be found at the robotics section of InnovationFirst’s website at:
http://www.innovationfirst.com/FIRSTRobotics/
If you are looking for other pre-made programs, they have a few good examples in their White Papers section.
--Chris Casinghino
Team 131, CHAOSYou could write a program to follow the goal, and use a yaw-rate sensor (i think that’s it) to track the angle going side-to-side. You can either have an independent turret, or when you are ready to launch, have the robot position itself so it will fire in that direction. If you have a set angle for the launch, say 45 degrees going up, you can use the distance found to figure out how long to launch it. The code shouldn’t be that difficult.
BTW: the goal is big enough where normal wear shouldn’t affect any shooting.
I think the trick is controlling the angle of the sensors with servos. Since you tell the servo what angle to go to you must already have the angle that it’s at tucked away in some convenient variable. Then it’s just triangulation for the distance and either a constant multiplier or a lookup/lookdown to adjust the force. I’m not sure of the relationship between power in the thrower and distance for the balls - a lot probably depends on the style of thrower. I’m trying to convince my team to make a trebuchet, but they tell me they actually want to have a chance - bah - who needs victory when you have style
Our team had the ball launching discussion today (to launch or not to launch), and although we specifically told them not too, they brought up a lot of interesting technical issues. (I guess they’re already engineers, in a way, <sniff> <tear> I’m just so proud of those kids.)
Anyway, someone mentioned that, as your battery power varied, your ball velocity would as well.
Just something else to add to your three lines of code.
It would be very possible to use the optical sensors to judge distance for a ball launching robot. It would take quite a bit of testing to get the numbers right in the program but it can be done. You might have to alter the numbers slightly because the balls will wear but that isn’t too big of a deal. I am not that experienced but I would be glad to help any one in some of my spare time try to write some code for for the ball throughing bot.
So far as battery voltage changing your throwing motor speed…no problem. You have that “magic” custom PCB this year…all you need to do is build a circuit that measures RPM and allows the stamp to get feedback on actual motor speed.
As battery voltage falls, the stamp can simply use this feedback loop to pump more voltage to the motor to keep the speed constant.
But my big issue with the friction thrower is simple ball friction changes due to scuffing and dust/dirt as the matches move on.
I bet the friction will change as much as 50% as the day goes on. :mad:
If anyone remembers back to the P&G Sunny Delight machine, you’ll notice that robot didn’t use a friction wheel. It had a thrower arm, I believe it was spring loaded, much like a catapult. With a mechanism like that, neither ball surface, ball roundness, ball size, nor battery voltage will have a noticeable effect on the trajectory.
Just a thought.
So what’s the deal with custom electronics this year? I heard something about it at kickoff, but I’ve been unable to get the correct documents off FIRST’s site. For some reason, the “Robot Rules and Specs” Document is missing all of the electronics stuff.
I think that it’s great that we can make custom electronics, though. One of the things I lamented most last year (my first) was that electronics design was under-represented in the competition.
Now if only they’ll give us a 30 second autonomous period at the beginning of the game…
Hey hey! they fixed it. Documentation’s back up in full.