|
CALPOLY MECHATRONICS
Documentation for all Mechatronics Labs
|
|
|
CALPOLY MECHATRONICS
Documentation for all Mechatronics Labs
|
|
The ME 405 term project serves to demonstrate skill with multi-tasking, mechanical modeling, control theory, and firmware implementation. This takes the form of using these skills to balance an inverted pendulum system, in our case a platform capable of pitch and roll motion. The following documentation includes the drivers, tasks, main file, graphs, and diagrams. Taken together, these demonstrate the underlying mechanisms of platform operation, the means of operating said platform, the architecture of our code, and the results upon balancing the platform. We have discussed our design process and results in detail below, or for a general overview we have also provided a video overview:
The core functionality of our code is divided up into tasks that allow us to perform multitasking on the single threaded STM32 microchip. Each task is responsible for one major element of functionality. Below is a list of links to the documentation for each task:
While each task is responsible for communicating with other tasks, we also designed driver classes which are responsible for directly communicating with the hardware:
There are also a few modules that aren't tasks or drivers that are necessary for our program to function:
Because each task only handles one seciont of the overall program, the tasks need to share data with eachother. The task diagram shown bellow illustrates how data is shared between classes. Each task is designed to run at a specified period and with a specified priority. Tasks with higher priority are run before tasks with a lower priority if both tasks are requesting to be run.
Data sharing is achieved by creating cotask.Share and cotask.Queue objects in the shares module. Each task then imports the shares and queues that they need to function so that they can read and right to the shares and queues.
When dealing with a system near zero velocity, it is common to run in to problems estimating velocities. This is most often due to sensors, such as the encoders or touch panel having too low a resolution to smoothly resolve very slow displacements, which results in granular position data. Granular position data can cause the velocity to spike when, for instance, an encoder registers a new tick. To avoid these velocity spikes we implemented an alpha beta velocity estimation filter which acts similar to a low pass filter and eliminates sudden spikes in velocity. The goal of an alpha beta filter is to have the filtered velocity track closely with the "naive" velocity estimation method, but eliminate sharp peaks in estimated velocity. Shown below are graphs of the "naive" and filtered velocities measured by the encoders, as well as the "naive" and filtered velocities measured by the touch panel.
We generated these graphs by moving the platform by hand and moving a finger around the touch panel. We used these graphs to adjust the values of alpha and beta for both the touch panel and the encoders until the filtered velocity had minimal phase shift relative to the "naive" velocity estimation but still eliminated the peaks from the "naive" velocity.
The key to sucsessfully balancing the ball on the platform is a well designed controller. In order to analytically design a full state controller we needed to fist create a dynamic system model, which can be found here. Next, we linearized the system at the opperating point, shown here. Finally, we used pole placement to find the controller gains for our full state controller, shown here.
Once all of our tasks were functioning we used these gains as a starting point for tuning our controller. We first started by trying to balance the platform in a horizontal position without the ball on it by only adjusting the controller gains for the platform angular position and velocity. We repeatedly doubled the angular velocity gains untill the platform begane to oscillate. Then we increased the angular velocity gain until the oscillation was significantly reduced. Next, we placed the ball on the touch panel and increased the ball position gains until the system became unstable and then reduced the position gains slightly. As the nex step, we increased the ball velocity gains until we couldn't see any noticable bost in the system performance. Form there we experimented with incrementally increasing and decreasing the ball position and velocity gains to see if we could improve the system's performance.
Ultimatley we were able to tune our controller to balance the ball near the center of the platform if the system started at zero initial conditions. However, if the ball was placed on the platform off center or we pushed the ball with a finger the platform would begin to oscillate and the system would become unstable. The graphs below show the angular postion and velocity of the plate as it is balancing the ball.
1.9.0