Documentation: What is the math behind the Motor Model?

[TSC21]

Hi guys,

So here's the thing: I'm building a VTOL model similar to the standard VTOL which has some specifications in terms of motor setup: for example, the front motors have less torque than the back motors, which are more powerful in order to keep the vehicle balanced. The pusher motor is also different from those.

Having some time already working with Gazebo SITL, I found out that most of the vehicle models have the same motor models, pretty similar configurations and even weights. The thing is, if one wants to create his own vehicle model, with proper inertia matrix and weight, it also needs to have the motors model with the correct setup.

So after some research, and trying to figure out how to compute the different parameters that compose the motor model in the SDF config, I came up with the following math for those:

Ω or Max Rotational Velocity = Kv * Max Applied Voltage * Max Motor Efficiency * 2π / 60
Motor Constant = Thrust / (Ω) ²
Moment Constant = 60 / (2π * Kv)
Rotor Drag Coefficient = Thrust / (ρ * (Kv * Max Applied Voltage * Max Motor Efficiency / 60) ² * Propeller diameter ⁴)
Rolling Moment Coefficient = Using SST turbulence model from reference, and bent/round wings/propellers: ~0.0220 for angle of attack smaller than 16 degrees - I'm keeping this defaulted to 1E-06 for now.

where,
Kv [RPM/V]
Max Thrust [N]
Max Applied Voltage [V]
Ω Rotor angular velocity [rad/s]
ρ Air density at 20ºC: 1.2041 [kg/m³]

The Motor Time Constant is still something I don't know how to get it.

So what I ask is for help from someone that dedicated time writing the motor model plugin and that knows how's the math structured so to confirm or correct the math above. This will be helpful to everyone facing the same trouble when wanting to properly simulate their vehicle models, and not just copy paste from the existing models.

[TSC21]

Just to let you know - using the math above I was able to get a 20kg VTOL model to fly, but I'm getting a strange behavior where the vehicle, so to move into a certain setpoint, back drifts and rotates 180 degrees in yaw, and just then it starts moving into the commanded position (so basically moving on its back into the commanded position). I can confirm that this behavior is due to some weird value I'm probably inserting on the motors model parameters (computed from the math above) which makes the vehicle drift on the back motors before then moving to the commanded position, which is something weird to watch.
The RPM, Thrust and Voltage are given by a table available on the motors vendor website.

[TSC21]

I believe this will also help solving #78.

[TSC21]

@LorenzMeier, @Tumbili, @ChristophTobler, @devbharat are you able to give some insights here? The purpose for this is that anyone that wants to build is own vehicle model is able to properly do it. Thanks in advance!

[LorenzMeier]

Looking into this.

[TSC21]

Looking into this.

Awesome! Thank you!

[TSC21]

@LorenzMeier were you able to make any progress in this?

[AlexandreBorowczyk]

Hi, I'm also looking into the motor model.
@TSC21 I'm curious here you found the equation for the Rotor Drag Coefficient?
I've used the data for a small 7 inch, 800g thrust, 1450 kv propeller-motor and the rotor drag is very high.

[TSC21]

@TSC21 I'm curious here you found the equation for the Rotor Drag Coefficient?

I'm still waiting that someone clarifies and confirms this in a clear way.

[AlexandreBorowczyk]

@TSC21 I understand, I'm just curious about where the equation come from.
If you don't mind sharing, I would like to look into it.

[TSC21]

@AlexandreBorowczyk - http://m-selig.ae.illinois.edu/props/propDB.html (CT equation). Maybe I'm mixing the thrust coefficient with the rotor drag?

[TSC21]

Yeah I was doing something wrong here. I'm applying the corrections now (though is kinda hard to guess what units are being used on Gazebo side).

[TSC21]

Ok for the rotor drag, I could compute it with this reference plus the above reference:
Drag Coefficient (CD) = (CT)^1.5 / (CP * 0.707) // For static conditions, figure-of-merit is calculated
where,
CP = Power_In / (ρ * (Kv * Max_Volt * Max_Eff / 60) ³ * Propeller_diam ⁵)
CT = Thrust / (ρ * (Kv * Max_Volt * Max_Eff / 60) ² * Propeller_diam ⁴)
ρ = Air density at 20ºC: 1.2041 [kg/m³]

[TSC21]

@AlexandreBorowczyk can you test the formulas above and check if it makes sense now?

[TSC21]

The vehicle is pretty stable right now but I'm still getting the stupid behavior of rotating 180 degrees on yaw. @LorenzMeier any points/tips on what can be happening? May the inertial matrix of the vehicle interfere with that?

[AlexandreBorowczyk]

@TSC21 I've looked at the reference you pointed to as well as into the code. I suspect the equation for the
Moment Constant and Rotor Drag Coefficient to be incorrect.

The moment constant is used as such in the code
-turning_direction_ * force * moment_constant_
which mean that to determine this value you either need to have torque data or their is a rule on thumb for the ratio of force to torque for common propellers.
As for Rotor Drag Coefficient, I believe it's the resistance to linear motion of the rotor disk and not the conventional airfoil drag coefficient. I'm trying to dig deeper in the document referenced in the code "The True Role of Accelerometer Feedback in Quadrotor Control" to see how it can be evaluated.

As for the 180 degrees yaw problem, check the orientation of your IMU link in our model make sure it is correctly oriented.

[TSC21]

The moment constant is used as such in the code
-turning_direction_ * force * moment_constant_
which mean that to determine this value you either need to have torque data or their is a rule on thumb for the ratio of force to torque for common propellers.

I got the above from https://en.wikipedia.org/wiki/Motor_constants - Motor Torque Constant.

As for Rotor Drag Coefficient, I believe it's the resistance to linear motion of the rotor disk and not the conventional airfoil drag coefficient. I'm trying to dig deeper in the document referenced in the code "The True Role of Accelerometer Feedback in Quadrotor Control" to see how it can be evaluated.

I already looked at that reference without luck. Also, I believe that this drag is the combination of the actuation of the motor and the propeller, and that's why it is included both thrust constant and power in constants. That's also math I found available in the proppeler database. But I can be wrong of course. What I don't think it make sense is that we have to be looking for this math models when this could be properly documented already by who created the plugins (open-source contributions usually indicate how can people use and modify the code).

As for the 180 degrees yaw problem, check the orientation of your IMU link in our model make sure it is correctly oriented.

Already checked that many times and with different orientations with no luck. Though I can confirm that if I send a setpoint of 180 degrees on yaw, it goes forward as expected.

[TSC21]

@AlexandreBorowczyk do you have news on this?

[AlexandreBorowczyk]

@TSC21

I got the above from https://en.wikipedia.org/wiki/Motor_constants - Motor Torque Constant.

I see however this is not the coefficient we are looking for. I believe the best way to obtain this coefficient would be from experimental data. However, I also think that is you use a similar type propeller (airfoil shape and number of blades) the force to moment ratio should not be very different and you can use the default.

As for the Rotor Drag Coefficient, I see the "The True Role of Accelerometer Feedback in Quadrotor Control" paper point to a book "Helicopter Theory" by W. Johnson which I have so I will look into it and see what I can find.

However, I don't believe a motor modelisation error is the source of your issue.

[TSC21]

I see however this is not the coefficient we are looking for. I believe the best way to obtain this coefficient would be from experimental data. However, I also think that is you use a similar type propeller (airfoil shape and number of blades) the force to moment ratio should not be very different and you can use the default.

What leads to think it is not? From the calculations I do, it leads me to very similar values to the default ones.

As for the Rotor Drag Coefficient, I see the "The True Role of Accelerometer Feedback in Quadrotor Control" paper point to a book "Helicopter Theory" by W. Johnson which I have so I will look into it and see what I can find.

Great. This is the value that does not show consistency with the default ones on the simulation (gives a two degrees higher value, though it seems to work, besides the yaw issue).

However, I don't believe a motor modelisation error is the source of your issue.

Probably not but right now I cannot tell what is the problem right now.

[TSC21]

@AlexandreBorowczyk here you can find that the rotor drag coefficient is:
= D / (ρ * π * R² * (Ω * R)²), where D is the rotor drag force, R is the rotor radius and Ω is the angular velocity in rad/s, which basically becomes Rotor drag coefficient = Drag Force / (ρ * (Kv * Max Applied Voltage * Max Motor Efficiency / 60) ² * Propeller diameter ⁴). Now, when the aircraft flies level at constant velocity, all opposite forces of flight are equal. In that case the aircraft is in cruise conditions. So in that case, drag = thrust and weight = lift (https://www.grc.nasa.gov/www/K-12/airplane/ldrat.html). So we can extrapolate that
Rotor drag coefficient = Thrust / (ρ * (Kv * Max Applied Voltage * Max Motor Efficiency / 60) ² * Propeller diameter ⁴) as I described on the issue description. Is this a wrong consideration on your opinion?

[AlexandreBorowczyk]

@TSC21, Can you repost the first link it seems not to work. Nevertheless, I believe I understand your reasoning and I see possible issue. First, it is important to differentiate between static thrust and dynamic thrust, most often for a motor-propeller combo thrust spec is the static thrust. A propeller thrust is highly dependent of the air inflow velocity so it's maximum dynamic thrust (if motion parallel to rotation axis) is must smaller than it's static thrust. In addition, the rotor drag is calculated with respect to the rotor disc motion (if you does account for wind) but the the propeller thrust is only along the rotation axis (for this simplified model). Hence, the drag=thrust cannot be used in this setting. So the equation could be correct but you would need to know the drag force to get the coefficient.

[TSC21]

@TSC21, Can you repost the first link it seems not to work.

It's a file it should automatically download - www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA224493.

Hence, the drag=thrust cannot be used in this setting. So the equation could be correct but you would need to know the drag force to get the coefficient.

And how do you expect to find the drag force without simplifying the model for static thrust?

[TSC21]

@AlexandreBorowczyk any news?

[AlexandreBorowczyk]

@TSC21 I finally got the time to do a little bit of algebra and look at the simplifying the H-Force equation.
I've set to zero the terms for vertical and rotation motion and ignored the blade flapping and obtain a expression that's
matches the form H-Force = - coefficient * motor_vel * body_perp_vel. Without any guarantee on the accuracy of the result:
H-force = - 0.25 * (0.5 * λ * θt * a - Cd) * Bt² * σ * ρ * A * Ω * body_perp_vel.
with

σ = b*c*R / A (rotor solidity, ratio of blade to rotor area)

where

Vt= Ω * R (tip speed)

A= π * R^2 (rotor area)

λ ≈ √(Ct/2) @ hover (inflow velocity ratio)

θt: propeller twist [deg]

a: lift curve slop (of the airfoil) [cl/deg]

Bt: tip loss factor (~ 0.97)

b: number of blades

c: thrust-weighted chord [m]

ρ: air density [kg/m³]

R: blade length or rotor radius [m]

Ω: rotor rotational speed (rad/s)

To implement this you need first to evaluate your lift and drag coefficient in a static setup.
I would try to take a few points of data and average out the Ct and Cd obtain.

Ct = T / (ρ * π  * R² * Vt²)

Cd = 8 * Pprof / (σ * ρ * π  * R² * Vt³)

Pprof= Torque (N.m) x Ω

Consequently you need to have a rought idea of the propeller twist and airfoil shape and be able to measure the Thrust, torque and RMP in a static setup.

I could do a bit more math to include the effect of coning at hover but you would need to know the rotor blade inertia. Also due to the approximation and simplification this equation is more accurate at level flight and low advancement speed.

However, I would recommend to use SITL to evaluate "Top Level functionality" rather then physical configuration functionality as the motor_model and liftdrag (I believe you are working on a VTOL) plugin implementations are of limited accuracy.

[TSC21]

Thanks for the effort @AlexandreBorowczyk. But in a general perspective, I think the equation you came up with come to be more complicated than expected. Are we to suppose that the person who wrote the plugin use this type of math to get the values, or would be something more standard that could be find on a table (like http://m-selig.ae.illinois.edu/props/propDB.html)?

[TSC21]

Now I'm confuse: what does the H-Force represent here? Aren't we trying to get the rotor drag coefficient?

[TSC21]

It appears reading through this project the lift drag plugin is only used for fixed wing while the motor model plugin is used to model lift and drag for multi-rotors aircraft. Can someone confirm if my understanding is correct?

Yes and no. The lift drag is basically applied to control surfaces, as elevons or rudders, which you can find if vehicle capable of forward flight. So yes, it is applied for fixed wing, no it's not exclusive to fixed wing vehicle as you have also VTOLs. But generally speaking, you would want to use the motor model, unless you are willing to apply the lift-drag to individual propellers and compute the dynamics from there.

[abdullahmohiuddin]

Hi,

Great discussion here. I wanted to ask, if the motor model accounts for the thrust deficit in the forward flight?

[mvernacc]

@mvernacc Thank you very much for your tutorial, how this values might have been calculated. I went through your calculations and may have found a small error. In eqn(3) you state that C_q =C_p/(2_Pi). But in chapter 4, where you are presenting an example it says: C_p0 is 0.051, which assumes C_q0 is 0.32. But if we assume eqn(3) is correct it rather should be: C_q0 = 0.051/(2_Pi)=0,0081. At the end the moment_constant_ is C_q0/C_t0_D = 0.0081/0.11_0.23m=0,0169m. Where the current default moment_constant_ is 0.06.
Kind regards

@Chraebi thanks for catching the error, I fixed it here: mvernacc/gazebo_motor_model_docs@9275d82

[wil3]

Would someone mind explaining how to derive the time constants (tau)? I'm having difficulty finding any sources that describe the processes.

[wil3]

Some updates other may find useful. I was under the assumption the time constant was the time to reach 63% of the max motor velocity however this was giving me poor results. After some experimental measurements there were a couple interesting things I found.
The first, the motor model makes the assumption there is a linear relaptionship between the control signal and the RPMs. For my quadcopter this was not the case as you can see in the figure below,

I fit the data to a 2deg polynomial and use this in the plugin to map to the correct target motor velocity. The second thing I noticed was the filter was a poor approximation of the motor response. I found better luck using a P controller off of the reference velocity. I then use different values for cmdMin and cmdMax to control different accelerations and decelerations. I will note however I am not using these plugins with Px4 but rather GymFC which is why this solution may work for me. There is a comment in the code that the PID controller does not work with Px4. All details will be released in a paper soon if anyone is interested.

[zaccer]

Can anyone here provide successfully implemented equations to change the parameters in the motor model plugin. I have followed the notes provided by @mvernacc but can only calculate the motor and moment constant using it. Since other equations are not that clearly defined.

[mzahana]

@TSC21 @hamishwillee are there any updates regarding corresponding documentation?
I have a custom model in Solidworks and used SW2URDF tool to get a URDF model. Then, I used gz sdf -p foo.urdf > foo.sdf to get an SDF file. I tried to mimic iris.sdf to add the required plugins into the SDF file. Also I added the required files in sitl_gazebo/models and Firmware/ROMFS/px4fmu_common/init.d-posix/. I was able to launch posix-sitl.launch and the custom vehicle appears in Gazebo. I am also able to send takeoff command using commander takeoff. However, the quadcopter does not takeoff. I am assuming that the the main problem is the incorrect values of the motor model. I believe that the mass and inertia values are fairly correct as the model is designed carefully in Solidwroks with the right materials.

So, are there any updates/documentation regarding how to model the motors used in SITL?

Thanks.

[hamishwillee]

@mzahana No updated docs. This happening depends on @TSC21 or someone else who understands the modeling making it happen. Is it possible to further test the assumption that it is the motor modeling that is the problem.

Nuno, got any advice? There are a couple of modeling cases like this that have been sitting as questions for a long time. Are there any other people you could recommend might be able to help us expand on these docs?

[luuxx]

I'm trying to get a model working with the T motors f80 pro 1900 Kv and I was wondering if some one was willing to double check my math. Also if I did make a mistake feel free to explain what I did wrong as math like this isn't my strong suite.

Gazebo motor calculations.xlsx

I was basing it on the information as found here.

Edit: Noticed I needed to use Feet for propeller diameter and not meters, This was not clear.

[mysterxous]

I'm trying to get a model working with the T motors f80 pro 1900 Kv and I was wondering if some one was willing to double check my math. Also if I did make a mistake feel free to explain what I did wrong as math like this isn't my strong suite.

Gazebo motor calculations.xlsx

I was basing it on the information as found here.

Edit: Noticed I needed to use Feet for propeller diameter and not meters, This was not clear.

@luuxx I think max motor efficiency is wrong. The motor efficiency on the information is thrust/power [g/w].The max motor efficiency should be around 0-1[dimensionless].

[fabrizioschiano]

Hi, I read the whole discussion and I found it really interesting. Thanks to all the people participating in this.

I am also looking into this topic and I found that in the discussion is missing one point that might be either stupid or that I might have just missed.

The whole point of the discussion and why it started (as far as I understood) is that the documentation of a specific plugin (libgazebo_motor_model) related to the motor model is missing. Is anyone aware of who is the author(s) of this particular plugin? Anyone in contact with the authors of these plugins?
Maybe we could get in touch with them to understand what is their thought about the whole discussion above. Moreover, they might help us in understanding what was their thought when they implemented the plugin.

[mzahana]

@LorenzMeier Is this issue resolved?

[LorenzMeier]

This was never an issue in the first place. It was a question with a lengthy discussion. Please use the forums.

[Jaeyoung-Lim]

@tayyabkhalil-313 Please dont hijack this thread with a topic that is not related.

[Palanisamy-student]

Max Motor Efficiency

what is the unit of max motor efficiency used here? and how it has been derived ?

[DronecodeBot]

This issue has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there:

https://discuss.px4.io/t/gazebo-sdf-file-motor-parameters-definitions/34747/1

[DronecodeBot]

This issue has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there:

https://discuss.px4.io/t/there-is-a-significant-discrepancy-between-the-simulation-results-and-the-real-world-experiments/34678/2

[DronecodeBot]

This issue has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there:

https://discuss.px4.io/t/heavy-drone-climbs-unresponsively-after-takeoff-in-px4-sitl-gazebo/39412/5

[DronecodeBot]

This issue has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there:

https://discuss.px4.io/t/heavy-drone-climbs-unresponsively-after-takeoff-in-px4-sitl-gazebo/39412/21