I am just getting back in the saddle after a great time out in San Jose.
It was a great and terrible tournament. I will not go into all the details here but I did want to just tip my hat to the Cheesy Poofs team #254 (Bionic Poofs if you like the 60/254 merger analogy).
The Cheesy Poofs were the class of the show out in San Jose. They were simply awesome.
Our robot is called the Bionic Poof . I think Kingman’s may indeed by called the Cheesy Bulldog, but you’d have to ask them.
It was pretty interesting on Saturday as the announcer transitioned from saying “The Cheesy Poofs with their robot the Bionic Poof” to just “The Bionic Poofs!”
Thanks for the kind words, it was a pleasure having the opportunity to interact with both the mentors and students of Chief Delphi. You truly run a 1st class organization. It’s to bad we never had the chance to face off, that would have been one to watch! Well maybe we’ll have another opportunity in a couple of weeks!
I don’t have any too dramatic right now, trying to get some of the huge fall out of the video I have, a few others in important matches…updates to follow.
We entered Mario from last year in the Cal Games, under the Cheesy Poofs, as well as the prototype for the new drive base (used on the Bionic Poof). The prototype was entered as Team 252 - The Bionic Poofs.
As a side note the new control system (throttle + wheel) was also prototyped at Cal Games.
The wheel we got isn’t terribly great, but it was really the only one we could find with a game port (its a Saitek, not sure of model number/name). Anyway, its potentiometer doesn’t reach all the way from 0 to 254, and it doesn’t stay centered at 127 (the center moves around at competition, we have to reprogram it), nor is it possible to adjust the pot manually. So to begin, we have in our program constants that define the minimum, maximum, center and dead range of the wheel (it wobbles a bit in the center).
That aside! Initially both sides are fed by the throttle, through some straightening code (if the wheel is centered; the straight code is based on motor encoder inputs). If you want to turn, we take the distance from center and convert it into a percentage (actually a percentage to the min or max), then bring the motor outputs on the side we want to turn to towards 127 by that percentage. If the throttle is low, the percentage is upped by about 25% in order to reverse the wheels on one side and allow a tighter turn. Further, the wheel paddle, when pressed, puts the robot into “turn mode.” Then, the distance from wheel center as a percentage is used to reverse one side and go forward on the other, turning the robot in place (at about 2 rev/s for full speed).
Jay said he prefers tank drive, but the robot this year is too fast and too twitchy to make that possible. When you move at near 15 ft/s, you really need a more forgiving method of control, as well as a way to recognize when you just want to go straight (as that’s really hard with two sticks).
edit: At Cal Games, the distance from center was added directly to the motor value on one side I believe, which wasn’t powerful enough at high speeds and too powerful at low ones. So we switched to a percentage based system and have been generally happy since.
Sorry if I didn’t explain it well enough–PM or IM me if you have more questions .
Basically, when you turn the wheel to the left and push the throttle forward, the right side moves at whatever speed the throttle is at, and the left side is reduced by a percentage equal to the turn percent of the wheel. So if the wheel is turned all the way to the left, the reduction is 100% and the right moves at throttle and the left moves at 0 (really 127 + throttle and 127).
When the wheel is to the right the same thing happens except the right side is reduced and the left side runs at throttle.
At lower speeds, the side that is being slowed down actually goes below 127 to make a tighter turn. The output to the left motors changes linearly from 127 + throttle (wheel = center) to 127 - FAST_TURN_CON (wheel = far left) while the right stays at 127 + throttle.
When the wheel is in the center dead zone, the robot enters straight drive mode, which uses prox sensors to keep the robot driving straight (it curves due to the drill motors).
There are also paddles on the wheel which we use to turn in place. When a paddle is pressed, it powers the 2 sides in opposite directions at a speed equal to the distance of the wheel from center.
Being the base driver and one of the programmers, I’ve had a lot of experience with the steering wheel. I have to say it is a life saver for our robot. The robot is a 6 wheel drive with the center wheel slightly lower than the others and it is uncontrollable with the normal 2 stick tank drive. It drives way too fast and turns way too easily. It took a lot of getting used to, but now I can drive it as well as I could with 2 sticks.
If your robot drives fine with 2 sticks or 1 stick, I’d stay with that. But if you find that it turns too easily and is uncontrollable, a steering wheel is definately the way to go.
Congratulations on (another!) great year! You guys have another outstanding robot.
Our team was fortunate enough to be at the Cal Games this year and we saw the base you mentioned. It is a beautiful thing! We felt real bad when we beat you in finals!
Looks like we may get a chance to see the newest version up close in Atlanta - preferably from the same side of the field!