Often when people design multirotors, they find it tricky to figure out what components would be a good choice for their desired mission. Typically after a few hours of scrolling through Hobbyking or another online store they come to what they think is a good fit, where everything has enough power to fly and is not too heavy. Though let's be honest, this process usually just involves copying what other people have done, picking something that “looks right”, or just plain guessing. The problem is that this can leave your designs inflexible and suboptimal. This is a tutorial about using optimization techniques to come up with smarter designs that are flexible and squeeze the most out of your componentry choices. It’s a coding tutorial, so you need to have basic skills in Python to follow along, but if you don’t, just read through and use the finished script I provide at the end.
Software that you'll need:
Make sure GPkit has installed correctly and is working well by using some of the examples they have provided. It can be a tricky install, but it's worth it once you have it all working.
To get started, open up your favourite text editor and make a file named opt.py. The first thing you want to do is import the package that we are using to do the optimization, called GPkit.
Now we can set up a simple physics-based model for a multirotor. This model can be used for any basic design objective such as maneuverability or payload capacity. The first characteristic of a multirotor is its number of rotors, i.e. is it a quad, tricopter, octocopter etc. We’ll go with a quadrotor here.
We can then take a guess at the payload and structure mass.
Next we need to model the battery, which is usually a large fraction of the mass. To get a reasonable value for the battery specific energy, or amount of energy it can hold per unit mass, I took the average of some random batteries off Hobbyking. The eX notation just means *10^X, it’s another way of saying scientific notation that’s much easier to code.
The next step in the power chain between the battery and thrust is the electronic speed controller or ESC, which we model in the same way as the battery though instead of specific energy we use specific power.
Same thing for the motor.
Ignoring things like RPM matching, a simple model of a propeller is just its diameter and efficiency. We’ll fix the diameter, for reasons that’ll become obvious later.
Now we need to ensure that our design will actually fly, as well as perform well, so we make some variables to track totals and performance.
Add in the air density and gravity at sea level for planet Earth, where I assume you’ll be flying.
So that’s all of our variables for the model. Now we can use constraints to add in the physics. We’re going to put all of these constraints in an array to be used by the solver, so I’ll just explain them one by one and then give a code block at the end that has them in an array. Let’s look at our first constraint.
Here we’re saying that the battery energy can’t be more than how much we can put into a battery of some mass according to the specific energy. We can do the same with the power for the ESC and the motor, using their specific power values we set earlier.
One thing that we want to make sure of is that the ESC has enough power to run the motor.
Now we can add a thrust model, which looks scary, but it’s really just this model multiplied by the number of propellers we have.
Next we add up all the masses.
We then add up the power, using the ESC power as it is the true consumption from the battery.
We also need to make sure our design flies.
The maximum hover time is the amount of time it takes to drain the batteries.
Here’s the complete set of constraints.
We'll set up our objective, or design goal, to maximize hover time.
Now we can put everything together and solve the model.
We also want to see what our result was, so we’ll take the hover time in seconds and display it in minutes.
If you run the Python file, either from IDLE or from your command line using ‘python opt.py’, you should see something like this.
If you didn't get the above, check your file against the one I provide at the end, or write your errors in the comments below.
What does all of this mean? Well, the cost is the inverse of the result for the objective we set, that’s why it has units of 1/s. The free variables are parameters that we left up to the optimizer, and the constants are values that we set. You can use the results of these free variables to help you pick out the right components from a retailer or your parts bin. Note that you can also fix the free variables according to what you have, to find what you need for the missing component. For example, we can fix the battery mass at some value.
If you ran this you'd then know what the best ESC and motor choice would be, given this battery. Sensitivities are the interesting one, they tell you how much a given design variable affects your objective. For this example the variables that make our flight time worse if they increase are gravity and mass, and things that make it better are better batteries, motors, ESCs and bigger/more efficient propellers. Note that this design is the global optimum, it’s impossible to do better than the answer given if you’re using the same inputs and model.
We now have this program that spits out magical designs, so what can we do with it? Well, you can play around with things such as different propeller diameter values, payloads or structures and see how they scale. Or you can pick out specific energy or power values for expensive batteries or motors for and see what that does. One thing that I did was take the environmental values (rho=0.02 and g=3.71) for Mars and trying to make that work. I found that you need really large values of propeller diameter to make this work. NASA has run into the same problem.
After a while you'll get bored of endurance alone, so let’s extend the model to include another performance parameter, the thrust to weight ratio of the multirotor. We add this to our objective with multiplication, and we tone down the hover time using its exponent as we don’t care that much about it anymore. So change the objective line with the following code.
We also want to add a print out for the thrust to weight ratio, so we don't have to calculate it ourselves. Add this after the printout for the hover time.
If we run this we get an insanely short hover time, because we are just making a rocket.
Let’s put a lower constraint on the hover time and now try and see what thrust to weight ratio we can get.
That’s pretty good, and you can see in the table that the design tries to keep the battery just light enough to fly with a monster powertrain. Other metrics for performance might be the payload mass fraction, total size or total mass. If you can describe something that you like in a multirotor using math, you can optimize it and make the best design possible. By tuning the exponents for each part of the objective, we can make proritize characteristics important according to our mission.
This is a pretty basic model, it doesn’t even include things like motor or ESC efficiency, so there’s definitely improvements that you can make. Also, the structures mass doesn’t change no matter how big the propellers are, and the mass of the propellers are not modelled at all. So there’s a lot you could improve on if you wanted to use this for your own designs.
The finished script is here: https://github.com/lochieferrier/gptut/blob/master/opt.py
If you’re interested in learning more about the optimization method used in this tutorial, read this (full disclosure: I work with the GPkit team as an undergraduate researcher).
Let me know in the comments if you found this useful and if you would like to see tutorials on setting up optimization for other types of UAVs (planes, helis etc). Also let me know if there are problems with the script.