Changes between Initial Version and Version 1 of ControlSystems/SoftwareTeam/Training/WPILib/CommandBasedProgramming


Ignore:
Timestamp:
Dec 15, 2019, 8:56:52 AM (6 years ago)
Author:
David Albert
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ControlSystems/SoftwareTeam/Training/WPILib/CommandBasedProgramming

    v1 v1  
     1== Command Based Programming ==
     2
     3As our robot programs become more complex, a framework is needed to help keep related functionality together (''cohesion'') while preventing unrelated functions from becoming entangled (''coupling'').  Improving cohesion and reducing coupling are key concepts in software engineering.  WPILib provides a framework called Command Based Programming that helps with this.  You can read about it in [https://wpilib.screenstepslive.com/s/currentCS/m/java/l/599732-what-is-command-based-programming ScreenStepsLive].
     4
     5In command-based programming, we define
     6   * '''subsystems''' representing ''physical parts'' of our robot: intakes, shooters, turrets, drivetrains, etc.
     7   * '''commands''' representing ''activities'' that can be done by one or more subsystem (e.g. throwing a frisbee)
     8   * '''command groups''' represent ''behaviors'': a set of activities that must be performed in a particular sequence (such as pointing a turret at a target, adjusting the elevation angle, and then throwing a frisbee into it).
     9A given activity may require more than one subsystem (e.g. throwing a frisbee might require both the turret and the shooter).  More than one activity can be running at the same time (e.g. the robot might be driving while throwing frisbees).  The Command-Based framework helps organize all of this activity so that multiple things can be happening at the same time without interfering with each other (e.g. preventing two commands from trying to control of the same subsystem at the same time).
     10
     11
     12=== How it works ===
     13Command-based programming is built on top of the !IterativeRobot template. In each of the template's periodic() methods, Scheduler.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.
     14
     15* [https://docs.google.com/document/d/1JHHRGrhe96rJXw6lIM-X3WJKoD14_8PwqjjP45UI0tg/ Intro to Command Based Programming]