Quote:
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.