Quote:
Originally Posted by blaxbb
During the season, remember that your main goal (assuming the game is similar to prior years) is to have the controls running so that the controls are natural to the driver.
|
I would like to add emphasis to this point. This is probably the single most important thing for a programmer to realize. As both a programmer and a driver (among other things...) I can tell you it makes a HUGE difference in robot effectiveness. There is a common saying that the three most important things in having a successful robot are 1) Drivetrain 2) Drivetrain and 3) Drivetrain. Yet a drivetrain is useless without driver skill, so I would propose that the two most important things are 1) Drivetrain 2) Driver Practice/Skill. Good programming can take a mediocre driver and make them good, or a good driver and make them amazing. Bad programming will not enhance a driver's natural abilities, and may even make them worse. Essentially, it can take the place of practice time and make the practice the drivers do have more effective.
This doesn't only go for drive systems it applies to game piece manipulators too; case in point, in our last two matches at VCU, when we finally got our arm working using a thrown together control method we scored, I believe, one ringer (part of that was a drivetrain problem stemming from a broken wheel, but the point still stands). At Palmetto, with improved algorithms we scored 3.5 per match (this is an actual number determined from our actual matches, not inflated conjecture; however, it does not include our first two matches when loose wires kept us from being able to score. But, since our lack of scoring in those matches has nothing to do with control, more like wiring sloppiness, those matches are irrelevant to the statistic in this use).
At Battle of Baltimore, I believe we scored at least 6-7 tubes in the first quarterfinal (I don't know exactly, I don't remember that match too well. 1089, the other scorer on the alliance, was pretty much neutralized by a double-teamed defense the entire match and yet the alliance still ran out of tubes in the player station. So, we must have scored quite a few) All along our robot was the same (actually, our turret broke at BoB, so it was scoring more even partially disabled and with a new, inexperienced base driver); yet, there is a big difference between 0-1 and 6-7 tubes. All of that was control algorithms and practice. (Actually, I expect that we could probably score up to nine tubes in two minutes if our turret was working and our controls were refined just a bit more)
Anyway, the effect of good programming can be huge. My first year as a driver our programmer (this was before I learned C and became a programmer myself) wouldn't listen to my requests for control changes and such, believing them unnecessary. Don't do this. Period. Autonomous is ten to fifteen seconds (usually), and teleoperated is one-hundred and twenty seconds. Don't shortchange the driver. If the driver wants a control change, listen to them. If you think a different method might make it easier to drive, suggest it and let them try it out, but do not force a certain method upon them. Your basic goal is to (as cheesy as it sounds) make the robot and the driver work in harmony, not opposition; to make operating the robot feel to the driver as natural and easy has operating their own feet and hands. If you reach that goal, even if the robot lacks an autonomous mode of any kind, I would say you've reached the pinnacle of FIRST robot programming.