Quadcopter MPC Control

Our goal in working on this project was to simulate a quadcopter that can move to specific points in space by using model-predictive control. We attempted this by using an existing ROS simulation, creating our own model of the simulation’s robot and subsequently its dynamics, and then we wrote controller code to control the ROS model based on our own.

One important consideration of ours was the lift and drag equations used by ROS (LiftDragPlugin). It seems that these were not readily accessible in ROSpy so we were required to approximate lift and drag on our own. We did our best to ensure they were similar to reality, but we understood that there would be differences.

Computer

ROS and Gazebo capable OS (optional)

Thinking cap

Model Predictive Control (commonly referred to as MPC) is a type of process control that can be employed to accurately control a modeled system relatively optimally.

How MPC works is pretty simple actually. Given an accurate dynamics model of your system, the controller tries out different actions and picks the one that gives the system the best results according to a cost function.

Now let's quickly discuss each of these parts of the controller!

Starting with the dynamics model, an MPC requires an accurate model of the system itself. Essentially, we need to know how giving certain inputs to the system will affect its state. For example, if we are shooting a cannon, we can use kinematics to predict how far the cannonball will travel given the angle, launch speed, and air properties.

Next let's talk about actions, also known as primitives. Primitives are a set of possible actions or inputs that we can give to our model and to our system. For the cannon example, our primitives could be a set of launch angles and launch speeds.

Finally, the cost function is an equation that allows the controller to evaluate how well it did a task. Let's look again at the cannon example. If we want to launch the cannon to hit a certain target, our cost function could be the square of the distance that the cannonball lands to the target itself. The cost function will allow us to evaluate which set of actions performs the best.

Putting it all together, we push a set of primitives through our dynamics model (in our case, changes in the propellers rotational speed). Our dynamics model tells us how the state of the quadcopter will change. We look at each final position that we get from our set of primitives and evaluate them with our cost function. Finally, we pick the best action (that gives us the lowest cost) and send it to the controller.

If you are interested in learning more about MPC, here are a few resources: https://en.wikipedia.org/wiki/Model_predictive_co... https://www.do-mpc.com/en/v4.1.1/theory_mpc.html

Quadcopters are not the most simple of dynamic systems, and as such there are a few important things to consider. Many of these considerations were stumbled upon by us when working on this project.

Inertia of props

Can’t hover at an angle, cost function does not have roll pitch

Coriolis forces canceling out

Calculating Lift

Global vs local orientation

The quadcopter we are using, and any quadcopter you can find have incredibly complex dynamics due to their shape, size, density of the air, motor dynamics, etc. This quickly becomes unwieldy when attempting to generate a model of the dynamics, so we propose the following simplified model of the quadcopter.

We simplify the quadcopter into a central region in the shape of a box, 4 legs which each extend out from the corners of the box and are each attached to propellers which spin either clockwise or counterclockwise. The parameters are as shown in the diagram, with a few extra that could not be shown due to perspective; they will be attached in the image.

See Image

It's time for us to build the Model Predictive Controller! As explained in the previous section, the MPC will try out a bunch of actions and evaluate them with a cost function, choosing the best of the bunch. Our Model Predictive Controller function is attached to this step.

Lines 141 through 144 initialize variables as well as establish the change in propeller velocity primitives that we will be trying.
The for loop on line 146 tries out all of the combinations of the different primitives and pushes them through our dynamics model on line 149.

We then evaluate the new cost of this state on line 155 and check if it is the lowest cost we have found so far, saving the specific set of primitives if so.

Finally, we return the best set of command inputs that we found on line 161.

As it stands, the quadcopter in simulation is still not perfectly controllable. This is largely due to some state calculation error, where our state is extremely different from what can be seen in the simulation environment. We were able to control our quadcopter to move, but because of state error we were unable to command it to fly to a specific location. This is an issue that should be fixable, but we unfortunately ran out of time before we were able to resolve the issue.

However, we believe that once this issue is fixed, and with tweaking some factors such as lift, drag, and our propeller velocity primitives, the quadcopter will reliably be able to reach any desired location.

There are multiple different paths that could be taken at this point. The first and most obvious path is to improve the model in such a way that it can be fully controlled. This will more than likely be absolutely necessary to do any further work, either on the simulation or in real life.

Another option is to bridge the Sim2Real and make this controller work on a real quadcopter. One of the big considerations here is the need to remodel a different quadcopter, and almost perfectly at that. Controlling a quadcopter in real life would also open the possibility of further projects requiring a quadcopter. Projects such as an aerial camera, or a drink deliverer. In the drink deliverer scenario, one would also need to find a way to localize the quadcopter so it isn’t overwhelmed by dead reckoning error.

One could also work on a weird sort of particle simulation using multiple quadcopters in simulation. If a new cost is assigned that relates to how close one quadcopter is to any other, while also penalizing being too far from the origin, it may be possible to automatically and evenly space multiple quadcopters. There may or may not be any practical applications of with, but it sounds like it could make for an interesting project.