You are using an out of date browser. It may not display this or other websites correctly.

You should upgrade or use an alternative browser.

You should upgrade or use an alternative browser.

- Thread starter Thunder Chicken
- Start date

I'm on Linux already. Understand that this uses Lua scripting. It is not a compiled module. The script should be OS-independent and not require porting. It's basically a text file that Orbiter can interpret into existing methods. Look in the /Config/Vessels/J3Script directory for the script code.

So for the stiffness and damping coefficients. I am an engineer and I *hate* tweaking numbers without understanding them. I still haven't found where these are applied in the Orbiter source code, but my educated guess is that the forced damped spring equation was used for each of the contact points:[math]mz'' + cz' + kz = \sum F_z[/math]where *z* is the displacement, *z'* is the rate of displacement, and *z''* is the acceleration. The coefficients are defined as:

Stiffness coefficient (Applied spring force per unit displacement): [math]k = F_S/z[/math]Damping coefficient (Applied damping force per unit rate of displacement): [math]c = F_D/z'[/math]

The goal is to apply physically appropriate values for*k* and *c * so the system plays nice. The applied forces will be variable, but order-of-magnitude estimates can be made at certain limits.

A basic requirement is that the contact points can support the stationary weight of the vessel with a sensible static displacement. The spring equation reduces to [math]kz = mg[/math] where we can solve for*k*: [math]k = (mg)/z[/math]In this case, the mass of the J-3 is about 450 kg, for a weight of about 4500 N and a sensible deflection would be maybe 10 cm. The weight is primarily on the main wheels, so we'll divide the weight by two. This gives a *k* = 2250 N / 0.1 m = 22,500 N/m or 2.25e4 N/m.

Now for the damping coefficient. We are aiming for a slightly under-damped oscillator (the spring will have a little "bounce" with an overshoot or two before it comes to equilibrium. Critical damping is the value that just prevents any overshoot and is defined as [math]c_c=\sqrt{4mk}[/math]For the J-3, again splitting the mass across the two main gear, [imath]c_c[/imath] would be 4500 N[imath]\cdot[/imath]s/m. We will want a damping coefficient slightly lower than this value. I'll start with*c* = 4000 N[imath]\cdot[/imath]s/m and adjust later if needed.

So something to consider is how "twangy" this system will be, more accurately what will be the period of oscillation T. If this period of oscillation comes out to be on the same order of magnitude as the simulation timestep [imath]\varDelta {t}[/imath] (simdt) or smaller, then the numerical time propagation will be unable to accurately resolve the vessel motion and this will generally lead to getting punted into solar orbit. The period of oscillation*T* is given by: [math]T=2m/\sqrt{4mk-c^2}[/math]

For*m* = 225 kg, *k *= 22,500 N/m, and *c* = 4000 N[imath]\cdot[/imath]s/m, we get [imath]T \approx[/imath] 0.2 s.

Looking into the time propagation settings, it's a little hard to determine if this is a resolvable period or not.

The Runge-Kutta routines are numerical differential equation solver routines, and I*think* the differing steps are limits associated with time acceleration (if your timestep is under 0.1 s, RK2 provides sufficient accuracy, if under 2.0 s RK4 is sufficient, etc..).

Going into the simulation and getting the value for simdt gives a value of about 0.015 s, which is about 15 times smaller than the period of oscillation. So at least we're not the same order of magnitude, so this may work out (assuming this is all correct and this is actually what Orbiter is doing under the hood).

Off for some flight testing, stay tuned...

Stiffness coefficient (Applied spring force per unit displacement): [math]k = F_S/z[/math]Damping coefficient (Applied damping force per unit rate of displacement): [math]c = F_D/z'[/math]

The goal is to apply physically appropriate values for

A basic requirement is that the contact points can support the stationary weight of the vessel with a sensible static displacement. The spring equation reduces to [math]kz = mg[/math] where we can solve for

Now for the damping coefficient. We are aiming for a slightly under-damped oscillator (the spring will have a little "bounce" with an overshoot or two before it comes to equilibrium. Critical damping is the value that just prevents any overshoot and is defined as [math]c_c=\sqrt{4mk}[/math]For the J-3, again splitting the mass across the two main gear, [imath]c_c[/imath] would be 4500 N[imath]\cdot[/imath]s/m. We will want a damping coefficient slightly lower than this value. I'll start with

So something to consider is how "twangy" this system will be, more accurately what will be the period of oscillation T. If this period of oscillation comes out to be on the same order of magnitude as the simulation timestep [imath]\varDelta {t}[/imath] (simdt) or smaller, then the numerical time propagation will be unable to accurately resolve the vessel motion and this will generally lead to getting punted into solar orbit. The period of oscillation

For

Looking into the time propagation settings, it's a little hard to determine if this is a resolvable period or not.

The Runge-Kutta routines are numerical differential equation solver routines, and I

Going into the simulation and getting the value for simdt gives a value of about 0.015 s, which is about 15 times smaller than the period of oscillation. So at least we're not the same order of magnitude, so this may work out (assuming this is all correct and this is actually what Orbiter is doing under the hood).

Off for some flight testing, stay tuned...

Last edited:

OK, that seems to work nicely. I just spent 10 minutes bouncing my J-3 down the SLF runway, and it behaves appropriately.

On a whim I took the old stiffness and damping coefficients to determine the state of damping.

Using a mass of 225 kg, this is a heavily overdamped situation. The oscillatory period is undefined, and so the relevant time are the settling times or time constants [imath]\tau[/imath] which we get from the roots of the characteristic equation:[math]r_i=-1/{\tau_i}={-c \pm \sqrt{c^2 - 4mk}/{2m}}[/math] These time constants are order of [imath]{10}^{-7}[/imath] - [imath]{10}^{-8}[/imath] seconds, much smaller than the simulation time step. I am not sure, but under certain conditions this might lead to spuriously high damping forces that cause yeeting into solar orbit. It would depend on the rate at which the dampers are compressed.

On a whim I took the old stiffness and damping coefficients to determine the state of damping.

Code:

```
stiffness_value = 1e6 --assuming N/m
damping_value = 1e5 --assuming N-s/m
```

Using a mass of 225 kg, this is a heavily overdamped situation. The oscillatory period is undefined, and so the relevant time are the settling times or time constants [imath]\tau[/imath] which we get from the roots of the characteristic equation:[math]r_i=-1/{\tau_i}={-c \pm \sqrt{c^2 - 4mk}/{2m}}[/math] These time constants are order of [imath]{10}^{-7}[/imath] - [imath]{10}^{-8}[/imath] seconds, much smaller than the simulation time step. I am not sure, but under certain conditions this might lead to spuriously high damping forces that cause yeeting into solar orbit. It would depend on the rate at which the dampers are compressed.

Last edited:

- Joined
- Feb 26, 2013

- Messages
- 507

- Reaction score
- 453

- Points
- 63

I was thinking about how it would be integrated into other addonsI suppose it wouldn't be hard to convert a script back to a C++ equivalent and compile it, but why is that necessary? The beauty of scripting is that you don't have to compile a module.

convert to C++ and include in a .dll

call up lua from a .dll

make whole addon in lua and include lua script, or call up

AFAIK all the lua functions would only be supported in future Orbiter releases, a .dll could be used in Orbiter2016 as well.

Also can I call it from a .cfg? and I don't think I can use it with Vesselbuilder? I think one can call it from a .scn file but I don't know how useful that would be?

Are there other ways to implement the script?

J-3 Cub Script Vessel Add-On by Thunder Chicken Low-poly but accurate flight model of a Piper J-3 Cub from 1937-1947 era. 100% Lua Script Vessel Add-on. It should work with OpenOrbiter March 21 2024 release or later. It will NOT work with...

www.orbiter-forum.com

Probably going to be doing a lot of work on a more realistic reciprocating engine module and a propeller model, but that will take a while before it's done.

Thanks to everyone who helped me learn how to work with the meshes and textures and sorting out the Lua scripting to make it all work. I learned a lot and (I think) made a pretty good little introductory add-on.

- Replies
- 23

- Views
- 534

- Replies
- 38

- Views
- 1K

- Replies
- 24

- Views
- 633

- Replies
- 14

- Views
- 405

Discussion
Mesh making with Blender

- Replies
- 23

- Views
- 582