Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add more details to control in Command-based articles #2771

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -36,4 +36,4 @@ One of the most common control algorithms used in FRC\ |reg| is the :term:`PID`
:linenos:
:lineno-start: 5

A ``PIDController`` is declared inside the ``Shooter`` subsystem. It is used by ``ShootCommand`` alongside a feedforward to spin the shooter flywheel to the specified velocity. Once the ``PIDController`` reaches the specified velocity, the ``ShootCommand`` runs the feeder.
The ``Shooter`` subsystem holds a ``PIDController`` and a ``SimpleMotorFeedForward``. They are used by ``shootCommand`` to spin the shooter flywheel to the specified velocity. The calculations and motor setting are performed in a lambda expression that is passed to the ``run`` command factory, which creates a command that repeatedly executes the lambda expression while the command is scheduled. This command runs in parallel (using the ``parallel`` command factory) with another command that waits until the ``PIDController`` reaches the specified velocity, and runs the feeder when the specified velocity is reached. This is command is created with the ``waitUntil`` command factory, which creates a command that does nothing and finishes when ``m_shooterFeedback.atSetpoint`` returns ``true``, and the ``andThen`` decorator which runs the feeders when the previous command is finished.
Original file line number Diff line number Diff line change
Expand Up @@ -42,4 +42,4 @@ The following examples are taken from the DriveDistanceOffboard example project

There are two commands in this example. They function very similarly, with the main difference being that one resets encoders, and the other doesn't, which allows encoder data to be preserved.

The subsystem contains a ``TrapezoidProfile`` with a ``Timer``. The timer is used along with a ``kDt`` constant of 0.02 seconds to calculate the current and next states from the ``TrapezoidProfile``. The current state is fed to the "smart" motor controller for PID control, while the current and next state are used to calculate feedforward outputs. Both commands end when ``isFinished(0)`` returns true, which means that the profile has reached the goal state.
The ``DriveSubsystem`` contains a ``TrapezoidProfile`` and a ``Timer``. The ``startRun`` command factory is used, with the first lambda being run when the command is scheduled. It restarts the timer, and for ``profiledDriveDistance``, it resets the encoders; for ``dynamicProfiledDriveDistance``, it sets the initial distances for the left and right encoders. The second lambda passed into ``startRun`` will repeatedly run while the command is scheduled. Inside the lambda, the timer is used along with a ``kDt`` constant of 0.02 seconds to calculate the current and next states from the ``TrapezoidProfile``. The current state is fed to the "smart" motor controller for PID control, while the current and next state are used to calculate feedforward outputs. The ``until`` decorator is used after the ``startRun`` command factory to end the command when ``isFinished(0)`` returns true, which means that the profile has reached the goal state.