From ec66be8314f7a8015135bb8a590bc1604f1ea81d Mon Sep 17 00:00:00 2001
From: Ahsan Moin <123082059+ahmoin@users.noreply.github.com>
Date: Wed, 30 Oct 2024 19:42:18 -0400
Subject: [PATCH] Fix Typo in Command and Control Tutorial (#2817)

---
 .../creating-robot-programs/command-and-control-tutorial.rst    | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/docs/software/labview/creating-robot-programs/command-and-control-tutorial.rst b/source/docs/software/labview/creating-robot-programs/command-and-control-tutorial.rst
index 07f56ab517..c2574bd239 100644
--- a/source/docs/software/labview/creating-robot-programs/command-and-control-tutorial.rst
+++ b/source/docs/software/labview/creating-robot-programs/command-and-control-tutorial.rst
@@ -10,7 +10,7 @@ Command and Control is a new LabVIEW template added for the 2016 season which or
 
 Command and Control recognizes that FRC\ |reg| robots tend to be built up of relatively independent mechanisms such as Drive, Shooter, Arm, etc. Each of these is referred to as a subsystem and needs code that will coordinate the various sensors and actuators of the subsystem in order to complete requested commands, or actions, such as "Close Gripper" or "Lower Arm". One of the key principles of this framework is that subsystems will each have an independent controller loop that is solely responsible for updating motors and other actuators. Code outside of the subsystem controller can issue commands which may change the robot’s output, but should not directly change any outputs. The difference is very subtle but this means that outputs can only possibly be updated from one location in the project. This speeds up debugging a robot behaving unexpectedly by giving you the ability to look through a list of commands sent to the subsystem rather than searching your project for where an output may have been modified. It also becomes easier to add an additional sensor, change gearing, or disable a mechanism without needing to modify code outside of the controller.
 
-Game code, primarily consisting of Autonomous and TeleOp, will typically need to update set points and react to the state of certain mechanisms. For Autonomous, it is very common to define the robot’s operation as a  sequence of operations – drive here, pick that up, carry it there, shoot it, etc. Commands can be wired sequentially with additional logic to quickly build complex routines. For teleOp, the same commands can execute asynchronously, allowing the robot to always process the latest driver inputs, and if implemented properly, new commands will interrupt, allowing the drive team to quickly respond to field conditions while also taking advantage of automated commands and command sequences.
+Game code, primarily consisting of Autonomous and TeleOp, will typically need to update set points and react to the state of certain mechanisms. For Autonomous, it is very common to define the robot’s operation as a  sequence of operations – drive here, pick that up, carry it there, shoot it, etc. Commands can be wired sequentially with additional logic to quickly build complex routines. For TeleOp, the same commands can execute asynchronously, allowing the robot to always process the latest driver inputs, and if implemented properly, new commands will interrupt, allowing the drive team to quickly respond to field conditions while also taking advantage of automated commands and command sequences.
 
 ### Why should I use Command and Control?