Fix software text issues

_pages/software.md

@@ -27,7 +27,7 @@ Execution of state logic is done in the Arduino ``loop()`` function. Rather than
 #### **TimerInterrupt**
 The [TimerInterrupt](https://github.com/khoih-prog/TimerInterrupt) library is an open-source repository that allows users to directly interface with the hardware timers available on their Arduino board. This was especially relevant for us as it allowed us to repurpose a hardware timer for integrating IMU measurements, allowing for angle tracking in our software. Having a dedicated hardware timer proved to be far more precise than using ``millis()`` for the same purpose.
 
-A key learning experience from our project is that one must be extremely conscious of the timers being used by not only the user, but the Arduino itself. The PWM pins on the board use these timers, and one must be careful that you are not accidentially using the timer for two purposes. For example, we chose to perform IMU integration on ITimer1, but the standard Servo library on the Uno controls the Servos via pins 9 and 10, whos PWM also runs off of ITimer1. This led to integration issues and ultimatelly necessitated a last-minue wiring change to offload the Servos to an external breakout board. Another example is that initially we had the one motors enable pin connected to an ITimer0 pin, while the other was on ITimer2. When diagnositng issues driving in a straight line, we eventually moved both motors onto ITimer2, which improved consistency and straight line performance.
+A key learning experience from our project is that one must be extremely conscious of the timers being used by not only the user, but the Arduino itself. The PWM pins on the board use these timers, and one must be careful that you are not accidentially using the timer for two purposes. For example, we chose to perform IMU integration on ITimer1, but the standard Servo library on the Uno controls the Servos via pins 9 and 10, whos PWM also runs off of ITimer1. This led to integration issues and ultimately necessitated a last-minute wiring change to offload the Servos to an external breakout board. Another example is that initially we had the one motors enable pin connected to an ITimer0 pin, while the other was on ITimer2. When diagnosing issues driving in a straight line, we eventually moved both motors onto ITimer2, which improved consistency and straight line performance.
 
 #### **IMU Processing**
 The IMU processing class was developed in-house and inherits the open-source [mpu6050](https://github.com/ElectronicCats/mpu6050) library and acts as a wrapper to improve ease of use. This library contains two key functions that expand upon the capabilities of the mpu6050 library:
@@ -51,9 +51,11 @@ The maximum-only method occasionally failed due to these sources of noise. Attem
 However, we found that when the board was moved to the other side of the building, we did not see the expected signal shape, and new sources of noise appeared that interfered with this method. For the competition, we simplified this routine to use a simple top-hat convolution kernel that only filtered out spurious peaks. 
 
 #### **Line Sensor Processing**
-The line sensor processing was relatively straight forward in our software. We used hysterisis in order to remove chattering around a single threshold, and the min and max thresholds were turned experimentially such that we could detect line crossings. The software also kept running counters of the number of transitions between ``on_line`` and ``off_line`` states which was useful for debugging. The reliability of our sensor meant that this simple software implentation was very reliable, and it did not cause many issues during the project.
+The line sensor processing was relatively straightforward in our software. We used hysterisis in order to remove chattering around a single threshold, and the min and max thresholds were tuned experimentially such that we could detect line crossings. The software also kept running counters of the number of transitions between ``on_line`` and ``off_line`` states which was useful for debugging. The reliability of our sensor meant that this simple software implentation was very reliable, and it did not cause many issues during the project.
 
 #### **Servo Commanding**
+In terms of servo commanding, we mainly relied on the Arduino PWM Servo Driver Library.
+We then created our own interface for commanding the two servos, namely ``setSwivelAngle()``, ``closeHatch()``, and ``openHatch()``. This allowed us to easily control the servos as in our state diagram.
 
 #### **Motor Commanding**
 The motor control library was developed in-house and provides a range of commanding capabilities for the motor driver. This simplified actions in our state diagram and provided developers with flexibility in how the robot could be maneuvered. Given the size of our robot, this maneuverability was critical to mission success.
@@ -63,4 +65,5 @@ One key aspect of the commanding capabilities was three different turn modes, de
 - ``BACKWARD`` is the opposite of forward, where one wheel drives backward results in the center of mass shifting backward as well.
 - ``MIDDDLE`` has the wheels drive in opposite directions, minimizing the shift in center of mass.
 
-We found that while the ``MIDDLE`` turns were slightly less accurate due to a higher minimum turning speed, the value of keeping the center of mass in the same place was especially important to tuning the parameters in our software. Therefore, most turns were executed using the ``MIDDLE`` specification.
+We found that while the ``MIDDLE`` turns were slightly less accurate due to a higher minimum turning speed.
+Yet, the value of keeping the center of mass in the same place was especially important to tuning the parameters in our software. Therefore, most turns were executed using the ``MIDDLE`` specification.