not sure, but likely involves the accelerometers, YRG and camera combo, along with a host of physics calculations
3)reasonably accurate, but our final version (which is of higher quality) hasn’t been built yet, so i cannot say for certain
I’m going to go against the trend here and post about a 1-pointer robot…
We’re a rookie team, with not quite the same experience, materials, or tools as more veteran teams. We figured that it was best to have a simple design that we could build for competition then a complex design that we might not get done in time for ship.
Suck up balls easily and efficiently, then be able to spit them into a goal in exactly the same manner.
I’ve created a discussion thread for our 2006 bot here:
So feel free to ask additional questions there as well.
We’re mainly planning on using the camera along with angle-adjustment in our launcher.
Our prototype worked well, but had nothing to do with the camera. I’ll post some test results and/or videos once we get there. May be a little while…
Yes, we have a launcher (one wheeled). We are changing speed while maintaining a constant angle (we likely will be able to change this angle between matches).
The angle of the camera from center (based off the servo pwm values) is run through a series of equations to determine ~desired speed (we did not factor in air resistance) and to rotate the shooter to the correct heading. These equations are done in a spreadsheet outside of the program and the final values are just put into a lookup table in the program.
A banner sensor is being used to measure the speed of the wheel so that we can maintain a certain speed rather than pwm, accounting for battery voltage changes.
The shooter can also be changed from auto tracking mode to manual tracking mode, where the 2nd driver uses a joystick and 4 push buttons to control direction of the rotator and desired speed (this speed is displayed in the user byte on the OI).
From the tests we’ve done, accurate provided you give it enough time to get back up to speed after each shot. We have not tried shooting in a goal since we completely finished all the bracing on it, so it should be even more accurate now.
I do not know how well anything in answer #2 works, we have to actually finish it and test it to see that.
It’s amazing to me as a rookie mentor for a rookie team that many of our initial concepts were dead-on with what many of the experienced teams seem to be building. So, I’m thrilled that our thought processes were on the right track.
Being new, we felt we didn’t have the experience or organizational structure yet to successfully execute our initial concept within the given time constraints. So, we’re sticking with a corner scorer, and ramp climber!
We felt that if we tried to engineer and build a shooter as well as a good pickup design, etc., that we would end up being a “jack of all trades and master of none”, and we didn’t really like that thougt too well. Instead we
Built the most robust drivetrain that i have ever seen on a robot, and a ball harvester style pickup that probably will run on one of the big CIM motors.
If you’ve spent a cumulative 12 kid-years in Little League, it didn’t take any prompting…
We set out NOT to build a wheel launcher at first, mostly because we wanted to do something different. After going through the issues of energy management, ease of construction, and packaging, the single-wheel launcher won. I want to see someone using a twin-belt launcher, though, as I still think it will be more repeatable. I really want to see a pneumatic catapult or kicker!
I am working on a more complex method now for the thing to be quicker, but we have had 90% accuracy from calculating the angle, moving to an ideal location (which in itself is about no more then 20 lines) and in 3 lines shooting the thing… so in a bit less the 25 lines I’ve made an autonomous that can shoot about 4 of the balls (but then again a few of the lines are calling functions from other files…), with 90% accuracy within the 10 sec frame.
I brought this idea up right after we saw this year’s game. I proposed a twin-belt design with a belt on the top and bottom, the top belt moving slightly slower than the bottom belt, giving the ball a slight backspin and thereby more long-range accuracy. But, alas, this idea was hacked immediately due to the (percieved) high design time with few advantages gained. I really would like to talk to someone from a team that prototyped something like this, or even better, had it on their robot.