I know this thread is a solid year old, but since it has been bumped and people are reading it...
Quote:
|
That being said, I've really wondered what it is like to be one of the programmers, I'm just glad I'm not one of them, as our team is very evil to them and gives them about 3- days to program the thing.
|
This post isn't directed at you specifically, it is hopefully directed at team leaders who have the power to allocate people's time: PLEASE don't do this.
At the very least, try to plan so that the programming team has access to the RC, OI, sensors, batteries, and other electronic kit right up until they are installed on the robot. At the very least that enables the programmers to make sure that their outputs make SOME sense given certain inputs, but there is really no substitute for on-robot testing. Most of the components the programmers need to test with are mutually exclusive from the mechanical components of the robot, so they can have their own special box.
If the programming team is already using the robot testing something and you have something to do, ask them what they're doing. If they are testing or implementing something vital (arm control, autonomous modes, drivetrain) and you're there to tighten bolts or something, ask yourself "do I want to sacrifice an autonomous mode for $TASK?". If the answer is no, then let them do their thing. For some reason or other, programmers always seem to at the bottom of the robot-access priority list. I've been delayed from autonomous coding and camera testing because bumpers needed their bolts tightened.
Without fail, every year since stack attack (2003) I've been asked/told both as a student or a mentor "Why wasn't that tested?" "Why don't WE have a killer autonomous mode" "What was that bug?" "It was the programmer's fault" "Why was the old version still on the robot?". Programmers cannot program correct programs without testing. Testing doesn't mean turning the robot on 5 minutes before a match (at that point, you're already doomed, especially with the slowness of IFI Loader). Whether at a competition or during the build period, programmers need time with the robot to make sure everything works.
There aren't many ways the robot software can fail that DON'T doom you in a match. Your robot might be uncontrollable, it might not move, it might ram into a wall real hard. Motors might turn in ways that software safeties were supposed to stop them from turn. Autonomous mode might not work. Your scoring thingy (arm/shooter/capper) might not work or break itself.
So, reader, if you're in a situation where you have to decide whether to build for one more day or give the programmers the robot for a day, please give that day to the programmers.
If that is impossible: At the very least, make a set schedule and say that "builders build from 8:00 - 11:00, then programmers get it all lunch with no-one bugging them". You won't believe how much more productive everyone is when there aren't builders coming in every 5 minutes tightening, measuring, mounting, and moving things. Every time someone comes in, we've potentially got to shut the robot down, move computers, unplug cables, and then put everything back. That is wasted time for the builder, and wasted time for the programmers. If people are coming in all the time, then that scarce minute/hour/day you've given the programmers to get things done is being wasted.