Tiffany's Lab 6

Lab 6: Closed Loop Control using PID

In this lab, I first improved my code structure to store chunks of data on the Artemis board and send data only when requested over BLE. Next, I drove the robot towards a wall and implemented PID control to stop the robot within 1 foot of the wall. I used the front-facing Time of Flight on the robot to collect data which was then used to calculate the error value for the PID controller.

Prelab / BLE

Before embarking on the main lab task, I first reorganized my code file structure and my system for sending data from the Artemis board to my laptop over Bluetooth. I broke down my Arduino file into one main file and two .h/.cpp files, one for motor functions and one for bluetooth commands. The header files below show the functions included in each file:

In my main loop, I also added new logic for the storing and transmission of data. Previously, I would send data over Bluetooth right as I received it, which caused significant delay in my data collection process. My code now stores data in arrays on the Artemis board and only sends data when it is requested over Bluetooth. This is done by sending a GET_DATA command in my Python code; in my Arduino command handler, I set a flag which triggers data to be written to BLE in the main loop.

Position Control

For this lab, I chose to implement Task A, which is to use PID control to drive my robot towards a wall and stop it when it reaches exactly 304cm from the wall. The input to the PID controller is the distance readings from the time of flight sensor, and the output is the new PWM values used to drive the motors.

Implementing the PID algorithm is simple, but the challenge comes from finding suitable constants for a well-tuned system. My goal is to drive the car as fast as I can in the beginning while still stopping it short of colliding with the wall with as little oscillation as possible. To find the optimal parameters for the PID control system, I used the following heuristic from class:

1. Set k_p to small value, k_d and k_i to 0.

2. Increase k_d until oscillation, then decrease by a factor of 2 to 4.

3. Increase k_p until oscillation or overshoot, then decrease by a factor of 2 to 4.

4. Increase k_i until oscillation or overshoot.

Using the above heuristic, I calculated the following parameter values which allowed my robot to quickly move towards the wall but stop before collision, adjusting to be around 304cm from the wall.

k_p = 0.08

k_d = 0.2

k_i = 0.125

In my pid function, I added deadband caps so that if the pwm being sent was too low for the motors to actually turn, I simply raised them to the minimum driving pwm. I also capped the maximum pwm value at 255 since that is the maximum duty cycle of the motors. Below is a compilation of videos I took throughout the process of adjusting the PID parameters. I start out by turning up the P and D terms, then decreasing them and adding the I term so that the robot can stop short of the wall and correct its position.

Here are graphs of the time of flight sensor readings and their corresponding pwm outputs over time. The robot starts out far away from the wall, so it has high readings for both distance and pwm. As it moves closer to the wall and eventually overshoots the 304cm setpoint distance, the pwm dips into the negatives to reverse the car's position and bring it closer to the setpoint.

I made the arrays for storing TOF and speed data 1000 ints long, so given that my TOF sensors sample new data roughly 2 times per second, my data structure can hold approximately 500 seconds of data, or over 8 minutes. With these structures as well as additional arrays I created to store the time and imu readings, my code used 37% of dynamic memory during compilation, meaning there is still room for storage of even more data and for longer periods of time if needed.

Home