add docuentation for motor command and line sensor processing

_pages/electrical.md

@@ -89,14 +89,16 @@ The line sensing circuit utilizes three RPR220 IR reflective sensors. Reflective
     {% include figure.liquid path="assets/img/line_sensor_electronics.png" title="Line Sensor Circuit Diagram" class="img-fluid rounded z-depth-1" %}
   </div>
 </div>
-Three sensors were used primarily for robustness in the sensing capabilities of the robot. The resistors were tuned to provide a large voltage range in the measurements, and each sensor was connected to an Uno analog pin. This allows for the software to make a determination on if a line has been detected.
+Three sensors were used primarily for robustness in the sensing capabilities of the robot. As documentation for the RPR220 was quite limited, the resistors were tuned experimentially to provide a large voltage range in the measurements. Each sensor was connected to an Uno analog pin. This allows for the software to make a determination on if a line has been detected.
 
 <div class="row justify-content-sm-center">
   <div class="col-sm-8 mt-3 mt-md-0">
     {% include figure.liquid path="assets/img/line_sensing_circuit.jpg" title="Line Sensor Electronics" class="img-fluid rounded z-depth-1" %}
   </div>
 </div>
 
+The casing surrounding the RPR220 made our line sensing quite robust and reliable in the presence of ever-changing external conditions. This is because nearly all noise sources were blocked, and we are able to consistently pick up the reflected signal off the ground.
+
 ### Inertial Measurement Unit
 The IMU selected was the MPU6050. This IMU is powered off of a 3V3 supply from the Uno and communicates with the Uno via the I2C communication protocal. This unit hosts three acceleratometers and gyroscopes to measure accelerations and angular velocities respectively. However, the only sensor that was actively used in the software was the +Z gyro, which allowed us to measure the robot's rotation rate.
 

_pages/software.md

@@ -18,18 +18,34 @@ Our GitHub repository can be found [here](https://github.com/hbuurmei/TRACBOT21-
 
 ### Libraries
 #### 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.
+
 #### IMU Processing
-The IMU processing class 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:
+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:
 - ``calibrate()`` reads IMU data for an user specified amount the time. The arithmetic mean of this data is stored as the bias for each sensor. This bias is then used to correct the IMU raw measurements to greatly improve accuracy.
-- ``update_integrator()`` is called at a fixed interval by ITimer1 to provide estimates of angles and position/velocity. It works by collecting the current bias-compensated measurements and integrating those measurements via a forward Euler approximation. This function along with the ability to ``reset_integrators()`` is key in measuring our turns to a high degree of precision, necessary for many events in our state diagram.
+- ``update_integrator()`` is called at a fixed interval by ITimer1 to provide estimates of angles and position/velocity. It works by collecting the current bias-compensated measurements and integrating those measurements via a forward Euler approximation. 
 
+$$\theta_{z,n+1} = \theta_{z,raw}+(\omega_{z,n}-\omega_{z,bias})\Delta t$$
 
-#### Servo Commanding
+This function along with the ability to ``reset_integrators()`` is key in measuring our turns to a high degree of precision, necessary for many events in our state diagram.
 
-#### Motor Commanding
+### Beacon Processing
 
 #### 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.
+
+#### Servo Commanding
+
+#### 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.
 
+One key aspect of the commanding capabilities was three different turn modes, described below:
+- ``FORWARD`` executes a turn where one wheel stays fixed, and the other drives forward. This results in a shift of the vehicle center of mass forward while turning.
+- ``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.
 
 
-[comment on limited timers as well]