Question ASCII-3 (Lua Script J-3 with mesh made with Notepad) Adventures and Questions

Matias Saibene

Developing and CMakin'
Joined
Jul 7, 2012
Messages
1,116
Reaction score
749
Points
128
Location
Monte Hermoso - Argentina
Website
de-todo-un-poco-computacion-e-ideas.blogspot.com.ar
Maybe I should make a car add-on? :unsure:

View attachment 38859
I think it's great that you've find out the formula to run a car on Orbiter. I'm still looking for a way to run my car and I'm also planning to make a cross-platform Orbiter car add-on. So if you're thinking of making a car add-on, you can consider me for porting it to Linux.
:cheers:
 

Thunder Chicken

Fine Threads since 2008
Donator
Joined
Mar 22, 2008
Messages
4,679
Reaction score
3,665
Points
138
Location
Massachusetts
I think it's great that you've find out the formula to run a car on Orbiter. I'm still looking for a way to run my car and I'm also planning to make a cross-platform Orbiter car add-on. So if you're thinking of making a car add-on, you can consider me for porting it to Linux.
:cheers:
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.
 

Thunder Chicken

Fine Threads since 2008
Donator
Joined
Mar 22, 2008
Messages
4,679
Reaction score
3,665
Points
138
Location
Massachusetts
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.

Screenshot at 2024-06-16 11-36-23.png
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...
 
Last edited:

Thunder Chicken

Fine Threads since 2008
Donator
Joined
Mar 22, 2008
Messages
4,679
Reaction score
3,665
Points
138
Location
Massachusetts
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.

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:

Buck Rogers

Major Spacecadet
Joined
Feb 26, 2013
Messages
507
Reaction score
453
Points
63
I 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.
I was thinking about how it would be integrated into other addons

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?
 

Thunder Chicken

Fine Threads since 2008
Donator
Joined
Mar 22, 2008
Messages
4,679
Reaction score
3,665
Points
138
Location
Massachusetts
Officially calling it an add-on:


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.
 
Top