How many days do your programmers get with a fully built robot before stop build day?

[Alan Anderson]

What is this "fully built robot before stop build" of which you speak?

TechnoKats programmers get access to the robot regularly during build. Closed-loop control system tuning is often an important part of the robot's ability to perform. In some years, we've actually gone so far as to reserve an entire day each week where software has priority access, and the only "build" work permitted on the robot is to fix hardware problems discovered (or occasionally created) by the software group. The mechanical group gets to keep busy making replacement or upgrade parts, or working on the practice robot.

[bigbeezy]

Do teams have any dedicated "programming only" days? For instance, you say that no matter what the Wednesday before Bag programming gets the robot for the night. No matter the state of the robot, that build day is for programming only.

Kids, well people really, are used to cramming for a deadline. So making an artificial one about a week out tells your mechanical kids that things need to be assembled and electrical that things need to be wired. Not 100% done, not pretty, just functional so that programming can get some of their work moving forward. I haven't done this specifically, but we do use our Week 0 event as this artificial deadline. Basically, we are inviting a ton of people and we need something to show and its the only time when we have our full field assembled. Does it put more pressure on us earlier? Yes, but in doing so we give ourselves time to figure out what things work and where we need to really focus for the final 3 days.

2015 we were really good about getting programming on the robot early and often. Had things pretty much fully operating during week 5. 2016 not so much...

[EmileH]

Here's what I've always tried to do with my team to save programming time while not restricting the mechanical team.

Say it's 2016 and we have two manipulators that require complex programming: an intake with a motor with PID to angle the intake and a catapult shooter powered by surgical tubing, winched down by another motor using PID.

This method does require a few extra mechanical kids in your shop to build these subsystems.

(this would be around week 2-3, once the design of the robot is just about complete and machining has begun)

Prototype both of those subsystems fairly accurately with wood (doesn't have to be exactly like your robot but similar enough that you can test as you would on the real robot), and while your mechanical team is assembling the real robot, use a spare RoboRIO or another set of electronics to get the feel of how those complex subsystems behave and then start writing some software. Doing this will make programming the real thing much easier as you technically can just copy and paste the software and make minor tweaks.

The reason we never prototype drivebases is because they're always the same...tank drives are quite simple to program, and you can use the same code every time you need to use a tank drive. The only instance in which a drivebase would be prototyped would be if it's a holonomic or a complex system (swerve, kiwi, mecanum, etc.)

[GeeTwo]

If our programmers needed a fully built robot before bag day to get any work done, we'd just sit there on the carpet.

They usually have a couple of days with a fully built (though subject to change) drive platform around week 4, but now that we're building two robots, we're tweaking our manipulators right up to competition. In 2015, we were "fully built" before bagging. In 2016, the key pneumatic cylinders for our launcher had not yet been received at bagging - they absolutely were installed on the competition robot on Thursday.