Lab 6 Overview
In Lab 6, students had the option to implemented PID control so that the robot could complete one of two tasks: either approaching and stopping exactly 1 m in front of a wall, or rapidly approaching a wall, spinning exactly 180 degrees, and then driving away from the wall in the opposite direction. I chose the latter task. I started by developing the code infrastructure by running it with a simple set of parameters: slow speeds and only P control. P control was not satisfactory on its own; after I tailored parameters as best as I could, I added integral and derivative terms, which changed the performance.
Code Overview
The code for my 180 degree turn has two primary functions: an actuation and data collection function, and then a data transmission function. Pseudo code for the actuation and collection function is shown below. Note that during rotation, the PWM signals sent to the motors are not directly proportional to the control. Rather, there is a base PWM value that the motors will receive even if the control U is zero. This is because the PWM value at which the motors won’t spin isn’t zero.
The actual code for the collection function is shown below. The time, left PWM signal, right PWM signal, yaw, and ToF data were collected using the previous function, and they were sent to my computer using this function. Note that this function was only run after all actuation and data collection was complete to keep computation as fast as possible. Data transmission occured because a notification handler was running on my laptop, which queried and stored the value of the characteristic string each time it was changed by the collection function.
P Control Issues
One issue I had was getting the robot to drive in a straight line. The left and right PWM values which caused the robot to drive in a straight line were not only very different, but they varied from one run to another. Another issue was the robot drifting into the wall even after starting its turn at one meter. This often caused the robot’s wheels to get caught up and fail to rotate the robot to the reference (an integrator term would have fixed this problem). A video of the robot veering off course and then getting caught up in the wall is linked below.
P Control Most Successful Run
The most successful P control run is shown below. In this run, the duty cycles for the motors when driving forward in a straight line were 33.33% for the left motor and 60% for the right motor. The proportional gain was 0.27. Lastly, the base analog write value for the left and right motors were 100 and 120 respectively. The additional analog write values that were multiplied by the control and added to the base were 110 and 120 for the left and right motor respectively. The video linked below shows the run.
Graphs of the ToF sensor, yaw, and PWM signals with respect to time are shown in the images below.
Most Successful Run: PD Control
One of the biggest issues with this task was the robot over shooting the 180 degree rotation and never fully returning. PD control mitigated this; before the robot reached 180 degrees, the derivative term was negative, reducing the control output and reducing overshoot. The run with the robot rotating very nearly 180 degrees is shown below. My most successful PD control run had a proportional constant of 0.2 and a derivative constant of 0.13. The base analog write values for the right and left motors were 120 and 100 respectively. The added analog write values multiplied by the error terms and the constants were 120 and 110 for the right and left motors respectively. A video and graphs for PD control are shown below.
PID Control and Wind Up
I was much less successful when implementing PID control, even with windup mitigation. Whereas the PD control mitigated overshoot, PID made the overshoot worse, as the integrator term grew over time. A video of the robot well overshooting the 180 degree goal is shown below. Another issue was that the robot gyroscope integrator read 180 degrees even when robot overshot the 180 mark. This caused the robot to move forward too early, rather than rotating back to the correct position.
The overshoot prevention term is pictured. The largest that the term can be is defined by the limit which is a value defined on python when the function call is sent over bluetooth. The limit I used was 180, which was equal to the error before turning began.
