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

[SoMe_DuDe904]

Originally Posted by JonKiddy

Hello. I'm the lead programming mentor for Team 4930 and I'm looking for some advice. Our team isn't using any formal methodology/model for programming but I'd like to introduce students to Agile/Waterfal/Scrum/etc. However, after thinking about it some more I've realized that none of those may work due to how our team builds the robot.

We have a design team that CADs the robot, a mechanical team that puts it together, an electrical team that wires it up, and then the programming team does it's thing. Well, in reality it isn't that simple, usually the programming team gets the robot on the last Saturday before stop build day and it becomes a "get it working!!" day, rather then a real workflow. Most of that day ends up being an electrical/mechanical QA session done by the programmers; talons aren't on the stated channels, wires aren't connected, etc. Then a rush to deliver a programmed robot after QA. After stop build day more programming sessions occur without a robot until our first competition. This is where we really do the majority of the programming, but I'd rather be testing on our robot before we see if it works at competition.

I'm guessing this is normal? How much time does your programming team have with a fully built robot before stop build day?

This sounds pretty normal for most teams. I know my team likes to build a shadow bot along side the main bot. This allows them to tweak code and play with it as the students are building the robot. They also then have something to mess with in the dead time between build and competition.

I know this isn't conducive to teams with minimal funding or newer teams that are just trying to put a working robot on the floor. If that is the case, then you really want to aim for a design early in the process that will give your programmers 4 days to a week with a fully functioning robot and multiple weeks with bits and pieces (assigning channels and IO, playing with motors and pneumatics, ect.). Programming is super important to the success of the robot.

[MamaSpoldi]

Originally Posted by JonKiddy

We have a design team that CADs the robot, a mechanical team that puts it together, an electrical team that wires it up, and then the programming team does it's thing. Well, in reality it isn't that simple, usually the programming team gets the robot on the last Saturday before stop build day and it becomes a "get it working!!" day, rather then a real workflow. Most of that day ends up being an electrical/mechanical QA session done by the programmers; talons aren't on the stated channels, wires aren't connected, etc. Then a rush to deliver a programmed robot after QA. After stop build day more programming sessions occur without a robot until our first competition. This is where we really do the majority of the programming, but I'd rather be testing on our robot before we see if it works at competition.

I'm guessing this is normal? How much time does your programming team have with a fully built robot before stop build day?

Our goal is always to have the robot functioning about a week before Bag Day, but... this rarely happens. In the last few years the software group has gotten the robot anywhere from 1 to 4 days before bag day. But often we are able to get in some testing of individual mechanisms as they are completed. This comes from working cooperatively with the electrical and mechanical teams. Or more specifically, from everyone realizing that by working together we get a better result that benefits the whole team.

Realistically, assigning channels to devices is generally the least of your worries. Changing the device channel is a simple task, the testing of more complex algorithms for controlling mechanisms with sensors, etc. require more time with an actual mostly-functioning robot. The first step in tuning our control systems requires system ID data to be gathered. This is a non-optional step in allowing the code to be properly implemented and mechanism to be properly controlled. And this data cannot be gathered without a functional system.

But this does not mean that the programmers just sit around doing nothing until it is built. You don't have to wait until the systems are completed to talk to the designers about how it is expected to work and begin working on the code that will control them. Certainly many constants, etc will need to be defined and/or tweaked after the robot is ready but there is a large amount of coding that can be performed in the meantime. For example, the classes for each mechanism are defined and implemented with the framework for the control system expected including options for calculating the components that will be used as part of the control system (e.g. previous position values, velocities, and accelerations). Yes, it is often true that while we are writing code for the expected mechanism the entire idea is scrapped and re-designed which often requires the software to be mostly or completely re-designed as well but the original effort is still a helpful learning experience especially for novice programmers.

[GreyingJay]

How many days?? More like how many minutes

We were just about able to finish the robot before bag and tag, so the software team had very little time with the finished robot before it went into the bag (literally minutes). However, the practice robot was finished a couple of days after that and the software teams had several days, shared with the drive team, to practice and optimize code. And throughout the build season, the teams had many weeks of access to a driving Kit of Parts chassis (but only a stand-in manipulator bolted on).

We made things a bit easier by dividing the software into functional chunks.
- basic driver and manipulator control, using the Java Command Based Robot - team of 3 students
- autonomous commands, sensor fusion and calibration (gyro, encoder PID etc) - team of 3 students
- pan/tilt servo control of on-board camera for vision tracking - one student
- Raspberry Pi running our custom TrackerBox software for target tracking - team of 4-5 students

This division of labour allowed groups to work without everyone needing to use the drive base at the same time. It wasn't perfect, of course, and we will adjust for next year. There was a mad dash at the last minute to do "systems integration" and combine all these products into one, final piece of robot code. This is where we way underestimated the time needed. We were actually still scrambling to integrate our software well into qualifications during our first regional at GTR Central. All our practices, and the start of quals, we were actually still running our hastily written "test" code which had none of the autonomous or vision code. Between matches we would deploy our integrated codebase and continue debugging it.

By Q22 we finally had it functioning, and the students made the (wise) decision to lock it down and use what we had for the rest of the weekend rather than risk additional "live" system testing and tweaking. Between GTR Central and North Bay we spent many hours fine tuning the robot code further, including adding and tweaking all our autonomous routines.

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