some more changes

Author: DriverStationComputer

docs/section-3/basic-control.md

@@ -1,7 +1,7 @@
 Now that we know the electronics on the robot, how do we actually control them? This section will provide a general overview, so if you want more details look in their respective javadocs and documentation.
 
 ## Motor Controllers/Motors
-Typical motor controllers that you will be using are Spark Maxes and Talon SRXs. Their respective class names are `SparkMax` and `WPI_TalonSRX`. There are other types of motor controllers. If you wish to know more about other motors, you can always look at their documentation. The information provided here should be present in all motor controllers.
+Typical motor controllers that you will be using are Spark Maxes and Spark Flexes. Their respective class names are `SparkMax` and SparkFlex`. There are other types of motor controllers. If you wish to know more about other motors, you can always look at their documentation. The information provided here should be present in all motor controllers.
 
 ### Creation
 
@@ -15,7 +15,7 @@ SparkMax motor = new SparkMax([insert port number], MotorType.kBrushless);
 
 The two motor types: `kBrushless` and `kBrushed` require the controller to power the motors in different ways, and you can end up destroying the motor by using the wrong motor type. The easiest way to tell the difference is that brushless motors use three wires while brushed motors use two. Most of the motors we will use with SparkMaxes are brushless.
 
-Lib199 is a repository which contains many methods and objects we reuse over many projects and years. Now let's use lib199's MotorControllerFactory methodto create the SparkMax
+Lib199 is a repository which contains many methods and objects we reuse over many projects and years. Now let's use lib199's MotorControllerFactory method to create the SparkMax
 
 ``` Java
 SparkMax motor = MotorControllerFactory.createSparkMax([motor id], MotorConfig.NEO);
@@ -52,7 +52,7 @@ Generally most motors will have the following methods. You can always go to thei
 ### Debugging/Updating
 - Motors have LED lights signifying their current status. You can find them on their website.
 
-    - [SparkMax](https://docs.revrobotics.com/sparkmax/status-led)
+    - [SparkMax](https://docs.revrobotics.com/brushless/spark-max/status-led)
     - [SparkFlex](https://docs.revrobotics.com/brushless/spark-flex/status-led)
 
 - Other than javadocs, these websites provide more information on installation of motor controller (Senac's job)

docs/section-3/subsystems-and-commands.md

@@ -63,7 +63,7 @@ Subsystems are where much of the logic of the code is stored. In each subsystem,
 Commands are sections of code that define general actions taken by the robot. Usually, they don’t contain detailed code about the function of the robot’s mechanical parts, such as how far a motor turns or its direction (these finer details are usually placed in subsystems, which commands then reference to give function to each of the robot’s mechanical components). Instead, commands code for actions taken by the robot’s mechanisms. Examples of these actions could include lifting an arm or turning wheels that intake a game piece. Command classes also have methods `initialize()`, `execute()`, `end()`, and `isFinished()` that serve as a base foundation (More details are in WPILib's article). Each command also have subsystem requirements. This is to avoid scheduling commands that may interfere with each other. For example, one command may want a motor to turn right, while another command wants the motor to turn left. Adding requirements make sure that only one command is using a subsystem at a time. You can add requirements by using the `addRequirements()`.
 
 ### Lib
-The `lib` folder is where we would store the complex calculations, wrappers, or other things that do not directly interact with the robot, but are rather called on by commands or subsystems to assist in their execution. Stuff in this folder would be valuable code that we would actually want to keep and develop on from one year to another, such as drivetrain characterization, motion profiling, or swerve drive code. We usually don't include a folder decicated to Lib in our projects, but rather ue the lib199 repository.
+The `lib` folder is where we would store the complex calculations, wrappers, or other things that do not directly interact with the robot, but are rather called on by commands or subsystems to assist in their execution. Stuff in this folder would be valuable code that we would actually want to keep and develop on from one year to another, such as drivetrain characterization, motion profiling, or swerve drive code. We usually don't include a folder decicated to Lib in our projects, but rather use the lib199 repository.
 
 Most of this code is stored in the repository [lib199](https://github.com/DeepBlueRobotics/lib199) which is included in the gradle build to our main robot code. This makes it easy to include in new robot projects and other codebases. The `lib` folder is accessed through gradle build configurations, so you have to directly go the lib199 repo to see the code. It will not be in your project.
 

docs/section-4/auton.md

@@ -15,6 +15,6 @@ More requirements for autonomous:
 
 - it must use a command group (look in the documentation if you forgot what that is) to run the autonomous period, with one command for moving and the other for spinning
 - it can only use the encoder values to tell the command whether or not you have traveled far enough
-- it should not overshoot by a wide margin, but as long as it goes around 2 feet it's acceptable
+- it should not overshoot or undershoot by a wide margin, but as long as it goes around 2 feet it's acceptable
 
 Good luck! Again, once you're done, check in with a veteran programmer and then run your code on a robot!

docs/section-5/delegation.md

@@ -4,7 +4,7 @@ Bugs or features which have to be worked on/implemented should have an issue ope
 [Read more about Github Issues here](https://guides.github.com/features/issues/)
 
 ## Shadowing Team Members
-Programming team members who are not fully ready to work independently during build season should shadow a more experienced member. Experienced members who have a shadowing programmer should explain and talk about their code as they write it, and should try to teach the shadow as much as they can.
+Programming team members who are not fully ready to work independently during build season should shadow a more experienced member. Experienced members who have a shadowing programmer should explain and talk about their code as they write it and try to teach the shadow as much as they can.
 
 ## Build Season Schedule