Fast Robots @Cornell, Spring 2023

Lab 6: Closed-loop control (PID)

Objective

The purpose of this lab is to get experience with PID control. The lab is fairly open ended, you can pick whatever controller works best for your system. 4000-level students can choose between P, PI, PID, PD; 5000-level students can choose between PI and PID controllers. Your hand-in will be judged upon your demonstrated understanding of PID control and practical implementation constraints, and the quality of your solution.

This lab is part of a series of labs (6-8) on PID control, sensor fusion, and stunts. This week you can choose to do either position control or orientation control. The former is easier and a good choice if you are very strained for time. The latter is a little harder, but will be of direct use in future labs (it is also more fun!). Whatever you choose, spend this week getting the basic behavior working. While we give you tips for improving/speeding up your controller in this lab, if you run out of time, you can optimize more over the coming weeks.

Parts Required

Prelab / BLE

No matter which task you take on, it will be essential that you first setup a good system for debugging.

Please attempt to implement this before your lab session. Feel free to discuss the best strategy with your team mate.

A good technique will be to:

Have the robot controller start on an input from your computer sent over Bluetooth
Execute PID control over a fixed amount of time (e.g. 5s) while storing debugging data in arrays.
- Remember to have a hard stop implemented directly on your Artemis, so that your robot will stop even if the Bluetooth connection fails.
Upon completion of the behavior, send the debugging data back to the computer over Bluetooth.

Debugging data may for example include sensor data with time stamps similar to what you implemented in lab 3-4, output from the individual branches of your PID controller, and/or the input that you are sending to your motors. Remember, however, the storage cannot exceed the internal RAM of 384kB. If you plan to do a lot of tweaking of your gains, you can also consider writing a Bluetooth command that lets you update the gains without having to reprogram the Artemis.

Lab Procedure

Choose one of the following two tasks. The objective will be to achieve reliable and accurate, yet fast control. Note that the task you choose in this lab will eventually create the basis of the stunt you can attempt in Lab 8.

Tips and tricks:

LOG DATA: If you don’t want to repeat work during Lab 7, be sure to log all data (time stamped sensor values and motor outputs), as well as setup variables from at least one successful run. Even if you are doing orientation control, be sure to log ToF data as you speed towards the wall as well.
Lectures: Brush up on your PID control skills by checking out Lectures 7 and 8.
PID library: There exists an Arduino PID library. You are welcome to use this library if you prefer, but we will only offer limited TA support if you run into issues. Implementing a basic PID controller from scratch is easy (<10 lines of code), and will give you more freedom in dealing with noise, wind-up, and system non-linearities.
Start simple: E.g. with a proportional controller running at low speeds and a generous setpoint, then you can work your way up to faster speeds, more advanced control, and more difficult setpoints if you have time.
Documentation: Please clearly document the maximum linear or angular speed you are able to achieve (you can use your sensors to compute this). To demonstrate reliability, please upload videos of at least three repeated (and hopefully successfull) experiments.
Frequency: Fast loop times means everything to a good controller. Be sure to include a discussion of sensor sampling rate and how this affects the timing of your control loop. Avoid using blocking statements when you can (e.g. delay() or while(sensor not ready) ){wait} ). Also, remember that any serial.print/BLE sending that occurs during execution may slow down your loop time considerably.
Deadband: From Lab 5, you should have found the deadband of your motor (the region below which the power to the motors does not overcome the static friction in your system). Consider writing a scaling function that converts the output from your PID controller to an output for which the motors can actually react.
Wind up: If you include an integrator, consider whether you need to worry about integrator wind-up.
Derivative LPF: If you include a derivative, consider whether it is necessary to include a low pass filter in the derivative branch.
Derivative kick: Consider whether the derivative kick can cause any issues, given the task you choose. Here is a great overview on how to eliminate derivative kick: http://brettbeauregard.com/blog/2011/04/improving-the-beginner’s-pid-derivative-kick/
Anything goes: The goal is a working system. When you have a reasonable control setup working, you should feel free to add any “hacks” that will improve your robot performance in a reliable way. If you don’t have time to implement them, discussing what you imagine would help can still get you grading points.
Motor drivers: Recall Lecture 6 on Actuators and that the motor drivers have both coasting and active breaking modes. These might come in handy.

Task A: Position Control

Again, if you are very low on time this week, this task is a good choice.

For this task, you will have your robot drive as fast as possible (given the quality of your controller) towards a wall, then stop when it is exactly 1ft (=304mm=1 floor tile in the lab) away from the wall using feedback from the time of flight sensor. Your solution should be robust to changing conditions, such as the starting distance from the wall (2-4m). If you attempt to do this at home, you could also show that your solution is robust to changing floor surface, e.g. linoleum or carpet. The catch is that any overshoot or processing delay may lead to crashing into the wall.

Beyond the considerations mentioned above, think about the following:

Given the range of motor input values and the output from your tof sensor, discuss what a reasonable range of the proportional controller gain will be.
Consider the range and sampling time you choose for your TOF sensor; it may be worth lowering the accuracy for faster updates. Note that the medium range is only available if you are using the (ToF Pololu library).
Also note that the sensor has a programmable integration time. If this is set too high, you will see large jumps in your data as the robot drives and you can no longer assume that the measurements are independent. You can lower the integration time (trading off accuracy for speed) using: proximitySensor.setProxIntegrationTime(4); //A value of 1 to 8 is valid. Again this function is only available in the Tof Pololu library.

Below you can see an example of a simple PI controller acting on the TOF signal.

Corresponding videos are here:

** NOTE: If you choose this task, your eventual stunt will involve speeding towards the 1ft position (where a small sticky matt will be located), then doing a vertical flip and driving back in the direction from where you came. In this lab you will be limited by sensor sampling rate and you may have to lower the motor speed accordingly. In Lab 7 we will look at sensor fusion as a way to overcome this problem.

Task B: Orientation Control

To lower your overall class workload, this task is a good choice.

For this task, you will have the robot drive fast forward toward a wall, then turn with drift to do a 180 degree turn, and return in the direction it came from without stopping. The PID controller should be controlling the orientation of your robot by introducing a difference in motor speeds. Before trying to get your car to drift, try controlling the orientation of your car while it is stationary, then introduce a base speed. To make your data useful for lab 7, be sure to start 4m from a wall and get within 1m before turning.

Beyond the considerations mentioned above, think about the following:

How do you get the orientation of the robot? How can you minimize the error introduced by discrete integration of the gyroscope?
How fast is your robot turning? You may have to check whether you are maxing out the gyroscope. The library will allow you to adjust the range.
The PID controller should control an “offset” or differential in wheel speed. That way you can control the orientation even if the car is moving at a set base speed.

Below you can see an example of the controller maintaining a constant orientation even when the robot is kicked.

Below is an example of the robot drifting and doing a 180 degree turn as well as graphs of the setpoint, angle, and control signal for the PID controller.

** NOTE: If you choose this task, your eventual stunt will involve speeding towards a wall until you are 3ft (914mm = 3 floor tiles in the lab) out, then turning 180 degrees and driving back from where you came (as fast as possible). Just like in Task A, lab 7 will involve sensor fusion on the time of flight sensor to help you estimate the distance to the wall at a high sampling rate.

Tasks for 5000-level students

Implement wind-up protection for your integrator. Argue for why this is necessary (you may for example demonstrate how your controller works reasonably independent of floor surface).

Write-up

Word Limit: < 800 words

Webpage Sections

This is not a strict requirement, but may be helpful in understanding what should be included in your webpage. It also helps with the flow of your report to show your understanding to the lab graders. This lab is more open ended in terms of the steps taken to reach the end goal, so just make sure to document your process you take to complete your task, including testing and debugging steps!

Prelab
- Clearly describe how you handle sending and receiving data over Bluetooth
- Consider adding code snippets as necessary to showcase how you implemented this on Arduino and Python
Lab Tasks
- P/I/D discussion (Kp/Ki/Kd values chosen, why you chose a combination of controllers, etc.)
- Range/Sampling time discussion
- Graphs, code, videos, images, discussion of reaching task goal
- A: Graph data should include Tof vs time and Motor input vs time (and whatever helps with debugging)
- B: Graph data should at least include theta vs time (you can also consider angular velocity, motor input, etc)
- (5000) Wind-up implementation and discussion

Add code (consider using GitHub Gists) where you think is relevant (DO NOT paste your entire code).