So in the Iterative Robot template, There is a lot of pre-made code, as shown below:
public class Robot extends IterativeRobot {
final String defaultAuto = "Default";
final String customAuto = "My Auto";
String autoSelected;
SendableChooser<String> chooser = new SendableChooser<>();
@Override
public void robotInit() {
chooser.addDefault("Default Auto", defaultAuto);
chooser.addObject("My Auto", customAuto);
SmartDashboard.putData("Auto choices", chooser);
}
@Override
public void autonomousInit() {
autoSelected = chooser.getSelected();
// autoSelected = SmartDashboard.getString("Auto Selector",
// defaultAuto);
System.out.println("Auto selected: " + autoSelected);
}
/**
* This function is called periodically during autonomous
*/
@Override
public void autonomousPeriodic() {
switch (autoSelected) {
case customAuto:
// Put custom auto code here
break;
case defaultAuto:
default:
// Put default auto code here
break;
}
}
/**
* This function is called periodically during operator control
*/
@Override
public void teleopPeriodic() {
myRobot.setSafetyEnabled(true);
while (isOperatorControl() && isEnabled()) {
Timer.delay(0.005); // wait for a motor update time
}
}
/**
* This function is called periodically during test mode
*/
@Override
public void testPeriodic() {
}
}
This may be a lot to ask, but can someone explain what each does?
For example:
- What are those Strings and “SendableChooser” variables for?
- Why does TImer.delay need to be in the teleOp Periodic
And finally, if I wanted to put code for something other than the drivetrain in the TeleOp Periodic, would I want to put it within the while (isOperatorControl() && isEnabled()) ? Or leave it outside the while loop? Furthermore, do i need to put the Timer.delay outside the while loop?
The strings and SendableChooser variables are for interoperability with the FRC Dashboard software; in this case, they let you transmit and receive the selected Autonomous routine to run (which lets you Choose what auto runs before each match, and Send it to the robot). The “Autonomous Selector” drop-down is in the Basic tab of your FRC Dashboard software; adding strings to it during robotInit() will allow you to choose those as options, which gives you more selections for autonomous behavior (ie. different routines for different starting points, different overall behaviors, etc.)
Timer.delay() needs to be in the Teleop Periodic for the Drive Safety Config system. The software itself has a built-in safety system in the Robot Drive subsystem so that it will disable (send the dead-stop PWM/CAN signal to the motors) if the call to teleopPeriodic() or autonomousPeriodic() takes too long to complete (ie. if the code crashes). Putting in a short delay ensures that the motors have a chance to run a bit if the loop is too short to start the safety timer. This is what the line myRobot.setSafetyEnabled(true); does.
Finally, if you put in code that moves the robot based on user input, it MUST be inside the while (isOperatorControl() && isEnabled()) {} block, since otherwise the robot will be disabled, and user-operated movement will therefore be illegal (and dangerous). The Timer.delay() is inside the while-loop for the reason mentioned above.
My question for you is, why are you just getting into coding now? Bag day is tomorrow…
We’ve been coding for a week now, but we simply ignored the pre-made code. I was just curious about its purpose.
Plus, we’re having a last minute coding session tomorrow until stop build time 
Take it from experience:
NEVER. PUT. OFF. CODE. UNTIL. THE. LAST. MINUTE.
I mean, it happens every year (somehow :rolleyes: ) but at least we get a start on it much earlier, mocking up code and unit-testing until the robot is there to be tested on.
I’ve essentially always used LabVIEW during robots, but the language is secondary to the purpose of the code itself. If you can break up the programming and intersperse it into the building and wiring process, then you can start checking off components of your robot as “tested”.
Right now, we’re at the point where all we need to test is the climber, autonomous (we don’t have a half-field to practice on, or the space to mock one up), and vision target acquisition (which we’re putting off until Tech Day to tweak our vision code). All of this code is implemented and in our build, but it’s effectively non-functional until we can verify it and modify the numbers.