wpilibsuite · sciencewhiz · Nov 24, 2024 · Nov 24, 2024 · Nov 25, 2024
diff --git a/source/docs/beta/tasks/task-3-port-code.rst b/source/docs/beta/tasks/task-3-port-code.rst
@@ -13,9 +13,9 @@ Desired Feedback
 
 Please keep the following questions in mind as you complete the task and include this information, as appropriate, in your Task 3 report.
 
- 1. Note any required changes to your robot program not detailed in the :doc:`documentation for porting robot code </docs/yearly-overview/yearly-changelog>`.
- 2. What problems or difficulties did you encounter?
- 3. What questions did you have during the process?
- 4. Any specific suggestions on improving the documentation? (Were any instructions unclear?)
- 5. Compare the Free RAM on the DS diagnostics tab to similar code running on the 2024 image.
- 6. Is there anything else you want to tell us related to this task?
+1. Note any required changes to your robot program not detailed in the :doc:`documentation for porting robot code </docs/yearly-overview/yearly-changelog>`.
+2. What problems or difficulties did you encounter?
+3. What questions did you have during the process?
+4. Any specific suggestions on improving the documentation? (Were any instructions unclear?)
+5. Compare the Free RAM on the DS diagnostics tab to similar code running on the 2024 image.
+6. Is there anything else you want to tell us related to this task?
diff --git a/source/docs/hardware/sensors/accelerometers-hardware.rst b/source/docs/hardware/sensors/accelerometers-hardware.rst
@@ -43,6 +43,6 @@ The roboRIO has a built-in accelerometer, which does not need any external conne
 
 Several popular FRC devices (known as "inertial measurement units," or "IMUs") combine both an accelerometer and a gyroscope.  Popular FRC example include:
 
-  - [Analog Devices ADIS16448 and ADIS 16470 IMUs](https://www.analog.com/en/landing-pages/001/first.html)
-  - [CTRE Pigeon IMU](https://store.ctr-electronics.com/gadgeteer-pigeon-imu/)
-  - [Kauai Labs NavX](https://pdocs.kauailabs.com/navx-mxp/)
+- [Analog Devices ADIS16448 and ADIS 16470 IMUs](https://www.analog.com/en/landing-pages/001/first.html)
+- [CTRE Pigeon IMU](https://store.ctr-electronics.com/gadgeteer-pigeon-imu/)
+- [Kauai Labs NavX](https://pdocs.kauailabs.com/navx-mxp/)
diff --git a/source/docs/hardware/sensors/gyros-hardware.rst b/source/docs/hardware/sensors/gyros-hardware.rst
@@ -8,9 +8,9 @@ Gyroscopes (or "gyros", for short) are devices that measure rate-of-rotation.  T
 
 Several popular FRC\ |reg| devices known as :ref:`IMUs <docs/hardware/sensors/accelerometers-hardware:IMUs (Inertial Measurement Units)>` (Inertial Measurement Units) combine 3-axis gyros, accelerometers and other position sensors into one device. Some  popular examples are:
 
-  - [Analog Devices ADIS16448 and ADIS 16470 IMUs](https://www.analog.com/en/landing-pages/001/first.html)
-  - [CTRE Pigeon IMU](https://store.ctr-electronics.com/gadgeteer-pigeon-imu/)
-  - [Kauai Labs NavX](https://pdocs.kauailabs.com/navx-mxp/)
+- [Analog Devices ADIS16448 and ADIS 16470 IMUs](https://www.analog.com/en/landing-pages/001/first.html)
+- [CTRE Pigeon IMU](https://store.ctr-electronics.com/gadgeteer-pigeon-imu/)
+- [Kauai Labs NavX](https://pdocs.kauailabs.com/navx-mxp/)
 
 ## Types of Gyros
 

diff --git a/source/docs/hardware/sensors/proximity-switches.rst b/source/docs/hardware/sensors/proximity-switches.rst
@@ -18,11 +18,11 @@ The digital inputs on the roboRIO have pull-up resistors that will make the inpu
 
 There are several types of proximity switches that are commonly used in FRC\ |reg|:
 
- - `Mechanical Proximity Switches ("limit switches")`_
- - `Magnetic Proximity Switches`_
- - `Inductive Proximity Switches`_
- - `Photoelectric Proximity Switches`_
- - `Time-of-flight Proximity Switches`_
+- `Mechanical Proximity Switches ("limit switches")`_
+- `Magnetic Proximity Switches`_
+- `Inductive Proximity Switches`_
+- `Photoelectric Proximity Switches`_
+- `Time-of-flight Proximity Switches`_
 
 ### Mechanical Proximity Switches ("limit switches")
 

diff --git a/source/docs/hardware/sensors/sensor-overview-hardware.rst b/source/docs/hardware/sensors/sensor-overview-hardware.rst
@@ -17,22 +17,19 @@ Sensors used in FRC can be generally categorized in two different ways: by funct
 Sensors can provide feedback on a variety of different aspects of the robot's state.  Sensor functions common to FRC include:
 
 - :doc:`Proximity switches <proximity-switches>`
-
-    * Mechanical proximity switches ("limit switches")
-    * Magnetic proximity switches
-    * Inductive proximity switches
-    * Photoelectric proximity switches
+   * Mechanical proximity switches ("limit switches")
+   * Magnetic proximity switches
+   * Inductive proximity switches
+   * Photoelectric proximity switches
 
 - Distance sensors
-
-    * :doc:`Ultrasonic sensors <ultrasonics-hardware>`
-    * :doc:`Triangulating rangefinders <triangulating-rangefinders>`
-    * :doc:`LIDAR <lidar>`
+   * :doc:`Ultrasonic sensors <ultrasonics-hardware>`
+   * :doc:`Triangulating rangefinders <triangulating-rangefinders>`
+   * :doc:`LIDAR <lidar>`
 
 - Shaft rotation sensors
-
-    * :doc:`Encoders <encoders-hardware>`
-    * :doc:`Potentiometers <analog-potentiometers-hardware>`
+   * :doc:`Encoders <encoders-hardware>`
+   * :doc:`Potentiometers <analog-potentiometers-hardware>`
 
 - :doc:`Accelerometers <accelerometers-hardware>`
 

diff --git a/source/docs/networking/networking-introduction/roborio-network-troubleshooting.rst b/source/docs/networking/networking-introduction/roborio-network-troubleshooting.rst
@@ -17,10 +17,10 @@ If there is no response, try pinging ``10.TE.AM.2`` (:ref:`TE.AM IP Notation <do
 
 ## Ping Fails
 
-   .. image:: images/roborio-troubleshooting/win10-dhcp.png
-      :alt: Windows 10+ image of the adapter setting
+.. image:: images/roborio-troubleshooting/win10-dhcp.png
+   :alt: Windows 10+ image of the adapter setting
 
-   If pinging the IP address directly fails, you may have an issue with the network configuration of the PC. The PC should be configured to **Automatic**. To check this, click :guilabel:`Start` -> :guilabel:`Settings` -> :guilabel:`Network & Internet`. Depending on your network, select :guilabel:`Wifi` or :guilabel:`Ethernet`. Then click on your connected network. Scroll down to **IP settings** and click :guilabel:`Edit` and ensure the :guilabel:`Automatic (DHCP)` option is selected.
+If pinging the IP address directly fails, you may have an issue with the network configuration of the PC. The PC should be configured to **Automatic**. To check this, click :guilabel:`Start` -> :guilabel:`Settings` -> :guilabel:`Network & Internet`. Depending on your network, select :guilabel:`Wifi` or :guilabel:`Ethernet`. Then click on your connected network. Scroll down to **IP settings** and click :guilabel:`Edit` and ensure the :guilabel:`Automatic (DHCP)` option is selected.
 
 ## USB Connection Troubleshooting
 

diff --git a/source/docs/software/advanced-controls/controls-glossary.rst b/source/docs/software/advanced-controls/controls-glossary.rst
@@ -61,7 +61,6 @@
 
    input
       An input to the :term:`plant` (hence the name) that can be used to change the :term:`plant's <plant>` :term:`state`.
-
          - Ex. A flywheel will have 1 input: the voltage of the motor driving it.
          - Ex. A drivetrain might have 2 inputs: the voltages of the left and right motors.
 
@@ -87,7 +86,6 @@
 
    output
       Measurements from sensors. There can be more measurements than states. These outputs are used in the "correct" step of Kalman Filters.
-
          - Ex. A flywheel might have 1 :term:`output` from a encoder that measures it's velocity.
          - Ex. A drivetrain might use solvePNP and V-SLAM to find it's x/y/heading position on the field. It's fine that there are 6 measurements (solvePNP x/y/heading and V-SLAM x/y/heading) and 3 states (robot x/y/heading).
 
@@ -129,7 +127,6 @@
 
    state
       A characteristic of a :term:`system` (e.g., velocity) that can be used to determine the :term:`system <system>`\'s future behavior. In state-space notation, the state of a system is written as a column vector describing its position in state-space.
-
          - Ex. A drivetrain system might have the states :math:`\begin{bmatrix}x \\ y \\ \theta \end{bmatrix}` to describe its position on the field.
          - Ex. An elevator system might have the states :math:`\begin{bmatrix} \text{position} \\ \text{velocity} \end{bmatrix}` to describe its current height and velocity.
 

diff --git a/source/docs/software/advanced-controls/filters/debouncer.rst b/source/docs/software/advanced-controls/filters/debouncer.rst
@@ -8,9 +8,9 @@ Debouncing is implemented in WPILib by the ``Debouncer`` class ([Java](https://g
 
 The WPILib ``Debouncer`` can be configured in three different modes:
 
-  * Rising (default): Debounces rising edges (transitions from `false` to `true`) only.
-  * Falling: Debounces falling edges (transitions from `true` to `false`) only.
-  * Both: Debounces all transitions.
+* Rising (default): Debounces rising edges (transitions from `false` to `true`) only.
+* Falling: Debounces falling edges (transitions from `true` to `false`) only.
+* Both: Debounces all transitions.
 
 ## Usage
 

diff --git a/source/docs/software/advanced-controls/introduction/introduction-to-pid.rst b/source/docs/software/advanced-controls/introduction/introduction-to-pid.rst
@@ -27,7 +27,6 @@ Roughly speaking: the proportional term drives the position error to zero, the d
    Throughout the WPILib documentation, you'll see two ways of writing the tunable constants of the PID controller.
 
    For example, for the proportional gain:
-
       * :math:`K_p` is the standard math-equation-focused way to notate the constant.
       * ``kP`` is a common way to see it written as a variable in software.
 

diff --git a/source/docs/software/advanced-controls/introduction/tuning-flywheel.rst b/source/docs/software/advanced-controls/introduction/tuning-flywheel.rst
@@ -6,8 +6,8 @@ In this section, we will tune a simple velocity controller for a flywheel.  The
 
 Our "Flywheel" consists of:
 
-  * A rotating inertial mass which launches the game piece (the flywheel)
-  * A motor (and possibly a gearbox) driving the mass.
+* A rotating inertial mass which launches the game piece (the flywheel)
+* A motor (and possibly a gearbox) driving the mass.
 
 For the purposes of this tutorial, this plant is modeled with the same equation used by WPILib's :ref:`docs/software/advanced-controls/controllers/feedforward:SimpleMotorFeedforward`, with additional adjustment for sensor delay and gearbox inefficiency. The simulation assumes the plant is controlled by feedforward and feedback controllers, composed in this fashion:
 

diff --git a/source/docs/software/advanced-controls/introduction/tuning-turret.rst b/source/docs/software/advanced-controls/introduction/tuning-turret.rst
@@ -8,8 +8,8 @@ A turret rotates some mechanism side-to-side to position it for scoring gamepiec
 
 Our "turret" consists of:
 
-  * A rotating inertial mass (the turret)
-  * A motor and gearbox driving the mass
+* A rotating inertial mass (the turret)
+* A motor and gearbox driving the mass
 
 For the purposes of this tutorial, this plant is modeled with the same equation used by WPILib's :ref:`docs/software/advanced-controls/controllers/feedforward:SimpleMotorFeedforward`, with additional adjustment for sensor delay and gearbox inefficiency. The simulation assumes the plant is controlled by feedforward and feedback controllers, composed in this fashion:
 

diff --git a/source/docs/software/advanced-controls/introduction/tuning-vertical-arm.rst b/source/docs/software/advanced-controls/introduction/tuning-vertical-arm.rst
@@ -8,8 +8,8 @@ Vertical arms are commonly used to lift gamepieces from the ground up to a scori
 
 Our "vertical arm" consists of:
 
-  * A mass on a stick, under the force of gravity, pivoting around an axle.
-  * A motor and gearbox driving the axle to which the mass-on-a-stick is attached
+* A mass on a stick, under the force of gravity, pivoting around an axle.
+* A motor and gearbox driving the axle to which the mass-on-a-stick is attached
 
 For the purposes of this tutorial, this plant is modeled with the same equation used by WPILib's :ref:`docs/software/advanced-controls/controllers/feedforward:ArmFeedforward`, with additional adjustment for sensor delay and gearbox inefficiency.  The simulation assumes the plant is controlled by feedforward and feedback controllers, composed in this fashion:
 

diff --git a/source/docs/software/advanced-controls/trajectories/constraints.rst b/source/docs/software/advanced-controls/trajectories/constraints.rst
@@ -6,14 +6,14 @@ For example, a custom constraint can keep the velocity of the trajectory under a
 ## WPILib-Provided Constraints
 WPILib includes a set of predefined constraints that users can utilize when generating trajectories. The list of WPILib-provided constraints is as follows:
 
- - ``CentripetalAccelerationConstraint``: Limits the centripetal acceleration of the robot as it traverses along the trajectory. This can help slow down the robot around tight turns.
- - ``DifferentialDriveKinematicsConstraint``: Limits the velocity of the robot around turns such that no wheel of a differential-drive robot goes over a specified maximum velocity.
- - ``DifferentialDriveVoltageConstraint``: Limits the acceleration of a differential drive robot such that no commanded voltage goes over a specified maximum.
- - ``EllipticalRegionConstraint``: Imposes a constraint only in an elliptical region on the field.
- - ``MaxVelocityConstraint``: Imposes a max velocity constraint. This can be composed with the ``EllipticalRegionConstraint`` or ``RectangularRegionConstraint`` to limit the velocity of the robot only in a specific region.
- - ``MecanumDriveKinematicsConstraint``: Limits the velocity of the robot around turns such that no wheel of a mecanum-drive robot goes over a specified maximum velocity.
- - ``RectangularRegionConstraint``: Imposes a constraint only in a rectangular region on the field.
- - ``SwerveDriveKinematicsConstraint``: Limits the velocity of the robot around turns such that no wheel of a swerve-drive robot goes over a specified maximum velocity.
+- ``CentripetalAccelerationConstraint``: Limits the centripetal acceleration of the robot as it traverses along the trajectory. This can help slow down the robot around tight turns.
+- ``DifferentialDriveKinematicsConstraint``: Limits the velocity of the robot around turns such that no wheel of a differential-drive robot goes over a specified maximum velocity.
+- ``DifferentialDriveVoltageConstraint``: Limits the acceleration of a differential drive robot such that no commanded voltage goes over a specified maximum.
+- ``EllipticalRegionConstraint``: Imposes a constraint only in an elliptical region on the field.
+- ``MaxVelocityConstraint``: Imposes a max velocity constraint. This can be composed with the ``EllipticalRegionConstraint`` or ``RectangularRegionConstraint`` to limit the velocity of the robot only in a specific region.
+- ``MecanumDriveKinematicsConstraint``: Limits the velocity of the robot around turns such that no wheel of a mecanum-drive robot goes over a specified maximum velocity.
+- ``RectangularRegionConstraint``: Imposes a constraint only in a rectangular region on the field.
+- ``SwerveDriveKinematicsConstraint``: Limits the velocity of the robot around turns such that no wheel of a swerve-drive robot goes over a specified maximum velocity.
 
 .. note:: The ``DifferentialDriveVoltageConstraint`` only ensures that theoretical voltage commands do not go over the specified maximum using a :ref:`feedforward model <docs/software/advanced-controls/controllers/feedforward:SimpleMotorFeedforward>`. If the robot were to deviate from the reference while tracking, the commanded voltage may be higher than the specified maximum.
 

diff --git a/source/docs/software/basic-programming/coordinate-system.rst b/source/docs/software/basic-programming/coordinate-system.rst
@@ -93,16 +93,14 @@ The code snippet below uses the ``DifferentialDrive`` and ``Joystick`` classes t
 The code calls the ``DifferentialDrive.arcadeDrive(xSpeed, zRotation)`` method, with values it gets from the ``Joystick`` class:
 
 - The first argument is ``xSpeed``
-
-    - Robot: ``xSpeed`` is the speed along the robot's X axis, which is forward/backward.
-    - Joystick: The driver sets forward/backward speed by rotating the joystick along its Y axis, which is pushing the joystick forward/backward.
-    - Code: Moving the joystick forward is negative Y rotation, whereas moving the robot forward is along the positive X axis. This means the joystick value needs to be inverted by placing a - (minus sign) in front of the value.
+   - Robot: ``xSpeed`` is the speed along the robot's X axis, which is forward/backward.
+   - Joystick: The driver sets forward/backward speed by rotating the joystick along its Y axis, which is pushing the joystick forward/backward.
+   - Code: Moving the joystick forward is negative Y rotation, whereas moving the robot forward is along the positive X axis. This means the joystick value needs to be inverted by placing a - (minus sign) in front of the value.
 
 - The second argument is ``zRotation``
-
-    - Robot: ``zRotation`` is the speed of rotation along the robot's Z axis, which is rotating left/right.
-    - Joystick: The driver sets rotation speed by rotating the joystick along its X axis, which is pushing the joystick left/right.
-    - Code: Moving the joystick to the right is positive X rotation, whereas robot rotation is CCW positive. This means the joystick value needs to be inverted by placing a - (minus sign) in front of the value.
+   - Robot: ``zRotation`` is the speed of rotation along the robot's Z axis, which is rotating left/right.
+   - Joystick: The driver sets rotation speed by rotating the joystick along its X axis, which is pushing the joystick left/right.
+   - Code: Moving the joystick to the right is positive X rotation, whereas robot rotation is CCW positive. This means the joystick value needs to be inverted by placing a - (minus sign) in front of the value.
 
 ### Mecanum drivetrain example
 
@@ -133,23 +131,20 @@ Mecanum drivetrains are holonomic, meaning they have the ability to move side-to
 The code calls the ``MecanumDrive.driveCartesian(xSpeed, ySpeed, zRotation)`` method, with values it gets from the ``Joystick`` class:
 
 - The first argument is ``xSpeed``
-
-    - Robot: ``xSpeed`` is the speed along the robot's X axis, which is forward/backward.
-    - Joystick: The driver sets forward/backward speed by rotating the joystick along its Y axis, which is pushing the joystick forward/backward.
-    - Code: Moving the joystick forward is negative Y rotation, whereas robot forward is along the positive X axis. This means the joystick value needs to be inverted by placing a - (minus sign) in front of the value.
+   - Robot: ``xSpeed`` is the speed along the robot's X axis, which is forward/backward.
+   - Joystick: The driver sets forward/backward speed by rotating the joystick along its Y axis, which is pushing the joystick forward/backward.
+   - Code: Moving the joystick forward is negative Y rotation, whereas robot forward is along the positive X axis. This means the joystick value needs to be inverted by placing a - (minus sign) in front of the value.
 
 
 - The second argument is ``ySpeed``
-
-    - Robot: ``ySpeed`` is the speed along the robot's Y axis, which is left/right.
-    - Joystick: The driver sets left/right speed by rotating the joystick along its X axis, which is pushing the joystick left/right.
-    - Code: Moving the joystick to the right is positive X rotation, whereas robot right is along the negative Y axis. This means the joystick value needs to be inverted by placing a - (minus sign) in front of the value.
+   - Robot: ``ySpeed`` is the speed along the robot's Y axis, which is left/right.
+   - Joystick: The driver sets left/right speed by rotating the joystick along its X axis, which is pushing the joystick left/right.
+   - Code: Moving the joystick to the right is positive X rotation, whereas robot right is along the negative Y axis. This means the joystick value needs to be inverted by placing a - (minus sign) in front of the value.
 
 - The third argument is ``zRotation``
-
-    - Robot: ``zRotation`` is the speed of rotation along the robot's Z axis, which is rotating left/right.
-    - Joystick: The driver sets rotation speed by twisting the joystick along its Z axis, which is twisting the joystick left/right.
-    - Code: Twisting the joystick to the right is positive Z rotation, whereas robot rotation is CCW positive. This means the joystick value needs to be inverted by placing a - (minus sign) in front of the value.
+   - Robot: ``zRotation`` is the speed of rotation along the robot's Z axis, which is rotating left/right.
+   - Joystick: The driver sets rotation speed by twisting the joystick along its Z axis, which is twisting the joystick left/right.
+   - Code: Twisting the joystick to the right is positive Z rotation, whereas robot rotation is CCW positive. This means the joystick value needs to be inverted by placing a - (minus sign) in front of the value.
 
 ### Swerve drivetrain example