Changes between Version 11 and Version 12 of ControlSystems/SoftwareTeam/Training/WPILib/CommandBasedProgramming

Timestamp:

Feb 23, 2020, 3:31:41 PM (5 years ago)

Author:

David Albert

Comment:

--

ControlSystems/SoftwareTeam/Training/WPILib/CommandBasedProgramming

@@ -11 +11 @@
 === Creating a Command-Based Program ===
 Create a new project in VSCode (WPILib Icon->Create a new project->Template->Java->Command Robot).  Notice that in the project src folder, addition to the Main.java and Robot.java we're used to seeing, the project also has: [[Image(CommandBasedFiles.jpg,align=right,margin=10)]]
-   * RobotContainer.java - where the subsystems, commands, and button bindings are defined
+   * !RobotContainer.java - where the subsystems, commands, and button bindings are defined
    * Constants.java - where global constants are defined (e.g. motor controller addresses) - may be called !RobotMap
    * commands folder - where your Commands will be stored
@@ -110 +110 @@
 }}}
 
-RobotContainer.java:
+!RobotContainer.java:
 {{{
 package frc.robot;
@@ -170 +170 @@
 
 === How it works ===
-Command-based programming is built on top of the !TimedRobot template. In each of the template's periodic() methods, !CommandScheduler.getInstance().run() is called. This takes all currently running Commands -- which behave like threads, but can't include waits like typical threads because it's a type of threading known as "cooperative" multitasking -- and runs them, first initializing any new ones and checking whether each one has completed yet. It's useful because these Commands can be easily joined together in CommandGroups to make autonomous modes, or can be mapped to buttons to easily allow complex teleop actions, etc.
+Command-based programming is built on top of the !TimedRobot template. In each of the template's periodic() methods, !CommandScheduler.getInstance().run() is called. This takes all currently running Commands -- which behave like threads, but can't include waits like typical threads because it's a type of threading known as "cooperative" multitasking -- and runs them, first initializing any new ones and checking whether each one has completed yet. It's useful because these Commands can be easily joined together in !CommandGroups to make autonomous modes, or can be mapped to buttons to easily allow complex teleop actions, etc.
 
 * [https://docs.google.com/document/d/1JHHRGrhe96rJXw6lIM-X3WJKoD14_8PwqjjP45UI0tg/ Intro to Command Based Programming]