Vehicle Dynamics 3DOF Single Track Block doesn't seem to include drag equations.

For the Vehicle Body 3 DOF block in the Vehicle Dynamics Blockset, I've configured it to run in single track mode. The documentation includes equations for drag forces under the dual track section, but not the single track section, which led me to believe that the drag forces are only relevant for the dual track block.

This does not seem to be the case, as I'm observing the drag forces in the output of the single track block to be nonzero. It makes sense that drag would be accounted for in both single track and dual track modes, but why then are the drag forces only described in the dual track equations?

Furthermore, the single track documentation does mention drag forces, saying that external forces = drag forces + input forces:

But then when I observe the external body forces as output by the block, they are always 0 despite the drag forces being nonzero. Seems like there might be a term overload with "external forces" referring both to the external input forces as well as the drag + input combined force.

External force input:

What I thought would be the computed external force output (drag + input forces), but is always 0 when input force is 0:

[Daniel]

It seems like the drag equations from the dual track section do apply to both the single and dual track models, but I'm confused about , as these aren't scalar constants, but vectors. How do I know what value is used when evaluating these drag force equations?

[Daniel]

Furthermore, doesn't seem to be specified anywhere in the block parameters despite showing up in the drag force equations.

[Daniel]

Looking under the block mask, I found that , , and all use lookup tables, but there's absolutely no information in the documentation to indicate this is the case, much less how the lookup works.

[Daniel]

Also, the block implementation does not even appear to match the drag equations from the docs. When I manually calculate the expected result from the provided equations, I'm getting [-87.3, 0, -29.1], but you can see from this screenshot that the block is computing [87.3, 0, -29.1].

This -K- block is scaling the air velocity vector by [4;4;0], then that is fed into the tanh block. The [3x1] block below that is set to [0;0;1] and is subtracted from the output of the tanh block. None of this is specified in the drag forces section of the 3 DOF Body documentation, so I'm very confused what's going on here.

[Daniel]

And to add another issue to the list, the documentation specifies that defaults to [0:0.01:0.3], and defaults to [0:0.03:0.9], but these default to [0 1e-6:0.01:0.3] and [0 0.01:0.01:0.3], respectively.

Answer 1

[Shivam Gothi]

Hello @Daniel,

Lets address the issues one by one:

1) Drag equations not included for Single track:

Refer to the below section of documentation.

https://www.mathworks.com/help/vdynblks/ref/vehiclebody3dof.html#d126e142360

The section named "Drag" is not included in either of the "Dual track" or "single track" section. It is printed as a seperate section, indicating that the same drag equations are valid for both, single track and dual track mode.

2) What exactly are the external forces?

I read the documentation. As per my understanding, the "Fext" appears as an input port upon selecting "External Forces" checkbox, found under "Input signals" drop-down. This "Fext" is the external input force acting on the CG of vehical (It has to be provided by the user as an input). It is not the sum of "Drag forces + external input forces". This "Fext" is represented by notation: () in the documentation.

The block calculates resultant external forces (represented by notation: ()), by adding "Drag forces () + external input forces" (), as shown in the below equation.

It uses this () to calculate other forces as shown in the below screen-shot.

3) How the equations of "drag forces" calculated ? What is the purpose of gain blocks [4;4;0] and [0;0;1] ?

The purpose of "tanh()" block is to find the direction of relative wind. Although, signum function can be used for this purpose, but the issue is, it may cause chattering problem. Refer to the graphs of both the functions. Signum function has discontinuity at zero, but tanh() is continuous function, for all values.

If you observe carefully, the output of "tanh()" block will be (-1) or (1) under normal operations. It just indicates the direction of relative wind. The gain "4" is multiplied to ensure that we stay in the yellow highlighted region, as shown below.

The gain of [0,0,1] is subtracted to ensure that "z" component of the force is (-1).

The wind direction vector is then multiplied with the calculated force in order to find force vector.

4) The defaut values of "" and "" stated in the documentation does not matches with the actual default values.

As correctly pointed out by you,

The default value of "" stated in the documentation is: [0:0.03:0.9]

The default value of "" stated in the documentation is: [0:0.01:0.3]

The actual default value of "" is: [0 0.01:0.01:0.9]

The actual default value of "" is: [0 1e-6:0.01:0.3]

But, you can observe that 1e-6 is very small and the vector [0 1e-6:0.01:0.3] will closely resemble the value [0 0:0.01:0.3]

You can contact Mathworks Technical support for the clearification.

https://www.mathworks.com/support/contact_us.html?s_tid=hc_resources

I hope you find the information useful !

[Paul]

Hi Shivam,

I'd like to focus on the aerodynamic drag model as its implemented and as it relates to the documentation.

The documentation states:

"To determine a relative airspeed, the block subtracts the wind speed from the CG vehicle velocity. Using the relative airspeed, the block determines the drag forces."

That statement sounds a bit loose to me as it mixes "speed", a scalar quantity, with velocity, a vector quantity.

These equations seem like they cannot be correct as they don't account for the direction of the relative velocity vector. For example, suppose the relative velocity vector (vehicle - wind) is exactly parallel to the x-axis of the vehicle. In this case the Fdy and Fdz should be zero, but they won't be according to those equations. It seems like each equation is missing a term that is proportional to (if not exactly equal to) the component of the relative velocity unit vector along each body axis. And the equations above will always result in all three components beting less than or equal to zero. Surely that can't be correct.

Why is the same Af used in each axis?

Cs is a table lookup. Is the independent variable for that lookup the Relative wind angle vector, beta_w ? The doc doesn't say what the independent variable is.

I haven't dug into this portion of the model and so can only comment on the screen cap above. But it's interesting that the model computes WindDir as 3-element vector, but such vector doesn't show up in the documented equations. I think I understand the intent of that tanh block, though it doesn't seem be any different than using a sign block (though I do agree that that the tanh(4*x) trick does avoid potential issues with zero crossing detection if that's turned on). So it looks to me like WindDir is trying to account for the polarity of the relative velocity vector components as I discussed above. But it doesn't take into account the relative weighting between the components of the relative velocity vector.

Can you comment on the difference between the default Cs table in the doc and the actual implementation (check the end points and the stride)?