|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
| Thread Tools | Rate Thread | Display Modes |
|
#16
|
||||
|
||||
|
Re: Should a programmer be a driver too?
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. ![]() |
|
#17
|
||||
|
||||
|
Re: Should a programmer be a driver too?
Quote:
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 .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 |
|
#18
|
|||||
|
|||||
|
Re: Should a programmer be a driver too?
Quote:
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. |
|
#19
|
||||
|
||||
|
Re: Should a programmer be a driver too?
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. |
|
#20
|
||||
|
||||
|
Re: Should a programmer be a driver too?
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.
|
|
#21
|
|||
|
|||
|
Re: Should a programmer be a driver too?
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. |
|
#22
|
||||
|
||||
|
Re: Should a programmer be a driver too?
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. |
|
#23
|
||||
|
||||
|
Re: Should a programmer be a driver too?
Quote:
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. |
|
#24
|
||||
|
||||
|
Re: Should a programmer be a driver too?
Quote:
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). |
|
#25
|
||||
|
||||
|
Re: Should a programmer be a driver too?
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. |
|
#26
|
|||||
|
|||||
|
Re: Should a programmer be a driver too?
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. |
|
#27
|
||||
|
||||
|
Re: Should a programmer be a driver too?
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. |
|
#28
|
||||
|
||||
|
Re: Should a programmer be a driver too?
We had our lead (and pretty much only) programmer as our primary driver, but we also had the entire robot done before qualifiers started
. |
|
#29
|
|||
|
|||
|
Re: Should a programmer be a driver too?
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 |
|
#30
|
||||
|
||||
|
Re: Should a programmer be a driver too?
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. |
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Who should be driver? | markulrich | Rules/Strategy | 28 | 28-03-2008 11:59 |
| new programmer | program1 | Programming | 5 | 24-01-2008 21:54 |
| pic: Too bad it's too late.... | Cody Carey | Chit-Chat | 20 | 31-05-2006 16:54 |
| Serial Driver and 2K6 Encoder Driver Not compatible | Tom Bottiglieri | Programming | 6 | 12-02-2006 01:11 |
| Size of the field: too big? too small? | archiver | 2000 | 5 | 23-06-2002 22:44 |