Our arm functions with one purely positional PID loop, which it leaves when it hits a deadzone deemed "close enough" to our ideal setpoint. A high Ki value compensates for the unbalanced arm, canceling out a lot of steady-state error.

In order to drive with high reliability, we wanted to utilize our wheel encoders in the most effective control strategy we could given the scope of our project. Using the task of driving straight as a case study, we would like each wheel to move the same distance in roughly the same time. Furthermore, we would like their velocities to be identical. Say the left wheel moves faster than the right (less friction, etc); the robot will curve right, and then at the very end rotate left about the left wheel contact point. To avoid this, we close the loop around velocity first.

This still isn't really a perfect path planning method for a few reasons. First, our PID loops aren't perfect. One wheel will have a longer rise time than the other and so the robot will curve a bit to start with, and then curve the other way at the end, resulting in the right heading but a bit of horizontal displacement. We would prefer a more physically based approach to localization within dead reckoning, a.k.a. using the encoders and the forward kinematics of a differential-drive robot to work out the velocity and rotation of the drivetrain in global coordinates at every time. Then, path planning can be implemented to zero in on a demand position, rather than execute a demand wheel movement. This is done in some robotics classes and in ROS, but it's far outside the scope of this 3 week project. The other issue is that the wheels slip on the ground. They don't have a ton of traction and our ball casters have a fair amount of irregular friction. Furthermore, wheels don't drive straight when there is an axial force applied. Even without leaving the static friction region, a wheel will deform in the direction of the axial force; in the case of our robot, this means it will translate downwards as it moves perpendicularly along an incline even if the wheels maintain traction. These sorts of effects are why dead reckoning accumulates error, which is why we needed line following and why we squared off against walls. Both of these actions stop the accumulation of dead reckoning error (at least in one axis), even if they are imperfect methods themselves.

We used a "PID-lite" approach to line following, which helped center us on the way back to the loading zone. The three sensors were placed in front of the wheel center (allowing for stable line following; with the sensors behind the wheel center, turning to correct translational offset translates the sensors the opposite direction, leading to more perceived offset, which is positive feedback). They were also aligned to make sure that the line would always be detected by 1-2 sensors (no dead spots). From which sensors detected the line, we could determine our position on the line within 5 states: left only, left and center, center only, center and right, and right only. The more offset the state, the more the robot turns to compensate. For example, left only triggers a fairly hard right turn, whereas center only keeps the robot driving straight.

In the future, we would have liked to have more sensors (to increase the amount of offset where the line would still be visible), and also sensors on the other side of the wheel center (to be able to line follow while driving the opposite direction).