| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| ece6554:project_quadcopter [2023/03/21 11:31] – [Implementation] classes | ece6554:project_quadcopter [2024/08/20 21:38] (current) – external edit 127.0.0.1 |
|---|
| The model parameters for this system are a bit more complex. They will be provided in accompanying Matlab files that have the parameters for a variety of quadcopter platforms as culled from online documentation and published works. These parameters will be located in a YAML file. | The model parameters for this system are a bit more complex. They will be provided in accompanying Matlab files that have the parameters for a variety of quadcopter platforms as culled from online documentation and published works. These parameters will be located in a YAML file. |
| |
| ===== Implementation ===== | |
| |
| Functional code stubs for the implementation are provided in the {{ ECE6554:projects:quadcopter.zip | quadcopter zipfile}}. They implement a constant control signal that most definitely fails to do the job, but provide enough structure to complete the project. Comments in the code should help to realize the necessary improvements. <color red>[NOTE: This zipfile is not yet ready. Working on it now.]</color> | |
| |
| ==== Alternative Forms ==== | ==== Alternative Forms ==== |
| How to implement the equations is a function of one's comfort level with them. For those familiar with Lie groups and control on Lie groups, then the best option is to keep them in geometric form by using rotation matrices or quaternions to represent the rotation $R$, and their corresponding Lie algebra representations for the angular velocities $\omega$. A common representation for those unfamiliar with, or new to rigid body mechanics, is to employ Euler angle representations for the angular states. Which to use is up to you, though the most common will be the [[https://en.wikipedia.org/wiki/Euler_angles#Conversion_to_other_orientation_representations | Tait-Bryan angles]], described using the notation $X_1 Y_2 Z_3$ for the first coordinate being rotation about $x$, second about $y$ and third about $z$. The order of application is from right to left since the multiplication happens from the left side. Sometimes it is written as $R_x R_y R_z$ where $R_\cdot$ is the canonical rotation about the subscripted axis. Picking the right representation choice can simplify the nonlinearity in the equations of motion. The value of doing so is such that adaptive controllers might benefit from the simpler nonlinearity by having dependence on a sub-state of the system instead of the full state, or by having easy to describe nonlinear basis elements for adaptive cancellation. | How to implement the equations is a function of one's comfort level with them. For those familiar with Lie groups and control on Lie groups, then the best option is to keep them in geometric form by using rotation matrices or quaternions to represent the rotation $R$, and their corresponding Lie algebra representations for the angular velocities $\omega$. A common representation for those unfamiliar with, or new to rigid body mechanics, is to employ Euler angle representations for the angular states. Which to use is up to you, though the most common will be the [[https://en.wikipedia.org/wiki/Euler_angles#Conversion_to_other_orientation_representations | Tait-Bryan angles]], described using the notation $X_1 Y_2 Z_3$ for the first coordinate being rotation about $x$, second about $y$ and third about $z$. The order of application is from right to left since the multiplication happens from the left side. Sometimes it is written as $R_x R_y R_z$ where $R_\cdot$ is the canonical rotation about the subscripted axis. Picking the right representation choice can simplify the nonlinearity in the equations of motion. The value of doing so is such that adaptive controllers might benefit from the simpler nonlinearity by having dependence on a sub-state of the system instead of the full state, or by having easy to describe nonlinear basis elements for adaptive cancellation. |
| |
| | ==== Implementation ==== |
| | |
| | Functional code stubs for the implementation are provided in the {{ ECE6554:projects:quadcopter.zip | quadcopter zipfile}}. They implement a constant control signal that most definitely fails to do the job, but provide enough structure to complete the project. Comments in the code should help to realize the necessary improvements. |
| |
| ===== Control Approaches ===== | ===== Control Approaches ===== |
| | ----------- |
| There are several approaches to stabilizing the quadcopter. Which one to take depends on your comfort with control theory. They are listed below. | There are several approaches to stabilizing the quadcopter. Which one to take depends on your comfort with control theory. They are listed below. |
| |
| **Inner/Outer Control Loops:** Since it is known that control of (horizontaol) position requires angling the quadcopter (there are no means to directly control these state coordinates), a common technique for control of the quadcopter is to design a fast inner loop that achieves fast angular control with the position variables ignored. This approach works because the position state variables don't factor into the angular rate equations. The next step would be to then assume great or perfect tracking of angular signals and look at the position substates with angular inputs. The inner and outer loops can be adaptively controlled using different techniques. For example, the angular portion could be controlled using a more geometric method; a simple version of something like this was in the homework with satellite angular rate control. The linear portion could be controlled using standard linear techniques. | **Inner/Outer Control Loops:** Since it is known that control of (horizontaol) position requires angling the quadcopter (there are no means to directly control these state coordinates), a common technique for control of the quadcopter is to design a fast inner loop that achieves fast angular control with the position variables ignored. This approach works because the position state variables don't factor into the angular rate equations. The next step would be to then assume great or perfect tracking of angular signals and look at the position substates with angular inputs. The inner and outer loops can be adaptively controlled using different techniques. For example, the angular portion could be controlled using a more geometric method; a simple version of something like this was in the homework with satellite angular rate control. The linear portion could be controlled using standard linear techniques. |
| |
| **Geometric Control:** There are geometric approaches that impose a transformation of state to render the system more linear looking. A combination of geometric transformations of the signals plus linear control permit stabilization and trajectory tracking of non-aggressive maneuvers. There are flavors of this that afford aggressive maneuvering along feasible, specified trajectories. That part is a bit more involved and is not sought here. | **Geometric Control:** There are geometric approaches that impose a transformation of state to render the system more linear looking. A combination of geometric transformations of the signals plus linear control permit stabilization and trajectory tracking of non-aggressive maneuvers. There are flavors of this that afford aggressive maneuvering along feasible, specified trajectories. Aggressive controllers are a bit more involved and not sought here. |
| |
| |
| ===== Activities ===== | ===== Activities ===== |
| | ----------- |
| Though the activities below involve application of linear control, the full nonlinear equations should be used for simulation. As a sanity check, it is usually a good idea to first implement with the linear system simulated as a confirmation. Once it works, switch to the nonlinear system dynamics and linear control law. Performance should be similar but degrade slightly. For expected documentation for the deliverables, see the [[ECE6554:Project_PlanarHeli | Planar Bi-Rotor Helicopter]] project description. | Though the activities below involve application of linear control, the full nonlinear equations should be used for simulation. As a sanity check, it is usually a good idea to first implement with the linear system simulated as a confirmation. Once it works, switch to the nonlinear system dynamics and linear control law. Performance should be similar but degrade slightly. For expected documentation for the deliverables, see the [[ECE6554:Project_PlanarHeli | Planar Bi-Rotor Helicopter]] project description. |
| |
| |
| ===== References ===== | ===== References ===== |
| | --------------------- |
| |
| For sure you need to be careful with these references. In addition to different reference frame conventions between Aerospace engineers and others, plus different ways of representing the $SE(3)$ Lie group state, there are actually slightly different dynamical equations for the quadcopter. The references below just give some idea for how static controllers are synthesized for these systems. The model chosen depends on what the authors wish to demonstrate or what kinds of constraints their control method has. | For sure you need to be careful with these references. In addition to different reference frame conventions between Aerospace engineers and others, plus different ways of representing the $SE(3)$ Lie group state, there are actually slightly different dynamical equations for the quadcopter. The references below just give some idea for how static controllers are synthesized for these systems. The model chosen depends on what the authors wish to demonstrate or what kinds of constraints their control method has. |
