1

QuadCopter Dynamics and Controls: Ramp-Up Reading…

I started to sketch a quadrotor model myself and derive the equations of motion, but I lost confidence and figured it would be best to sample the literature first. Below is a list of papers I found online. Click the links to see the papers.

All the papers are useful, but I found the, “PID vs LQ Control Techniques Applied to an Indoor Micro Quadrotor” by Bouabdallah et al. to be a most useful reference. It is becoming my primary basis for understanding and modelling the system I need to design a controller for.

PID vs LQ Control Techniques

modelling_of_quadrotor_minicraft

design_of_four_rotor_aerial_robot

Thesis KTH – Francesco Sabatino

State Space System Modeling of a Quad Copter UAV

Modelling of the ETH Helicopter

linearization

A goal here is to develop a dynamic model and controller scheme as a platform for learning and applying, “Optimal Control and Estimation” techniques.

The multi-input model can be broken into a set of independent PID servos for level flight (hover). It will be interesting to retain the coupled system in which roll, pitch, and yaw terms interact over a larger, “flight envelope” (larger roll and pitch angles) and not just small control action from level flight. It might not be necessary for much practical flying, but we’re going to follow some advanced topics for the fun of it.

The Bouabdallah paper above doesn’t jump to model simplifications and linearizations. It maintains consideration for gyroscopic effects because the focus is on a lightweight, presumably highly dynamic platform. I’m also intrigued by the, “successive linearization” concept presented.

We’re going to get a better grasp on model linearization through this exercise. We’re going to better understand how to modify the, “state transition matrix” (typically termed matrix ‘A’ for continuous control models and ‘F’ for discrete-time models). Hence the, “Linearization” paper above.




Dynamics and Controls Study Materials

I’ve enjoyed great opportunities to both study and work on mechanics, electronics, real-time control systems and supporting software for automated machines: Agricultural machine control for the most part, and some neat control systems problems in communications, sensors,  and other areas.

Dynamic Modelling

One thing I really like about, modelling a dynamic system is you need to be creative to arrive at an appropriate model, or mathematical representation of a system. It is just like a scale-model in that it isn’t the, “real thing”. It is something that represents the actual system, in a form simple enough to apply some math to, but not so complicated that you can’t solve the equations into some control electronics and software.

This modelling step is my favorite part. It is the most important part. If it’s too complicated I can’t work with it. If it’s too simple, it means I’m probably ignoring something in the real world that would make any system design fail to do the job correctly. There really is not much math at this point, but a sketch and an accounting for what goes in, and what goes out: the stimuli you expect to make the system do it’s work, and also the forces of nature that want to move the system in ways you can’t always know, but need to manage somehow.

Differential Equations Comprise the Model

Because we’re dealing with dynamic systems we’re talking about differential equations to represent them. This just means an equation that describes, given where something is (it’s current state), where it is going based upon some attributes and some forces acting on it right now.

It’s kind of like this: if you know where you are standing, you know how heavy you are, and how strong your kid is who is trying to push you out the door to drive him to a friend’s house, we might know how much closer to the door you will be one second from now.

These Differential equations are the mathematical model of a dynamic system. At this point of our model they might be too complicated for us to do much with, so we might need to decide if there are terms we can ignore because they will have a small effect, or maybe we need to linearize the system by making some assumptions about the range of action (motion) we expect relative to perhaps a typical operating point.

Creativity

Proper simplification requires creativity. There are so many great examples of similar problems (especially now with the vast resources of the internet) that it is fun to borrow techniques and sometimes combine techniques from different problems to a problem at-hand. The best ideas are typically stolen.

In order to be creative and confident in our modelling of the Quad we’ll need a solid foundation. Here are some references I often revisit.

Control Systems Basics: review of the old studies

This is introductory Controls textbook.

This is introductory Discrete-time controls text that builds on the text above. Most controllers today are implemented by a digital computer that samples sensors and outputs actuator commands on a, “sampling interval”.  We model this sampling and the math is a bit different (Z-transform in place of Laplace transform in the continuous time case). This is a good reference.

New Material…

I haven’t systematically studied “Optimal Control and Estimation” so after some old notes were challenging me I bought some books.

This looks like the classic text on this subject. I also found a great reference for working through the text:  Weatherwax_Stengel_Notes and some MATLAB samples  here

.

These last two were listed along with the Stengel book as some of the best, so I picked these up too. I’m a bit into this first one from 1970. I like some of the pre-personal-computer era books because they often tend towards math and hand calculations that promote deeper understanding. Newer texts jump to Matlab examples right away. This is great, but the old-timers did a lot with slide rules and solid understanding.

I desired to brush-up on the Lagrangian method for deriving equations of motion. I found a link to a great reference online, and I bought a couple books from the guy! His name is David Morin from Harvard, and his classical mechanics materials look excellent…he also strikes me as a fun person in his presentation of materials.

OK, enough with the books already. If you’re in school now or studied these topics before you may have similar, suitable references.




Finalizing Equations Of Motion: Thrust Inputs from Propellers

This post explains how we determine propeller thrust and drag factors for our quadcopter project.

The last couple posts have been working-out the sum-of-torques on our quad-copter. We covered gyroscopic effect of the total air-frame in the, “equations of motion” post a few weeks ago.

Next we looked at the torque induced by the gyroscopic effects of the spinning propellers in the last post.

Now we’ll consider the propeller drive inputs.

Propeller Drive Control Input

We started the, “equations of motion” with the sketch below, so we’ll use it again here as we model the command inputs from the propellers: F_{1-4}.


ref_frames

Torque About Body X-axis

Assume the length of the arm from the center of the quadcopter to the propeller is, ‘l’ then…

\tau_x=F_2\cdot l - F_4\cdot l

The, ‘F’ terms are thrust forces. We know from an earlier post that this thrust from a propeller is going to be a function of propeller speed squared: \Omega^2:

F = b\cdot\Omega ^2

Where, ‘b’ is a, “thrust factor” we need to determine. After you watch the video below you’ll understand how we get…

b =\frac{C_t\cdot\rho\cdot D^4}{4\pi^2}

where…

C_t = experimentally \ determined \ propeller \ thrust \ coef.\\ \rho \ \ = \ air\ density.\\ D=propeller\ diameter.

our torque about the X-axis equation above becomes…

\tau_x= bl(\Omega _2^2-\Omega _4^2)

Torque About Body Y-axis

\tau_y=F_1\cdot l - F_3\cdot l

By the same logic above for the X-axis torque, this Y-axis torque becomes…

\tau_y= bl(\Omega _1^2-\Omega _3^2)

Torque About Body Z-axis

The torque about the Z-Axis is proportional to the squared angular velocities of the propellers. We subtract the squared counter-clockwise props from the clockwise props to lump them. The proportionality constant (the multiplier) is going to be a, “drag factor”: d.

See the video for an explanation on how we get ‘d’ from the experimentally determined, “power coefficient” for a candidate propeller.

\tau_z = d\cdot (\Omega _2^2+\Omega _4^2-\Omega _3^2-\Omega _1^2)
d =\frac{C_p\cdot\rho\cdot D^5}{8\pi^3}
C_p = experimentally \ determined \ propeller \ power \ coef.\\ \rho \ \ = \ air\ density.\\ D=propeller\ diameter.

Deriving the, ‘b’ and, ‘d’ terms above

‘b’ is our thrust factor and, ‘d’ is our drag factor. They are arrived at through experimentally determined thrust and power coefficients for our propeller. We encountered the drag term earlier earlier (here) but we didn’t have insight into how it’s arrived at.

An excellent resource is offered by the University of Illinois and Urbana-Champaign: the UIUC Propeller Data Site. There are wind-tunnel data for a variety of hobby-craft propellers. The following video explains how we could arrive at our drag and thrust factors through measurement.

Propeller Thrust Coefficient

Let’s estimate the thrust coefficient from the, “static” data because a quadcoptor is not going to travel very fast along the axis of the propellers. A preliminary estimate for the static thrust coefficient after looking at a number of experimental data sets is…

C_t =0.1

From this we can calculate, ‘b’ as described above.

Propeller Drag Coefficient

Recall the motor+gearbox+propeller post. There we look at now to map the torque load of the propeller back through the gearbox to the motor shaft to get all the parameters correct in modelling the DC motor drive. In that post we have

“Aerodynamic torque for rotor R:    D = 2.91\times10^{-7} \frac{Nms^2}{rad^2}    (page 9, Gafvert) for what looks like a comparable hobby-sized propeller lab set-up”.

We didn’t see how this term was derived though.

Confusion…

It’s a challenge (for me at least) to find a propeller, “drag coefficient” explicitly stated in many references. 

Then I read, “While an airfoil can be characterized by relations between angle of attacklift coefficient and drag coefficient, a propeller can be described in terms of advance ratiothrust coefficient, and power coefficient” here. That statement cleared some fog.

Next I found an online question from a person facing the same confusion I was experiencing. The question married the above quote to the same UIUC data I was looking at. The dialog there ultimately gets to a drag term resolved from the UIUC, “power coefficient”.

From there I made sense of it and as expressed in the video above. I derive my, ‘d’ term from the experimental, “power coefficient” as explained in the video. As the video explains, I’m estimating…

C_p=0.7

For the APC Carbon Fiber 7.8-inch propeller, if we plug-in numbers we calculate, ‘d’ as…

d =\frac{C_p\cdot\rho\cdot D^5}{8\pi^3}=\frac{(0.7)(1.23\frac{kg}{m^3})(0.175m)^5}{8\pi^3}=5.65\times10^{-7} Nm s^2

This is close to the number from page 9 of Gafvert above. We don’t know what specific propeller he is referencing, but we know it is in the family of these hobby propellers. We can be satisfied with this method for arriving at our drag factor from the UIUC data.

Conclusion…

We now have a good understanding of our thrust and drag factors for our propellers.

When we get into the design iterations we might try other propellers with different coefficients. We can revisit the UIUC data and compute a range of, ‘b’ and, ‘d’ terms as we did above. This is how we can assess propeller selection impact on performance of our quadrotor.




Linear Quadratic Control with Reference Input

[latexpage]The last post was our introduction to the Linear Quadratic Regulator (LQR). We saw there that as we started with initial conditions or introduced a disturbance the LQR will drive the states to zero. In the simulations we saw the graphic of the copter converge on the zero state: zero roll, pitch, yaw, and respective rates all to zero.

The, “Control Law” (feedback gain K) was obtained through a solution of the matrix Ricatti equation buried in Matlab. We’ll dig into that math at some other time.

This same solution is relevant for the, “tracking” problem or servo case: when we desire the plant to be controlled to a particular set of non-zero state values.

Basic Idea

We can think of it as the reverse of our last simulated cases where we started with non-zero state initial conditions (some angles for roll, pitch, and yaw) and observed the platform converge on the zero-state attitude.

Think of this new problem as starting with zero initial conditions (a level quadcopter) and desiring the attitude, “step response” to a non-zero input.

This is a bit artificial for the quadcopter because a non-zero attitude will mean thrust in a particular lateral direction which we are ignoring at present. Our controller design will still be relevant, as this is the attitude control loop.

Ultimate Goal

Later we’ll introduce an outer position control loop that supplies the reference inputs to the attitude controller: the reference input that is the topic here. In flight it will not be a set value but a continually changing attitude reference input based on the outer position control loop’s desire to move the platform by altering the attitude and the resultant thrust vector.

Before we can illustrate how an outer position controller will command attitude to this inner attitude controller we need to understand how to introduce the reference for roll, pitch, and yaw.

The respective rates are states also, but our goal is to regulate these to zero as the attitude tracks the body angle input reference. Our reference vector will supply zero for the rate states.

Theory

Feedback Control of Dynamic Systems by Franklin, Paul, and Emami-Naeini introduces the topic via the material below. The following page copies are from a 1994 edition of their textbook.

Quadrotor Implementation

We are dealing with more states and a multi-input, multi-output (MIMO) problem. The equation to solve from the reference above is shown here with bold matrix elements representing matrices themselves.

Our ‘A‘ and ‘C‘ Matrices are 6×6. The ‘B‘ and ‘D‘ Matrices are 6×4. This results in the matrix needing an inverse being 12×10, which is non-invertible. On page 510 Stengel writes we can employ the right pseudoinverse in this case.


\begin{equation}
\begin{bmatrix}
\mathbf{N_{x}} \\
\mathbf{N_{u}} \\
\end{bmatrix}
=
\begin{bmatrix}
\mathbf{A} & \mathbf{B} \\
\mathbf{C} & \mathbf{D} \\
\end{bmatrix}^{-1}
\begin{bmatrix}
\mathbf{0} \\
\mathbf{1} \\
\end{bmatrix}
\end{equation}

We can then solve for the reference gains. The resulting Nx is 6×6. The resulting Nu is 6×4. We now have the matrices we need to operate on our state reference.

Nx and Nu are simplified into a composite gain in the second block diagram according to the reference textbook above:


\begin{equation}
\bar{N}=N_u+KN_x
\end{equation}

We’re now ready to see how the quadrotor LQ controller will track a reference input. The controller gain matrix K is from our LQR solution, so it’s the same controller.

Matlab Simulation

This Matlab script is a generalized version of the script in the last post covering the LQR simulation. In this script you will see the reference gain N is established and applied to a reference input. Yaw-axis sinusoidal reference tracking is illustrated in the following video generated by running the script.

You’ll need the same three additional files from the last post (see the matlab script section near the end).

Download the script, find yourself a Matlab seat, and explore!

Quadrotor Reference Input Tracking: a yaw-axis sinusoidal reference

Conclusion

We’ve covered how to solve for the reference input gain matrix and modified our LQR Matlab simulation script accordingly. The simple simulation shared in the video above indicates we’re stable and generally tracking the yaw sinusoid.

There’s more to do in this area: examine disturbance rejection, tracking performance, and general analysis of our LQR controller. Through this process we’d apply some performance assessment metrics and iteratively adjust our cost function weights.

We’re not yet to a real design and iteration process yet. We’re still building the tools and the understanding of how this MIMO Linear Quadratic quadcopter math works.

Happy Learning!




Maximum Thrust vs. Battery Voltage

[latexpage]

In a previous post we got the Ardupilot simulator stable running the linear-quadratic attitude controller, but we had a hack in-place for normalizing our body torque commands from Newton-meters to -1 to +1 for input to the Ardupilot motor sub-system.

Purpose

This post uses a test stand to measure maximum available thrust over a range of supply (battery) voltages in order to gain a normalizing constant we need for the output commands of our linear quadratic controller. With normalized commands we drive -1 to +1 commands into native Ardupilot motor code which in-turn drives PWM outputs to electronic speed controllers (ESCs).

Equipment

After all the modelling and equation solving for the motor-prop assembly in previous posts I’ve been wanting to take some measurements. I found a reasonably priced test stand from Tyto Robotics: their model 1520. I purchased the add-on optical speed sensor. All-in with shipping was near $200.

Here’s the 1520 on my bench with the AIR2216/880Kv motor and T1045 prop that comes with the Hexsoon EDU-450 kit. On my setup here you can see a green LED on the RPM sensor board as well as the reflective tape on the motor rotor.

Problem

In the Linear-Quadratic controller implementation within the Ardupilot Attitude Controller we’re calculating roll, pitch, yaw command outputs as Torques. Challenge is, Ardupilot motor code desires normalized roll, pitch, and yaw commands scaled -1 to +1.

Focusing on a single axis, say roll, once we have a roll torque to command on each iteration we need to cram a normalized roll (-1 to +1) into the Ardupilot motors object. From there it will result in PWM output to electronic speed controllers (ESCs) to drive the motors.

Roll torque is differential thrust from a cross-body pair of propellers multiplied by the arm length. If we divide our controllers command torque by arm length we get this differential thrust command but…

How to normalize it for the Ardupilot motors and PWM stack of code?

  • We need a maximum thrust
    • with added twist that it’s voltage-dependent as battery voltage drops during flight.

Solution

Characterize the motor-prop assembly maximum thrust as a function of battery voltage. Call it, Thrustmax.

Given Thrustmax and also run-time battery voltage sampled in real-time, scale Thrustmax down to a Thrustavailable.

Then at run-time we’ll normalize that differential thrust for roll and pitch with a divide-by Thrustavailable (first clamping the differential command to +/- Thrustavailable ). This will give us a normalized -1 to +1 roll and pitch to command the resident motors object in Ardupilot.

Yaw is different as it’s driven by propeller drag force and resultant moment induced about the craft’s center. We’ll look at that later.

Max thrust derating by battery voltage

The first plot below illustrates what to expect for thrust as our Lithium Polymer (LiPo) battery voltage drops during flight. A single LiPo charged cell is nominally 3.7 volts to 4.2V. We’ll likely use a ‘4S’ configuration (4 cells in series) for nearly 15 Volts at max charge.

I don’t yet know what a low voltage cuttoff will be. I read maybe 3.2V per cell which means our minimum operating voltage might be say 10-12V. In any case I tested with my bench supply as follows in order to produce data seen here.

Procedure

  1. Set bench supply at 15V.
    • This is source voltage to the ESC driving the motor on the test stand shown above.
  2. Step ESC from 1000 to 2100 with intervals of 100.
    • This results in a 1-2ms pulse to the ESC in 100 microsecond steps.
  3. Hold each step.
  4. Sample motor speed and torque mid-step.
    • When the step’s steady-state is established.
  5. On pause after last step.
    1. lower battery voltage.
  6. Jump to step 2 above.

Measured Thrust over ESC range by Battery Voltage

We’ll get our data off the 2-D plot below. These 3-axis plots illustrate the test runs and reveal the relationship between battery voltage, ESC command, and measured motor speed and torque.

plot: Thrust output by ESC command input over range of Battery voltage.

Thrust derates with voltage because the maximum RPM drops with voltage. You can see this in the following plot where we’re plotting against measured RPM instead of command. We don’t actually drive thrust, we drive motor speed, which in turn provides thrust proportional to RPM squared as described in an earlier post.

In the perspective view here you can see it’s actually RPM that is dropping with lower voltage, and consequently thrust. Thrust it our output of interest though.

plot: Thrust output vs RPM output from ESC command over range of Battery voltage.

What we care about is the maximum thrust possible as a function of battery voltage. Note from the plot below how no-load battery voltage droops up to max thrust (RPM) for each step. Let’s take our voltage difference from the loaded maximum drive output for the first and last step. We’ll take the thrust difference and get our slope. It’s nicely linear.

\begin{equation} 
 \Delta V = 13.75 – 8.25 = 5.5V
\end{equation}

\begin{equation} 
 \Delta Thrust = 10.5 – 4.5 = 6N
\end{equation}

\begin{equation} 
 m = \dfrac {\Delta Thrust}{\Delta V} =\dfrac{6N}{5.5V}\approx 1\dfrac{N}{V}
\end{equation}

Plot: Maximum Thrust at Battery Voltage

Run-time equation for our normalizing value: Thrustavailable

The equation here will replace the normalization constants described in an earlier diagram. Our interest then was to get stable with the simulator, so we hacked-in a scheme. Here we’ll have an acurate divisor for the -1 to +1 motors input range.

\begin{equation} 
 Thrust_{available} = Thrust_{cal} + m\cdot(V_{batt,current} – V_{batt,cal})
\end{equation}

Conclusion

We’ll confirm these results with a battery stack instead of a bench supply to finalize our numbers, but it looks like we have a tidy linear derating to apply here. We’ll calibrate somewhere near a fully-charged battery pack voltage and store these two parameters for Ardupilot:

  • Thrustcal (Newtons)
  • ThrustVcal (Volts)
  • ThrustSlope (Newtons per Volt)
    • This is unity above but we’ll store it anyway

The above run-time equation and application of these parameters will cover cases where run-time voltage is higher than the calibration voltage.




Gyroscope History: Lead Computing Gunsights

In this post we’ll dissect and simulate basic concepts embodied in early gyro instrumentation applications in combat gun sights. We’ll build a deeper understanding of gyro mechanics through this application of their first principle: output torque resulting from precession. We’ll learn some interesting history too.

The basic problem to solve is this: when we fire a ballistic projectile how can the sight compensate to have the projectile intercept a moving target down range? We desire to hold the sight on the target and not guess how much to lead it by.

The British did early work in the Mk IID sight that was also produced in the US by the Sperry Gyroscope Company as the K-14 that saw use in US fighters during WWII. Charles Stark Draper started working in the same area in 1940 out of his Instrumentation lab at MIT.

Charles Stark Draper’s Gunsight Designs

Draper’s first efforts in naval gunnery stemmed from a prototype he built in 1940 illustrated here. If some independent sensor could measure the crossing speed of the target paper, “Doc” is targeting and simultaneously know the line-of-sight of the barrel axis this independent actor could command the site in the “shoebox”.

The complicating factor is that the shoebox is the actor measuring the target crossing rate (drop rate too) by way of integrated gyroscopes. It is the, “computer” that assumes its own rates represent the target’s. This will present a problem we’ll cover below: tracking instability.

From Air Power History (SUMMER 2009 – Volume 56, Number 2), page 32 (full PDF below)

From this early, “shoe box” effort Draper designed anti-aircraft fire control systems for WWII ships. This became the Mark 14 sight manufactured by the Sperry Gyroscope Company. There’s some interesting information here.

From https://forums.spacebattles.com/threads/doc-drapers-shoebox-the-mark-14-gunsight.824442/

John H. Blakelock’s, Automatic Control of Aircraft and Missiles, Second Edition Chapter 9 and Appendix J present Draper’s later work on the A-1 air-to-air sight. Blakelock writes on page 324 that Dr. Draper, “was probably the first person to completely understand the tracking instability phenomenon and was thus able to solve this troublesome problem”. This might be generous towards, “Doc” as he was called, given the amount of varied work in this field. Click the image below for book information.



There’s a hint to this, “tracking instability” problem in training material for the Naval sight Mark 14 highlighted below. Our simulator will reveal why the Navy gave this advice. When a gunner increases slew rate of gun to catch-up to a target the pipper actually moves backwards in a manner that can confuse settling to smooth tracking. However, as you slow from ahead of a target this effect is less dramatic and easier to track to zero. We’ll make sense of this problem and identify how Draper and others mitigated the problem.

Mark 14 Naval Anti Aircraft Gun Sight Operating Advice

Draper’s A-1 Gunsight

Blakelock’s Appendix J introduces Draper’s later A-1 and A-4 air-to-air gun/rocket sight design. They were too late for WWII, but achieved some fame in the F86 Sabre vs. MIG battles over Korea in that later conflict.

The A-1 sight incorporated radar ranging. This eliminates the manual stadiametric ranging involving throttle grip twisting to close a concentric ring in the HUD on the wingspan of a target after having manually clicked the sight to specify target size. The promise of radar ranging eliminated this tedious process, but not without some growing pains as described in the article below, extracted from Air Power History (SUMMER 2009 – Volume 56, Number 2).

If you don’t read the entire article, scroll to the end and read the last paragraphs discussing the concepts of a, “heterogeneous engineer” and, “innovative departure”. These are relevant notions when attempting to gain traction when innovating in any industry or area.

Next Up…

With the above history a guide, the next post will present a simplified dynamic model we can use to investigate the, “tracking instability” problem in particular. There will be some matlab code to share so you’ll be able to play with the model yourself.




Motor-Prop Model Validation

[latexpage]

In a recent post we used the Tyto 1520 test stand to get at a maximum thrust available from our motor-prop system. We want that maximum thrust so we can normalize our LQ controller command output for the Ardupilot motor command as outlined here. The Tyto 1520 offers great value for under $200.

While we have it set-up, let’s also have some fun validating our motor-prop equation and parameters!

Review Motor-Prop Mathematical Model

Modelling the motor-prop assembly is where the quadcopter deep-dive started way back here. Since that time we took some time to appreciate propeller fluid mechanics, and drag and thrust coefficients. We started with this…

\frac{d\omega}{dt} = A\omega + Bu +C

Where…

A = -(\frac{K_m^2}{RJ} + \frac{2d\omega_0}{\eta r^3J})
B = \frac{K_m}{RJ}
C = \frac{d\omega_0^2}{\eta r^3J}

But as rationalized here we eliminated the, ‘C’ term and adjusted the A term accordingly to arrive at…

\begin{equation} 
 \frac{d\omega}{dt} = -(\frac{K_m^2}{RJ} + \frac{d\omega_0}{\eta r^3J})\omega + \frac{K_m}{RJ} V
\end{equation}

Where, ‘V’ is DC voltage. By inspection we see this equation tells us that on the moment we apply a voltage, ‘V’ the term multiplying it is all about the motor-prop ability to spin-up while the negative term preceding on omega enforces the drag.

Another way to think about it is to observe that at some steady-state for a constant voltage input, ‘V’ if we remove V that second term becomes zero and the first term conveys spin-down of the system due to mechanical and electrical effects.

Comparing the step-response of our model using Matlab to data we collect on our test stand permits us to check some parameter assumptions to this point.

Test Stand Step Response

The Tyto RCbenchmark software permits scripting a step sequence to maximum output. The test stand is set-up to step from zero to 20%, hold, then step to 100% output. This step from spinning at 20% to maximum is our reference for model validation.

The red dots below represent the step from 10% to 90% RPM output on the transient from 20% spinning start to 100% from the electronic speed controller (ESC). This indicates a step response of 4.33-4.18= 150ms. We don’t step the prop from a dead-stop.

The start-up motor dynamics are too messy to contend with. Think of it like not wanting to model, “stiction” or what it takes to get something sliding. We want to make a step-change once sliding and avoid all the unknowns from zero. Hence we start our test stand from 20% output on the electronic speed controller, which produces near 3200RPM.

We’ll start our simulator from the same 3200 RPM too, although it doesn’t suffer from a zero start because it’s an ideal, first-order model, albeit with modelled nonlinearity in omega.

Tyto test stand output: step-response

Steady State Comparison

The first thing we want to do is check our parameters at steady-state

  • Set V to max test voltage = 13.85 V
    • This is the Maximum at steady-state with voltage droop from 15V on our test stand so…
    • Use this for steady-state model voltage
  • Steady-state so…

\begin{equation}  \omega_0 = \omega \end{equation}

\begin{equation}  \frac{d\omega}{dt} = 0 = -(\frac{K_m^2}{RJ} + \frac{d\omega}{\eta r^3J})\omega + \frac{K_m}{RJ} V \end{equation}

Rearranging…

\begin{equation}   \frac{K_m^2}{RJ}\omega^2 + \frac{d\omega}{\eta r^3J}\omega – \frac{K_m}{RJ} V = 0\end{equation}

Quadratic equation to solve for omega…

\begin{equation}   \omega = \frac{-K_m^2+\sqrt{K_m^4+4RdKV}}{2Rd}\end{equation}

Our largest uncertainty is likely the, ‘d’ term: the drag coefficient for our propeller. Motor resistance, ‘R’ is another uncertainty, while motor constant Km is had from 1/Kv where Kv equals the advertised 880 RPM/Volt.

Estimate Drag Factor From Test Stand Data

We measured max 9500 RPM (~1000 rad/s) above at Vmax=13.85 so to solve the above equation for our most uncertain parameter pair R and d.

  • ω = 1000 rad/s
  • V = 13.85
  • Km = 1/Kv = 1/880 RPM/volt = 0.011 (converting to radians and seconds)

Rearrange the Quadratic equation and solve for Rd…

Rd = 3.135 x 10-8

where

\begin{equation}  d = \frac{P_{const} \rho D^5}{8\pi^3} \end{equation}

If we take motor resistance as 0.115 ohms our test stand estimate for drag factor, ‘d’ is…

d = 2.73 x 10-7

Model Drag Factor

The model gives d=1.5 x 10-7 when we accept the Ardupilot SITL script assumption for propeller power coefficient Cp=1.13. Both model and above operation on test stand data assume same value for motor coil resistance of 0.115 Ohms.

For Cp=1.13 the model also produces a higher steady-state result. observing the figure below

Model Step Response with assumed Cp=1.13 from Ardupilot SITL script

Model Parameter Adjustment

Changing the model power coefficient to Cp=2.25 yields a steady-state RPM in-line with the test stand result and a rise time that is still within 15% of the measured rise time (129ms below compared to 150 above). The test stand output plot indicates some higher-order response from zero. We don’t have those dynamics modeled. Given we have some unmodeled higher-order 129/150= 86% match on rise-time with match on steady-state is close.

Let’s conclude that our SITL Cp is too low at 1.13, and that Cp=2.25 is closer to actual than 1.13.

With model Cp=2.25 the model’s drag coefficient d = 2.97 x 10-7, within 10% of our estimate of d = 2.73 x 10-7 for the test stand.

Model Step-reponse with Cp Adjusted to better match test stand output at steady-state

Conclusion

Motor-propeller power coefficient (Cp) taken as 1.13 from the Ardupilot SITL (simulator in-the-loop) appears low. Increaing model Cp to 2.25 produces a close match on steady-state output between test stand and model for a modelled-as-same voltage step input.

Cp=2.25 yields a rise-time estimate 15% faster than the test stand. However, considering the higher-order response from intitial RPM for the test stand that we don’t have modelled this appears reasonable when examining the plots above. If the model rise from zero were higher-order like the test stand reveals this would increase the first-order simulated rise time of 129ms above, closer to the measured 150, closing the 15% error to some degree.

With Cp=2.25, a close match on steady-state output and a model simulation rise-time within 15% of measured, given our somewhat crude tools and basic methods here, let’s call the model, “validated”!