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!
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…
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.
This is actually one of the first years MORT has NOT had a lead programmer be a driver. In previous years the programmers in question performed their tasks perfectly and were still great drivers. One of the reasons is because the programmers spend the most time working with and testing the finished robot and drivetrains.
I am a lead programmer/driver. I think it works great. I know the code. I know the low level stuff, what I can and can’t do, and what I have to do to make something happen.
We have a new driver this year and he is one of the programmers. It is nice to have someone who understands the control system.
Our other operator is the business group leader…and that is a whole other question 
190’s operator in 2007 and 2008 was also the lead programmer, and he did an amazing job. It is often extremely useful to have someone on the drive team who knows the programming inside and out and can make quick assessments when the robot is not performing as expected.
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. =]
I’m sure there are great, competent programmers out there, but I would never let our programmers touch the controls lol. They just don’t have the understanding/feel the the mechanical limits of the machine the same way the mechanics who built it do.
I hope Evin doesn’t read this lol, and if he does, GET OFF Delphi and finish the auton!
I have to agree that I am very happy when a driver is chosen from our controls team. They come back from the arena with much more detailed information regarding the problem (example: LED status) and not just “it broke”.
At the same time, when a student becomes a driver, they must move aside and let the other control team members pick up the baton. At the competitions, the drivers should be spending their time between matches discussing strategy, meeting with alliance partners and looking over the competition.
Many students have a hard time letting go. This is especially true if they are the “lead” in some key role such as programming. However, the other team members can and will pick up the slack and do a fine job if given the opportunity.
This is just another aspect of teamwork and individual maturity that FIRST forces on us.
JMHO.
Mike
Our strategy has generally been to try and have people on the drive team that can easily understand what is going wrong if the robot starts malfunctioning. When something goes wrong on the field it’s good to have members on the drive team that know the robot inside and out from both the software and hardware sides. On the hardware side, if something breaks mechanically, you want someone who can understand what broke, and can quickly decide whether the issue necessitates disabling your robot. On the software side too, if part of the software is not functioning correctly, having a programmer on the drive team may allow you to come up with a solution to the issue on the fly, or help the software team understand what to fix when the robot gets off the field.
Looking on towards elimination matches, these experienced people are also the ones you want down at field level so that they can fix any issues in short-order between matches.
In other words, having programmers and fabrication members on the drive team has been our strategy in the past, and has been quite effective/advantageous for us.
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 :yikes: )
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.
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
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!
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. 
Come on, really, there’s no documented proof I was in fact part of the robot… :]
But seriously, I can say that this was an extremely stressful position to be in. You have absolutely zero free time at competitions, especially early in the season as you’re either driving or making code changes or maybe having somebody yell at you to go eat because you haven’t taken a break to eat all day :ahh:.
Also, when it comes to graduation time, remember you’re double-investing in an individual. If your programmer and driver happen to reside in the same graduating team member, you just lost your programmer and driver.
However, there definitely are benefits. You get instant firsthand feedback on your software that affects driving and functional operation of the robot (i.e. autoshifting). Also, during autonomous, you get a great feel for how your robot performs, or if any constants are off a little and need to be edited.
At the end of the day, I’d say the benefits outweigh the costs. If you have any more specific questions I haven’t touched on, I’d be happy to go into greater detail.
Thanks for the compliment, and GO TEAMS!
-q
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.
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.
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.