A command is un-scheduled and has its end(boolean interrupted) method called when either its isFinished() method returns true, or else it is interrupted (either by another command with which it shares a required subsystem, or by being canceled). Its execute() method is then called once per call to CommandScheduler.getInstance().run(). When a command is scheduled, its initialize() method is called once. TODO: replace this graphic with one that isn't wrong This is useful for continuous "background" actions such as controlling the robot drive, or keeping an arm held at a setpoint. Subsystems also can be associated with "default commands" that will be automatically scheduled when no other command is currently using the subsystem. If a new command is scheduled that requires a subsystem that is already in use, it will either interrupt the currently-running command that requires that subsystem (if the command has been scheduled as interruptible), or else it will not be scheduled. this ensures that, for example, users will not end up with two different pieces of code attempting to set the same motor controller to different output values. Resource management is handled on a per-subsystem basis: commands may specify which subsystems they interact with, and the scheduler will never schedule more than one command requiring a given subsystem at a time. Multiple commands can run concurrently, as long as they do not require the same resources on the robot. The scheduler's run() method may be called from any place in the user's code it is generally recommended to call it from the robotPeriodic() method of the Robot class, which is run at a default frequency of 50Hz (once every 20ms). The CommandScheduler is in charge of polling buttons for new commands to schedule, checking the resources required by those commands to avoid conflicts, executing currently-scheduled commands, and removing commands that have finished or been interrupted. How commands are runĬommands are run by the CommandScheduler, a singleton class that is at the core of the command-based library. Commands, including command groups, implement the Command interface. Simple commands can be composed into "command groups" to accomplish more-complicated tasks. Users write code specifying which action should be taken in each state. A command is a simple state machine that is either initializing, executing, ending, or idle. Subsystems implement the Subsystem interface.Ĭommands define high-level robot actions or behaviors that utilize the methods defined by the subsystems. Subsystems allow users to "hide" the internal complexity of their actual hardware from the rest of their code - this both simplifies the rest of the robot code, and allows changes to the internal details of a subsystem without also changing the rest of the robot code. Subsystems encapsulate lower-level robot hardware (such as motor controllers, sensors, and/or pneumatic actuators), and define the interfaces through which that hardware can be accessed by the rest of the robot code. Subsystems are the basic unit of robot organization in the design-based paradigm. The command-based pattern is based around two core abstractions: commands, and subsystems. ![]() ![]() For example, in a command-based program, a user can specify that "the robot should perform an action when a button is pressed": ![]() Thus, the command-based libraries allow users to define desired robot behaviors while minimizing the amount of iteration-by-iteration robot logic that they must write. In declarative programming, the emphasis is placed on what the program ought to do, rather than how the program ought to do it. The command-based paradigm is also an example of what is known as declarative programming. It is not the only way to write a robot program, but it is a very effective one command-based robot code tend to be clean, extensible, and (with some tricks) easy to re-use from year to year. It is a general way of organizing one's robot code that is well-suited to a particular problem-space. "Command-based" programming is an example of what is known as a design pattern. In general, "command-based" can refer both the general programming paradigm, and to the set of WPILib library resources included to facilitate it. WPILib supports a robot programming methodology called "command-based" programming. Table of contents generated with markdown-toc What is "command-based" programming? PID control through PIDSubsystems and PIDCommands.Structuring a command-based robot project.Restrictions on command group components.Recursive composition of command groups.Command-Based Library Screensteps: Markdown Edition
0 Comments
Leave a Reply. |