![]() |
Re: Should a programmer be a driver too?
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 |
Re: Should a programmer be a driver too?
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. |
Re: Should a programmer be a driver too?
Works for us.
|
Re: Should a programmer be a driver too?
Let the best driver drive. Period.
|
Re: Should a programmer be a driver too?
Quote:
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. |
Re: Should a programmer be a driver too?
Quote:
|
Re: Should a programmer be a driver too?
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.
|
Re: Should a programmer be a driver too?
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
|
Re: Should a programmer be a driver too?
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. |
Re: Should a programmer be a driver too?
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
|
Re: Should a programmer be a driver too?
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.
|
Re: Should a programmer be a driver too?
Our head programmer is our driver this year and we haven't had any problems with him being driver.
|
Re: Should a programmer be a driver too?
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 |
Re: Should a programmer be a driver too?
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.
Quote:
Quote:
|
Re: Should a programmer be a driver too?
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 |
| All times are GMT -5. The time now is 00:56. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi