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.

[Akash Rastogi]

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.

[Booksy]

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.

[Meredith Novak]

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 :)

[Nuttyman54]

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.

[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. =]

[hipsterjr]

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!*:p

[Mike Betts]

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

[monty1540]

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.

[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 :yikes: )

[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. :D

[Qbranch]

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: )

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

[GaryVoshol]

... 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.

[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.

[JesseK]

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:.

We wind up yelling at everyone in the pits to go eat because they haven't taken a break all day. Many students get dehydrated because they get caught up in things going on. Even a mentor or two forgets to eat sometimes (doh!). It's not a fun feeling to be rushing through maintenance and competition only to feel faint because you haven't eaten in 8 hours.

Last year we saw huge benefits in letting the mechanical lead do the elevator/etc. This year, the lead programmer is the secondary driver since he knows the most about our radar display, and the primary driver was a key build student who understands how to drive our bot proficiently enough. I believe it is quintessential to success for the drivers to have mechanical and/or coding knowledge of the robot, further than just your typical xbox-style video game. This will allow them to get to know the physical limitations of the bot and figure out ways to push the robot to the limits.

The other option is to put your lead build, integration, or programming mentor out on the field with your students. So long as the student drivers aren't intimidated by an adult who has to speak up loudly in order to be heard over the music & commentator, there are huge benefits to doing this. YMMV though.

[Warren Boudreau]

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).

[usbcd36]

Last year, I was the programmer and the driver, but I was not just the driver because I was the programmer; on our last testing day, I worked on the code and drove the robot for about twelve hours. The guy who was traditionally the driver wanted to drive at competition, and at first, we let him. After one particularly horrible match, we were about to tell him that he wasn't to drive anymore, at which point he told us that he was yielding to me. Unfortunately, it wasn't soon enough to salvage our ranking.

This is why it's essential to have the driver be chosen definitively and to stick to it. It doesn't necessarily have to be the programmer, but it does have to be someone with lots of practice and ability.

[Grant Cox]

Drivers for the Thunderchickens don't have very many rules. Our biggest one is NO drivers in the pit. I'm not sure how it's working out this year, because I've noticed our driver is a high up (if not lead) programmer, but this has always been a virtue. Like you said, the driver's job is to be the driver. That includes doing personal scouting of other teams, watching other teams' driving styles, strategy meetings before each match, as well as often being the personal ambassador to other teams. Those are enough responsibilities on their own. When they start having the pressure of elims plus having to fix the code at blazing speeds, many people will break.

That being said, if they really are your best driver, then it's worth it to give a try. I just feel that it is a level of stress that is often tough to tackle on its own, without added robot maintenance stresses.

[EricLeifermann]

Our drive team doesn't have any programmers on it but all three of them are on the pit crew. I don't see the point of having more people in the pit than needed. The drive team is in the pits before and after matches so why not have them lend a hand in fixing the robot? Plus we have a small team so we need as many people in the stands scouting as possible.

As for the programming person driving, my personal feeling is i don't care if all you did all year was sweep the floor when we were cleaning up, as long as you contributed to something for the team and you are the best driver, you will be driving. Oh you also have to know the rules as well as I do.

[Katie_UPS]

We had our lead (and pretty much only) programmer as our primary driver, but we also had the entire robot done before qualifiers started :ahh:.

[AlexBish_GRR]

on GRR we try not to have a programmer on the drive team because often time they need to code at regional and may not have time to get ready for matches
but thats just are team's 2 cent

-alex

[Enigma's puzzle]

This year we are going to have one of our best mechanical people as axillary operator and the Lead programmer as driver. The programmer has easily spent the most time driving and early in the season showed the most capability and slid into the position by default of being the best person.

The lead programmer i believe will be able to better diagnose programming problems from that position on the field. In years past the driver always ended up being a mechanical person, but as we would come off the field they would explain what they wanted the programmers to do, And it didn't work well.

Where as on our team we have the coach (a student) do all of the scouting and strategy. The coach (formerly me) would then fill the drive team in with all of the relevant information in the cue line. we found this to be a good way to communicate the information and not take people away from there prior responsibilities.

[DonRotolo]

Our lead programmer was the driver last year and this year; he is the best driver on the team. Last year, sometimes he would stop driving to think "gee, what in the code cause that behavior", but we cured him of that right quick. This year it is somewhat better, since we have others who can work on the code instead of the driver - it was a strain last year for sure when he was the 'only' one.

Similarly, our mechanical lead is also on the drive team. This has also worked out well, for the reasons others have stated above.

I certainly have my doubts, since not every student can pull this off, but there is considerable evidence that it is possible, usually with good results.

Don

[Lord Byron]

I'm the programmer for 538, and I'm one of our drivers. This has worked well for us because I can both test the code and practice with the robot at the same time. I also get ideas of how to improve the code during matches, and can usually guess what went wrong whenever we have a problem. All the members of our drive team this year are very knowledgeable in some area of the robot (wiring, mechanics, etc.) so whenever we have a problem, we can usually immediately figure it out. It also keeps crowding in the pits down, because the drive team members and the ones improving the robot are the same. Bottom line, if your programmer can drive, then by all means let him.

As far as lack of time goes, my team went to DC a few weeks ago, and I did all of the programming modifications, next-match scouting, strategy with other teams, talking with judges, and still managed to eat well and spend time in the stands. As long as you don't have to completely redo the programming code, it should be fine.

[HighLife]

Works for us.

[GGCO]

Let the best driver drive. Period.

[keehun]

Let the best driver drive. Period.

I tend to disagree. I am the programming captain and in trial runs, the build team captain was better than me at just pure driving. He is a senior and has been driving a car for years and I'm only a sophomore and I don't even have a permit yet (this summer =P). However, I didn't lag behind much at all but he clearly was a better driver. However, we did more trial run as pairs. The electronics captain (another sophomore) paired with me to be on the try outs. The building captain paired up with another senior, someone who worked extensively on the robot and was a large part of the build team. The electronics captain (http://www.chiefdelphi.com/forums/member.php?u=29578) and I knew each other since 7th grade and we work really well with each other where as our building captain lagged on this part.

We valued the ability to work well together over pure driving skills. After all, everyone is pretty much equal in regards to ability to drive, at least on our team.

We also capped the try outs at a local pre-ship event and Trent (Electronics captain) and I ended up doing best so there you go.

Ability to work together and COMMUNICATE over driving skills. At least in my experience and the experiences of Team 2502.

[EricLeifermann]

I tend to disagree. I am the programming captain and in trial runs, the build team captain was better than me at just pure driving. He is a senior and has been driving a car for years and I'm only a sophomore and I don't even have a permit yet (this summer =P). However, I didn't lag behind much at all but he clearly was a better driver. However, we did more trial run as pairs. The electronics captain (another sophomore) paired with me to be on the try outs. The building captain paired up with another senior, someone who worked extensively on the robot and was a large part of the build team. The electronics captain (http://www.chiefdelphi.com/forums/member.php?u=29578) and I knew each other since 7th grade and we work really well with each other where as our building captain lagged on this part.

We valued the ability to work well together over pure driving skills. After all, everyone is pretty much equal in regards to ability to drive, at least on our team.

We also capped the try outs at a local pre-ship event and Trent (Electronics captain) and I ended up doing best so there you go.

Ability to work together and COMMUNICATE over driving skills. At least in my experience and the experiences of Team 2502.

I agree that being able to communicate is a very valuable thing. But im not going to pick 2 students who communicate very well to be on the drive team if they don't have the skills im looking for. I look for skill and then communication. Communication can be worked on, so can driver skill, but i want my driver to be good at that first. I can work on the communication part, if it is lacking.

[GGCO]

Oh, I totally agree that communication is key, but the drivers can communicate all they want and be horrible drivers. I think that the people who drive should be the ones that know how the robot works the best and who have an ability to think fast and solve problems even faster.

[LilGrohnke2013]

On the FTC team 160, we have a programmer as a driver and a builder (me) I think it works pretty well since then you have two people that know about the robot in different ways, yet both know the robot very well. I think that it should work fine if you have a programmer as a driver there are many benefits.:D

[ttldomination]

Think of it like this. Your programmer will not be programming the robot while someone else is playing a match. So rather than sitting in the stands, he can be driving.

And as far as skill is concerned, the person with the greatest skill should drive. We don't really care, but a human player cannot be a driver. We established that REALLY early. :D.

[Hanna2325]

We have our lead programmer as "coach" during competition, I drive and am on programming and the last programmer is the HP, our shooter is from mechanical. It works out well. The benefit to being on programming and driving is that you have direct control over how things are going to work and while programming you know what seems to work best from a drivers view point. :D

[robox89]

i think that you should have a programer as a driver because then the programer know exactly how the robot has to be set up and if something with the code goes wrong they know wat to do. also it would be great to have a programer in the pit at all times.

[FIRSTgirl675]

Our head programmer is our driver this year and we haven't had any problems with him being driver.

[Chief Samwize]

Last year I was both a Programmer and a Driver. It worked out fine but we did have a whole team of programmers, some of which on the drive team actually (our drive coach and robocoach), ready to go in case they were needed.

-Sam

[Faith]

I'm programmer, operator, and I designed the scouting system/often have to go fix it when somebody does something weird. It is good - I know exactly what to change in the code when I get back to the pit, so it takes half as long as it took last year to fix the problem, because it doesn't have to be explained to the programmers. That leaves me with enough time to check with the scouters and get information for the upcoming matches, and then go work on strategy. Tight schedule, but it works.

Our lead programmer was the driver last year and this year; he is the best driver on the team. Last year, sometimes he would stop driving to think "gee, what in the code cause that behavior", but we cured him of that right quick.
I understand that. I started operating last year, but at that point I was all mechanical/scouting and no programming. This year I am the only programmer, and when we were practicing at home, I would catch myself doing that. By the end of Thursday, though, I was cured of that problem (except during auto).


Just don't let them make the control board.
My .02
-Keaton
I disagree :D. I made the control board last year, and that is part of the reason I operated. I knew the controls inside and out, and no one else really did. This year, I built them again, and it is nice. I have the exact controls I want, and I have them programmed the exact way I want.

[dtengineering]

Regardless of who is the primary driver, I think it is important to have at least one software expert and one hardware (mechanical stuff) expert on the drive team. The software expert can download and modify code while waiting in Queing, while the hardware person can take responsibility for last minute fixes and adjustments.

Since we normally use students in the coaching role (and if you want to discuss that, do it in an exisiting thread... I'm not offering a value judgement here, just stating a fact) that makes it easier for us to cycle through different people in different roles.

I try to always make sure that we have at least two people who can drive the robot competitively... and at least one of them will be someone who will be returning the following year. We will often put the "junior driver" in with the lead driver as coach once or twice per regional, and will cycle other team members through other positions so that many people get a chance to be on the field.

But always, always, always, there will be at least one person who knows the software (often the lead programmer) and one person who knows the mechanial systems (often the lead builder/fixer) as part of the team.

Jason

[pacoliketaco]

over the past for years for 1807, i have been one of the drivers, as well as being the lead builder on our team. this has proved to be very handy when something goes wrong with our robot, and we only have a few minutes to fix it. also i have done the electrical work, which was one of our main problems this year, as pwm cables fell out often (fixed with a lot of tape)

we always have two mechanical people, our programmer (singular), and one of two coaches on our drive team. i think it is essential that teams have drivers that can not only drive very well, but can also fix the robot quickly under pressure.

[Molten]

Regardless of who is the primary driver, I think it is important to have at least one software expert and one hardware (mechanical stuff) expert on the drive team. The software expert can download and modify code while waiting in Queing, while the hardware person can take responsibility for last minute fixes and adjustments.

100% agreed.