Should a programmer be a driver too?

[FoleyEngineer]

What's your opinion about having your lead programmer also be a driver? We have someone who has driven in the past and has done well. However this year is our lead programmer. Can someone do both jobs well? If you've done this, how did it work out? Does the complexity of this year's control system affect that?

Thanks!

[GBIT]

Well if it is anything like having a lead mechtite as driver it should be no problem. for 2 years now i have been a major mechtite as well as lead driver... and i have found no issues with it....

[RyanN]

If they're good at driving, then let them drive, especially if he/she is up to driving and programming! In fact, I think it works out better having someone that has a lot of knowledge run the robot. They know the limits of the machine more than anyone else.

[Kimmeh]

We're doing that this year. Our lead student programer is also our best driver. He's said it can be a little stressful at time, but it's worth it to be able to experience the code first hand and know exactly what it's doing on the field. It's much harder to have to explain the problem to someone else. Once he comes off the field, he's back in the pits fixing the code.

At our meeting tonight, he admitted that he changed the code between almost every match. And the robot did indeed drive better. =]

[Jetweb]

I have seen it work great many times. I would even venture a guess that over 50% of drivers are programmers.

One success case that comes to mind is Qbranch on 1024 in 2008, took the robot all the way to Einstein and had one of the best autonomous routines of the year. ( of course he may be part robot himself so Im not sure if that is a good example )

[Brdn666]

I'm the programmer and the driver. It's great because if there's a problem with driving, I know where and how to fix it.

[KF987]

The arm driver when we won the championship in 07 was our lead programer, he also was the arm driver in 08. (graduated last year

This year our lead programmer is going to be the arm driver too... (new driver)
In some ways it helps to have a programmer as a driver because they can quickly diagnose problems that may come up in a match and be able to better fix the program because they experienced first hand what was wrong.

Just don't let them make the control board.

My .02

-Keaton

[FoleyEngineer]

Great feedback, thanks! My one concern is that our drivers are usually busy with strategy meetings, driver meetings, and of course being in queue and on the field. Normally our programmer works on the code during those events changing what the drivers have requested. How do you do both jobs simultaneously? I'm open to the possibility (that's why I asked), just want to know about how to handle the dual-responsibility. The programmer is really the only team member who knows the code well enough to make changes... just makes me nervous to stretch anyone too thin?

Thanks!

[Stvn]

From my experience, it has been beneficial to have a programmer as one of the drivers. For the past two years, we have had the lead mechanical student as the driver and the lead programming as the operator. Since we have used simple skid steering for the past four years, sometimes with shifting, the method of driving around the robot has stayed relatively the same. As for the mechanism, it is much more game specific. Because it is new every year, the method of controlling it will drastically change with the game.

I actually prefer to have a programmer on the drive team. Though he might not have quite the same grasp of mechanical limitations as the mechanics guy, he knows exactly how it is supposed to move. He has made any code changes and configured all the controls, so he will already know any basic controls or manual overrides. He can make any tweaks he sees.

As well, it's nice to have the ability to trace down and fix nearly any problem on the robot between our driver and our operator. Our "pilots" know what they are doing.

If coding needs to be done on the fly, we can just bring the laptop to queue with us.

But, since I am the programmer, I am highly biased.

[XXShadowXX]

In the past two years we have always had a programmer on the field, which i think is beneficial, because a programmer can spot errors on the field (generally know who's fault it is mechanical/programming), and fix it if it's programming fault.

[Roger]

To add to the general agreement above, one thing is when the robot gets into programming, the programmers have to drive it to test it. While we have driver practice time -- we programmers do share! -- when it gets into the wee hours and that autonomous sequence has to be just so, it helps to have someone just to reset the robot. That person, usually another programmer, gets very good driving backwards!

And while he may deny it, our lead programmer has programmed in "job security" by having all the joystick controls doing things that no adult could follow, or at least I couldn't. We still have a driver test on who is the best.

[popo308]

I am 1625's lead programmer and aux driver. It works out well for us, we have had no problems with it. We had a team discussion about having a programmer in a driver position and the team voted that it would be best for the team to have a programmer be a driver. It gives the programmer a much better idea of how the alterations in the code are effecting performance instead of having a driver try to explain what needs to be tweaked...

So far it has worked out great for 1625.

[GaryVoshol]

Originally Posted by FoleyEngineer

... our drivers are usually busy with strategy meetings, driver meetings, and of course being in queue and on the field.

And you haven't been to a district yet, John. With only 40 teams, minimum match separation has to be set to 3 matches, or else you're playing with/against the same teams too much. For all practical purposes, the maximum match separation is 9-10; it would mathematically average to 40/6=6.6667.

However, many teams don't have the luxury of not doubling up assignments. They just don't have enough team members. My daughter doubled up between Chairmans and pit crew (lead electrical) , with safety captain thrown in. While she didn't get to see many matches on the field, it did mean that she was usually available in the pit to talk with wandering judges. Also it relieves crowding in the pits if the person there can do multiple jobs.

You might consider doubling up someone on scouting as your strategist. It doesn't have to be a driver meeting with the other teams, as long as the strategist knows what your drivers and PS's will be doing. Or your PS could double as a strategist.

[Ryan Caldwell]

We have our 2 lead programmers and one of mechanical guys on the drive team. I don't forsee a problem there. They know the robot well and can fix it in que(bonus).

Our team is a bit worried as our student comander is also on the chairmans presentation group, we have back ups for every possition but its still good to have the A-team in.

[Warren Boudreau]

Originally Posted by FoleyEngineer

Normally our programmer works on the code during those events changing what the drivers have requested.

At least he won't have to worry about drivers asking for code changes. Unless, of course, if he is prone to talking to himself.

My suggestion is put your best driver on the sticks. It's a great advantage when they are also aware of how the robot works. Either mechanically, electrically, or code-ally (couldn't think of a good word for it).