Control of a Cartesian Drawing Bot
This was a group project for the ME 461 Automatic Control course at the University of Michigan. The objective of our project was to model the system dynamics of a dual-axis cartesian drawing-bot. Note that we did not actually build the system; we only simulated it in Matlab/Simulink.
Below are selected excerpts from the final report.
Summary
In order to model the drawing-bot as a SISO system, we made simplifying assumptions and modeled the X and Y dynamics as two separate and independent systems. Generally speaking, the system would work by sending a desired y position to the y-axis motor which would then translate to an input voltage and the rotary motion 𝛉y of the shaft. The rotary motion converted to linear motion via a rack and pinion. A rotary encoder measured the actual position of the motor which was then used to estimate the y position of the drawing pen. The system worked similarly for the X dynamics.
Design Criteria
Some concerns included the trade-offs between settling time, overshoot, and steady-state error. We preferred if the system would respond quickly given an input by decreasing settling time, but this would indirectly increase overshoot by also decreasing the rise time. A high overshoot would result in an unfavorable jerking motion in the pen, additional points drawn, and inaccuracies in the drawing. Large steady state error would also lead to inaccuracies in the drawing. Increasing settling time would decrease overshoot but significantly increase the time it takes for the bot to draw. However, for this application the quality of the drawing was the higher priority so we focused on reducing steady state error to 5%, reducing overshoot to 10%, and keeping settling time under 0.5 seconds.
Description of Control Law
To reduce the steady-state error and meet our system requirements we decided to use a lead-lag controller. The lead controller ensured stability in our system while the lag controller reduced steady state error. These two controllers had to be used in combination because individually, there was no way to tune them such that they would meet all of our design requirements. We chose a lead-lag controller over a PID and other controllers because, experimentally, it was easier to tune using the SISO tool in Matlab and had it better performance. Lead-lag controllers also typically have more desirable bode characteristics than PID controllers. More specifically, the gain in a lead-lag controller tends to a constant as the frequency goes to infinity whereas for a PID controller, the gain tends to infinity. This results in lead-lag controllers having better attenuation of noise at high frequencies.
Tuning the Control System
We primarily tuned our system using the root locus methods by adjusting the poles and zeros until we were able to pull the closed loop poles into the area meeting the settling time and overshoot requirements. We started with tuning the lead controller, then the lag, and then adjusted the overall gain as necessary. To ensure that our other requirements were being met, we observed the changes in the step response and bode plots as we tuned the controller. The step response showed us the effects of settling-time, steady-state error, and overshoot in response to the control system. The closed loop bode plot showed us the magnitude and phase of the system. We specifically looked at the changes in the bode plot to make sure that the magnitude was small at low frequencies and phase shift was minimized to reduce lag.
We chose the root locus method to tune our controller because it was the most intuitive method given our design requirements. Matlab has a built-in design requirements function that makes it easier to visualize the requirements as we tune the controller. We could have used the bode plots to tune the controller—and indeed, we did look at the open loop bode plots as we tuned the controller—but using this method alone told us more about the stability of the system and would not allow us to visualize whether we were meeting the steady state, overshoot, and settling time design requirements. Other methods such as Nyquist and time domain were also valid alternatives, but were not chosen for the same reason why we did not use the bode plots alone.
System Performance Compared to Requirements
While we were able to meet the rise time and overshoot design requirements using SISO tool, our steady state error was slightly higher than we wanted. The design requirements feature in the root locus tool in Matlab allowed us to visualize acceptable regions to achieve our rise time and overshoot requirements, but not the steady state requirement. This made it difficult to tune the controller accordingly since we did not have a visual representation in the root locus plot. Instead, we had to rely solely on the 7 step response plot to determine steady state error. Additionally, reducing the steady state error required higher gain values, which widened the gap between our unsaturated and saturated controller outputs. When applying the controller to the model in Simulink, which models the saturation of the motor, we were not able to meet any of our requirements. This was primarily because the voltage saturation slowed down how quickly the system could reach a position. We were not able to tune or improve the controller for the saturated condition because there are not any good ways to tune controllers on the fly in Simulink.
Takeaways
Some takeaways from this project were to be absolutely sure that the block diagram is correctly implemented in the Simulink model to avoid compounding error as we progress through the analysis. Another takeaway was to first try a lead compensator and then a lag compensator to understand the effects of lead and lag compensation individually before jumping to a lead-lag compensator. Finally, it’s important to consider the non-ideal, physical limitations of your system. We may have been able to come up with a better controlled for the system if we had modeled the saturation of the motor voltage from the start or if we had a way to tune the controller in Simulink, where modeling the saturation was possible, as opposed to tuning in SISO tool.
Changes
If we could do this project again, we would most likely choose a more simple feedback control system such as a toaster or thermostat. We’d also like to build the physical system so that we could determine system parameters. Modeling the dynamics of the rack of pinion would have been easier if we had a rack and pinion. If we had a physical system we would have been able to estimate the damping constant by running experiments and doing empirical calculations.