diff --git a/source/docs/software/commandbased/pid-subsystems-commands.rst b/source/docs/software/commandbased/pid-subsystems-commands.rst
index bd5bdd8bf6..e0689bf9bb 100644
--- a/source/docs/software/commandbased/pid-subsystems-commands.rst
+++ b/source/docs/software/commandbased/pid-subsystems-commands.rst
@@ -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.
diff --git a/source/docs/software/commandbased/profile-subsystems-commands.rst b/source/docs/software/commandbased/profile-subsystems-commands.rst
index cfa21cb119..5bf4c000e5 100644
--- a/source/docs/software/commandbased/profile-subsystems-commands.rst
+++ b/source/docs/software/commandbased/profile-subsystems-commands.rst
@@ -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.