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

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:
 
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.
 
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:
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:
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?
 
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.
 
If set_touchdownpoints accepts all of the contact points, that means the ntdvtx parameter isn't needed, at least in the Lua version. We really need to get the documentation for scripting sorted out as it is maddening trying to guess Lua methods based on the API reference, and trying to infer it from the Orbiter code base is challenging as the Atlantis and DG are much more complicated vessels. I'm thinking if I can get this to work I might write up how I made this airplane. That might be helpful for other confused souls who just want to make something simple. I'd help with the Orbiter documentation if there is something I can contribute.
I think it would be very useful.
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.
Sadly, most of the formulas in the message above (and within the thread at all) aren't displayed correctly (maybe a problem with tags), but nevertheless I find it useful for the touchdown point parameters calculation (or at least evaluation). As far as I understood it's not yet known exactly what a model (equations) of the touchdown points is used by Orbiter, but your thoughts describe the behavior well, isn't it?

Currently I'm trying to add three touchdown points for an airship (on Lua) to make taxiing and landing more hard and stable (like the DG on Lua). Experimentally I found some stiffness and damping values, but I'm not satisfied with them. I'm using a very simple (without airfoils, but I think it's not a problem) Lua script, and maybe the problem is related to small mass and simultaneously big size (and touchdown point coordinates), and therefore the correct touchdown paramerets can't be found for this case. Can I post my Lua code here? Maybe anyone could recommend something.
 
I think it would be very useful.

Sadly, most of the formulas in the message above (and within the thread at all) aren't displayed correctly (maybe a problem with tags), but nevertheless I find it useful for the touchdown point parameters calculation (or at least evaluation).

The forum did support Latex and those equations did look correct when I initially posted them. I am not sure if that is a forum bug or support for LaTex was dropped from BB.

misha.physics said:
As far as I understood it's not yet known exactly what a model (equations) of the touchdown points is used by Orbiter, but your thoughts describe the behavior well, isn't it?

I haven't traced out the code in how the touchdown point model is implemented in Orbiter, but I'm 100% certain that it's a spring-damper model as I described. I wouldn't be able to set touchdown points so accurately if it was something more obscure.

Currently I'm trying to add three touchdown points for an airship (on Lua) to make taxiing and landing more hard and stable (like the DG on Lua). Experimentally I found some stiffness and damping values, but I'm not satisfied with them. I'm using a very simple (without airfoils, but I think it's not a problem) Lua script, and maybe the problem is related to small mass and simultaneously big size (and touchdown point coordinates), and therefore the correct touchdown paramerets can't be found for this case. Can I post my Lua code here? Maybe anyone could recommend something.

My other thread on touchdown points might be a better place for that discussion:


Certainly, post your code there and I'll see if I can help. You have to specify the touchdown points and their stiffness and damping properties. The damping property in particular can easily cause stability problems as it calculates forces based on the vessel velocity. If you hit very hard and the damping is set too high you can can a non-physical force that will punt your vessel into solar orbit.
 
The Lua doc is in Orbitersdk/doc/orbiter_lua.chm, it's not much but still better than nothing. Don't hesitate to comment on it if you find some issues.
Thanks, I just found it and took a look at it. I'l keep in mind I can refer to the document you mentioned above. I just never have a deal with Lua and Orbiter code at all, and I'm not a programmer, so I'm at the very beginning of this subject.

Here:
I think it would be very useful.
I just meant that some example of the simple vessel on Lua would be useful. I know there're some default, but more complicated vessel on Lua like DG, although the ScriptPB is pretty simple, and I took its code like an example, but nevertheless I think some additional explanations regarding choosing some paramteters will be very welcome (maybe not only for me), but of course, I don't mean that such the example must be created, I just wanted to support this idea (maybe it will be implemented someday):
I'm thinking if I can get this to work I might write up how I made this airplane.
 
Updated to version 4:


Some major improvements to this add-on.
  • Implemented Otto cycle model for reciprocating engine performance. Matches power and fuel consumption of an A-65 engine very well. Inputs are engine displacement volume (in cubic meters) and compression ratio.
  • Implemented a momentum disk model of the propeller which translates the calculated engine power to thrust. A root finding routine solves for the air velocity exiting the propeller at a given power, which provides the thrust applied to the vessel. Delivers very appropriate levels of thrust at all flight speeds and power levels.
  • A dihedral model that provides a righting moment to level the aircraft.
  • Sundry improvements to aerodynamic model.
 
So I checked my VWThing against Orbiter 2024 and found that it works quite well, but there does seem to be a bug with the visuals. When I apply the brakes with the spacebar, the car body visuals as seen from the cockpit disappear, and they reappear when I release the brakes. I have no idea why this is occurring.

I don't know if this is a bug in Orbiter 2024 or a bug in my script that is coming to light in Orbiter 2024. If someone can confirm that they see this behavior in their installs I'd appreciate it.

I haven't seen that problem yet. Tested on OpenOrbiter 2024 on Linux under WINE.
 
I've been trying to import my J-3 mesh into Blender, but it fails for some unknown reason. It loads into Orbiter fine. Does anyone see a problem with the attached?
 

Attachments

Make sure your mesh file is in a 'meshes' folder under Orbiter, and the textures are in 'Textures'. The importer makes these assumptions.

1739635819477.png
 

Attachments

  • 1739635645059.png
    1739635645059.png
    171 KB · Views: 3
I just did the above and it's loaded.
 
I keep getting this when trying to import the J-3 mesh in my Orbiter 2024 where the textures and meshes are in the correct directories:

Screenshot at 2025-02-15 13-12-28.png
I do have the Orbiter mesh extension and am attempting to import an Orbiter mesh FYI.
 
I'm not sure if this will help, but just to clarify: try to put the J-3 mesh file into Orbiter-2024/Meshes, and put all J-3 textures into Orbiter-2024/Textures. Not using any sub-directories for the mesh and textures.
 
I'm not sure if this will help, but just to clarify: try to put the J-3 mesh file into Orbiter-2024/Meshes, and put all J-3 textures into Orbiter-2024/Textures. Not using any sub-directories for the mesh and textures.
This does help. I'll try this.
 
I just made a simple directory structure with Orbiter/Meshes and Orbiter/Textures and put the J-3 mesh and textures in the respective folders with no subfolders, just to keep my main Orbiter install organized. Blender is importing the mesh without errors now:

Screenshot at 2025-02-15 13-45-57.png

But no textures are showing? The textures are in Orbiter/Textures, no subfolder, and I edited the texture paths in the mesh file to eliminate the subfolder. No luck.
 
Back
Top