Preliminary First Look Changes

bringing-up-swerve/check-your-gyroscope.md

@@ -2,7 +2,7 @@
 
 ## Define a front and expect to change it.
 
-It's easiest to define a front, maybe it's one that you want but expect to change it. Relative locations of modules are determined by the gyroscope. If your gyroscope is installed in the wrong orientation and can't be changed you WILL have to compensate for it in code that is not in any existing examples or apart of YAGSL. 
+It's easiest to define a front, maybe it's one that you want but expect to change it. Relative locations of modules are determined by the gyroscope. If your gyroscope is installed in the wrong orientation and can't be changed you WILL have to compensate for it in code that is not in any existing examples or apart of YAGSL.
 
 {% hint style="warning" %}
 FRONT is determined by gyroscope `0`!
@@ -18,4 +18,4 @@ If you are using a NavX or any gyroscope I would highly recommend that you calib
 
 ## Why should you invert your gyorscope?
 
-Gyrscope's should be inverted ONLY if they do not increase their yaw while moving counterclockwise!
+Gyrscope's should be inverted ONLY if they do not increase their yaw while moving counterclockwise! (See Gyroscope on the [Swerve Orientation Diagram](https://yagsl.gitbook.io/yagsl/bringing-up-swerve/creating-your-first-configuration#swerve-orientation-diagram))

bringing-up-swerve/check-your-motors.md

@@ -22,7 +22,7 @@ Conversion factors are applied to your motor convert from native units (usually
 
 ## The Absolute Encoder Offset
 
-The absolute encoder offset is what allows your swerve module to maintain the wheel orientation between power offs. It is vital to a functioning swerve drive. 
+The absolute encoder offset is what allows your swerve module to maintain the wheel orientation between power offs. It is vital to a functioning swerve drive.
 
 1. Line up all wheels so that the bevels are facing to the left like this.
 
@@ -40,11 +40,10 @@ The absolute encoder offset is what allows your swerve module to maintain the wh
 
     <figure><img src="../.gitbook/assets/shuffleboard_read_vals.png" alt=""><figcaption></figcaption></figure>
 
-
 7. Take note of the `Module[...] Raw Absolute Encoder` value's and use them for `absoluteEncoderOffset` in the module JSONs.
 
 {% hint style="warning" %}
-## Special note to MAXSwerve teams!
+### Special note to MAXSwerve teams!
 
 **IF** you are using the calibration bracket that comes with the max swerve modules it **WILL** make two of the wheels not face front to back!
 

bringing-up-swerve/swerve-information.md

@@ -10,6 +10,8 @@ Try to measure module locations in CAD to be as precise as possible and go from
 
 ## How to measure module locations (by Team 5010)
 
-1. Lay the robot on its side and rotate the wheels perpendicular to the direction you’re measuring. 
-2. Measure to the outside of each wheel and subtract 1 wheel width to get the measurement from center to center. 
+1. Lay the robot on its side and rotate the wheels perpendicular to the direction you’re measuring.
+2. Measure to the outside of each wheel and subtract 1 wheel width to get the measurement from center to center.
 3. Do the same thing in the other direction.
+
+<figure><img src="../.gitbook/assets/Measuring Swerve Drive Module Positions (1).png" alt=""><figcaption><p>Measuring Module Locations</p></figcaption></figure>

configuring-yagsl/dependency-installation.md

@@ -18,8 +18,6 @@ Bellow is a list of URL's that are required to be installed for YAGSL to work pr
 
 {% embed url="https://docs.wpilib.org/en/stable/docs/software/vscode-overview/3rd-party-libraries.html#installing-libraries" %}
 
-
-
 <table data-full-width="true"><thead><tr><th width="177">Vendor</th><th width="597">URL</th><th>Offline Installation</th></tr></thead><tbody><tr><td>CTRE Phoenix 6</td><td><code>https://maven.ctr-electronics.com/release/com/ctre/phoenix6/latest/Phoenix6-frc2024-latest.json</code></td><td><a href="https://v6.docs.ctr-electronics.com/en/latest/docs/installation/installation-frc.html">Tuner X</a></td></tr><tr><td>CTRE Phoenix 5</td><td><code>https://maven.ctr-electronics.com/release/com/ctre/phoenix/Phoenix5-frc2024-latest.json</code></td><td><a href="https://store.ctr-electronics.com/software/">Phoenix Tuner</a></td></tr><tr><td>REVLib</td><td><code>https://software-metadata.revrobotics.com/REVLib-2024.json</code></td><td><a href="https://github.com/REVrobotics/REV-Software-Binaries/releases/tag/rhc-1.6.2">REV Hardware Client</a> Offline</td></tr><tr><td>Studica (NavX)</td><td><code>https://dev.studica.com/releases/2024/NavX.json</code></td><td><a href="https://www.studica.ca/en/navx-2-mxp-robotics-navigation-sensor"><code>https://www.studica.ca/en/navx-2-mxp-robotics-navigation-sensor</code></a></td></tr><tr><td>ReduxLib</td><td><code>https://frcsdk.reduxrobotics.com/ReduxLib_2024.json</code></td><td><code>unavailable</code></td></tr><tr><td>PathPlanner</td><td><code>https://3015rangerrobotics.github.io/pathplannerlib/PathplannerLib.json</code></td><td><code>unavailable</code></td></tr><tr><td>YAGSL</td><td><code>https://broncbotz3481.github.io/YAGSL-Lib/yagsl/yagsl.json</code></td><td><code>YAGSL-Example</code></td></tr></tbody></table>
 
-All of these vendordeps must be installed for YAGSL to work due to the generic nature of YAGSL even if you do not use any of the products the vendor library supports.
+All of these vendordeps must be installed for YAGSL to work due to the generic nature of YAGSL even if you do not intend to use any of the products the vendor library supports.

configuring-yagsl/how-to-tune-pidf.md

@@ -8,7 +8,7 @@ Swerve steering/angle/azimuth motors have PID wrapping enabled at the topmost an
 
 YAGSL has PIDF values in [`pidfproperties.json`](configuration/pidf-properties-configuration/) within the swerve module folder.
 
-This has been hashed and boiled down to the simplest form like this before. 
+This has been hashed and boiled down to the simplest form like this before.
 
 * P: if you’re not where you want to be, get there.
 * I: if you haven’t been where you want to be for a long time, get there faster
@@ -19,7 +19,7 @@ This has been hashed and boiled down to the simplest form like this before.&#x20
 
 ## Tuning PIDF
 
-Another good way to describe it [from CTRE](https://pro.docs.ctr-electronics.com/en/latest/docs/api-reference/device-specific/talonfx/closed-loop-requests.html) is 
+Another good way to describe it [from CTRE](https://pro.docs.ctr-electronics.com/en/latest/docs/api-reference/device-specific/talonfx/closed-loop-requests.html) is
 
 Manual tuning typically follows this process:
 
@@ -49,7 +49,7 @@ The PIDF values will vary for every robot so tuning and testing are required. He
 
 {% tabs %}
 {% tab title="Drive Motor" %}
-## SparkMax
+### SparkMax
 
 When the `drive` motor `type` for every module is `sparkmax` then this is what the starting point can be.
 
@@ -71,7 +71,7 @@ When the `drive` motor `type` for every module is `sparkmax` then this is what t
 }
 </code></pre>
 
-## TalonFX
+### TalonFX
 
 When the drive motor `type` for every module is `talonfx` or alike (`kraken`/`falcon`) then this is what the starting point can be.
 
@@ -95,7 +95,7 @@ When the drive motor `type` for every module is `talonfx` or alike (`kraken`/`fa
 {% endtab %}
 
 {% tab title="Angle Motor" %}
-## SparkMax
+### SparkMax
 
 When the `angle` motor `type` for every module is `sparkmax` then this is what the starting point can be.
 
@@ -117,7 +117,7 @@ When the `angle` motor `type` for every module is `sparkmax` then this is what t
 </strong>}
 </code></pre>
 
-## TalonFX
+### TalonFX
 
 When the `angle` motor `type` for every module is `talonfx` or alike (`kraken`/`falcon`) then this is what the starting point can be.
 

fundamentals/swerve-drive.md

@@ -4,12 +4,19 @@ description: How does Swerve Drive work?
 
 # Swerve Drive
 
+
+## Introduction
 <figure><img src="../.gitbook/assets/sim_sample.png" alt=""><figcaption><p>Swerve Drive simulation from YAGSL</p></figcaption></figure>
 
+
+* Swerve drives allow robots to move in any direction while facing any orientation, offering unparalleled agility on the field.
+
+<figure><img src="../.gitbook/assets/BmhK4k.gif" alt=""><figcaption><p>FRC 2910 Off Season Swerve Drive</p></figcaption></figure>
+
 ## Tips while building a Swerve Drive
 
-* Center the gyroscope in the robot, this will help prevent a small drift and ensure more accurate odometry.
-* Make sure the magnets (if you're using them) are glue'd in right!
+* Center the gyroscope in the robot, this will help prevent a small drift and ensure more accurate odometry as calculations are based on distances from your gyroscope to your modules.
+* Make sure the encoder magnets (if you're using them) are glue'd in right!
 * Set aside time, assume you will mess up building 1 module or otherwise need a spare during competitions.
 * Programming a Swerve Drive is hard, and while YAGSL tries to make it easier there are many things you must know to fully understand what you are doing!
 * Use the right tools for the job! Debugging a Swerve Drive is difficult enough by text only, try out other Dashboards like [AdvantageScope](https://github.com/Mechanical-Advantage/AdvantageScope/blob/main/docs/NAVIGATION.md), or [FRC Web Components](https://github.com/frc-web-components/app/releases) they have excellent visualization tools that are sure to help you out!
@@ -20,7 +27,7 @@ Swerve Drives move around by moving each wheel to a specific angle/azimuth and r
 
 ## What is a Swerve Drive?
 
-A Swerve Drive typically consists of 4 Swerve Modules (which are in essence a drive motor, a angle/azimuth motor, and an absolute encoder),  and a gyroscope (centered is best). The motors, absolute encoders, and gyroscope do not matter and can all work together with varying degrees of success. As a rule of thumb if you can stick to one system do it (all REV, all CTRE). This will give you the best feature set however they are not the same! For all other use cases YAGSL is the best choice because YAGSL was built with abstraction in mind to make all sensors and motor controllers functionally equivalent.&#x20;
+A Swerve Drive typically consists of 4 Swerve Modules (which are in essence a drive motor, a angle/azimuth motor, and an absolute encoder), and a gyroscope (centered is best). The motors, absolute encoders, and gyroscope do not matter and can all work together with varying degrees of success. As a rule of thumb if you can stick to one system do it (all REV, all CTRE). This will give you the best feature set however they are not the same! For all other use cases YAGSL is the best choice because YAGSL was built with abstraction in mind to make all sensors and motor controllers functionally equivalent.
 
 #### TL;DR
 
@@ -31,18 +38,23 @@ A swerve drive is composed of
   * [ ] Angle/Azimuth Motor (+ controller)
   * [ ] Drive Motor
   * [ ] Absolute Encoder
+* [ ] Control System
+* [ ] Power Source
 
 #### TL;DR Things that cause issues
 
 * [ ] Bad Center of Gravity
 * [ ] Non-centered gyroscope
 * [ ] Non-square drive train
+* [ ] Mechanical Faults
+* [ ] Inconsistent Calibration
+* [ ] Faulty Wiring
 
 This is not a complete list and will grow over time.
 
 ## How does a Swerve Drive work in code?
 
-Swerve Drives move each module into a specific angle determined by the direction you want to go and heading you want to face. For FRC we can get these value's by hand by calculating the kinematics of the robot or use [`SwerveDriveKinematics`](https://github.wpilib.org/allwpilib/docs/release/java/edu/wpi/first/math/kinematics/SwerveDriveKinematics.html)  which uses the module locations to determine what the rotation and speed of each wheel should be given a [`ChassisSpeeds`](https://github.wpilib.org/allwpilib/docs/release/java/edu/wpi/first/math/kinematics/ChassisSpeeds.html) object and returns an [`SwerveModuleState`](https://github.wpilib.org/allwpilib/docs/release/java/edu/wpi/first/math/kinematics/SwerveModuleState.html) array. The [`SwerveModuleState`](https://github.wpilib.org/allwpilib/docs/release/java/edu/wpi/first/math/kinematics/SwerveModuleState.html) can then be used to set the angle/azimuth and speed corresponding with each Swerve Module to go in the desired direction facing the desired heading.&#x20;
+Swerve Drives move each module into a specific angle determined by the direction you want to go and heading you want to face. For FRC we can get these value's by hand by calculating the kinematics of the robot or use [`SwerveDriveKinematics`](https://github.wpilib.org/allwpilib/docs/release/java/edu/wpi/first/math/kinematics/SwerveDriveKinematics.html) which uses the module locations to determine what the rotation and speed of each wheel should be given a [`ChassisSpeeds`](https://github.wpilib.org/allwpilib/docs/release/java/edu/wpi/first/math/kinematics/ChassisSpeeds.html) object and returns an [`SwerveModuleState`](https://github.wpilib.org/allwpilib/docs/release/java/edu/wpi/first/math/kinematics/SwerveModuleState.html) array. The [`SwerveModuleState`](https://github.wpilib.org/allwpilib/docs/release/java/edu/wpi/first/math/kinematics/SwerveModuleState.html) can then be used to set the angle/azimuth and speed corresponding with each Swerve Module to go in the desired direction facing the desired heading.
 
 ### `SwerveDriveKinematics`
 
@@ -130,7 +142,7 @@ Swerve Drive code does not work without [`SwerveDriveOdometry`](https://github.w
 
 ### `SwerveDriveOdometry`
 
-Unfortunately life isn't that easy. We have to keep continuous track of our current positioning of the robot, specifically the **heading**, **speed**, and **module positions** collectively known as **odometry**. This is the only way to correctly generate [`SwerveModuleState`](https://github.wpilib.org/allwpilib/docs/release/java/edu/wpi/first/math/kinematics/SwerveModuleState.html) which are usable.&#x20;
+Unfortunately life isn't that easy. We have to keep continuous track of our current positioning of the robot, specifically the **heading**, **speed**, and **module positions** collectively known as **odometry**. This is the only way to correctly generate [`SwerveModuleState`](https://github.wpilib.org/allwpilib/docs/release/java/edu/wpi/first/math/kinematics/SwerveModuleState.html) which are usable.
 
 <pre class="language-java" data-title="SwerveDrive.java" data-line-numbers data-full-width="false"><code class="lang-java">// Import relevant classes.
 import edu.wpi.first.math.kinematics.SwerveDriveKinematics;
@@ -231,8 +243,6 @@ Swerve Drive odometry must be updated every single run in a similar fashion to t
 
 There are many more intricacies to Swerve Drive's than covered on this page however this is sufficient for a basic understanding of how to program a Swerve Drive. I would highly encourage the reader to look at as many examples they can find to understand some of the gotcha's more or continue on to use YAGSL, Good Luck!
 
-
-
 [^1]: This will not work as is and is representative of a \`SwerveModule\` class.
 
 [^2]: This is not optional and necessary in order to keep track of your robot's current positioning and continue to generate correct `SwerveModuleState`'s.

fundamentals/swerve-modules.md

@@ -7,16 +7,16 @@ description: What is a Swerve Module?
 You may see a bunch of different classes in other teams code which represent a `SwerveModule` and wonder why there isn't a standard class. There is a very good reason for that, every motor, absolute encoder, gear ratio, and installation can be different! Some teams try to prevent more issue's in their Swerve Drive than others because they had more time to debug it. YAGSL aims to take into account all common issues and address them in JSON configuration files.
 
 {% hint style="warning" %}
-If you are using a magnetic encoder ensure that the magnet is glued correctly so it does not slip.
+If you are using a magnetic encoder ensure that the magnet is glued correctly so it does not slip. Modules typically have installation guides that can be found on their respective webpages where the module was purchased.
 {% endhint %}
 
 ## What is in a Swerve Module?
 
-* [ ] Drive Gears (ratio must be known)
-* [ ] Steering Gears (ratio must be known)
-* [ ] Drive Motor (+ controller)
-* [ ] Angle/Azimuth/Steering Motor (+ controller)
-* [ ] Absolute Encoder
+* [ ] **Drive Gears** (ratio can be found on modules website)
+* [ ] **Steering Gears** (ratio can be found on modules website)
+* [ ] **Drive Motor** (+ controller \[ex. Rev Spark MAX if using NEO's])
+* [ ] **Angle/Azimuth/Steering Motor** (+ controller \[ex. Rev Spark MAX if using NEO's])
+* [ ] **Absolute Encoder** (ex. CTRE CANCoder)
 
 ## Review
 
@@ -44,11 +44,11 @@ All of these need to be set correctly in order to configure a Swerve Module prop
 
 ## Checklist
 
-* [ ] Steering/Azimuth/Angle motor[ increases with the absolute encoder](#user-content-fn-1)[^1] value.
-* [ ] Steering/Azimuth/Angle motor increases counterclockwise positive.
-* [ ] Drive motors increase propelling the robot "forwards"
+* [ ] Steering/Azimuth/Angle motor[ increases with the absolute encoder](#user-content-fn-1)[^1] value (see [When To Invert](../configuring-yagsl/when-to-invert.md)).
+* [ ] Steering/Azimuth/Angle motor increases counterclockwise positive when looking down on the robot.
+* [ ] Drive motors increase propelling the robot "forwards".
 * [ ] Absolute Encoders are securely seated into the Swerve Module.
-* [ ] Conversion Factor is correctly calculated.
+* [ ] Conversion Factor is correctly calculated (see [Conversion Factor](https://yagsl.gitbook.io/yagsl/fundamentals/swerve-modules#conversion-factor)).
 * [ ] Absolute encoder offset of which the wheel facing the same way is configured.
 
 {% hint style="warning" %}
@@ -259,8 +259,6 @@ $$
 SteeringConverionFactor = \frac{1_{degree}}{1_{rot}} = \frac{1_{rot}}{12.8_{rot}} * \frac{1_{rot}}{360_{deg}}
 $$
 
-
-
 The drive conversion factor will take _**rotations/minute**_ given by the motor encoder and convert them to _**meters/second**_.
 
 For the following example we will use the gear ratio `6.75:1` [(SDS MK4 L2 Drive Ratio)](https://www.swervedrivespecialties.com/collections/kits/products/mk4-swerve-module) which means the rotor spins `6.75` times for the wheel to complete a rotation.
@@ -281,7 +279,7 @@ The conversion factor is extremely important and if it is wrong the motor **COUL
 
 ### PID Control
 
-PID stands for Percent-Integral-Derivative. Swerve Drive's should try to use the most up to date feedback sensors so we will be using the on-board PID feature of the SparkMAX. 
+PID stands for Percent-Integral-Derivative. Swerve Drive's should try to use the most up to date feedback sensors so we will be using the on-board PID feature of the SparkMAX.
 
 WPILib has a great guide to learning PID's here. The turret position example is how we will control the steering motors.
 
@@ -291,7 +289,7 @@ REV's documentation on this is available and shows how it works (mostly) on the
 
 {% embed url="https://docs.revrobotics.com/sparkmax/operating-modes/closed-loop-control" %}
 
-There are 2 PID's you need to control create to control a Swerve Module one for the drive motor, the other for the steering motors. 
+There are 2 PID's you need to control create to control a Swerve Module one for the drive motor, the other for the steering motors.
 
 #### Drive Motor PID
 
@@ -303,7 +301,7 @@ For a drive wheel there may be a feedforward you want to always use to ensure th
 
 #### Steering Motor PID
 
-The Steering Motor PID controls the angle of the wheel in degrees based off of the feedback sensor. A few tricks are necessary to do this effectively though. 
+The Steering Motor PID controls the angle of the wheel in degrees based off of the feedback sensor. A few tricks are necessary to do this effectively though.
 
 1. PID Wrapping ensures the wheel will always choose the shortest path to the destination angle.
 2. Grease your gears often!!!