SDK Question Touchdown points definition 2016

[gattispilot]

Syntax error.

Also ALT is no standard parameter of Orbiter.

Syntax error in the code?


Well how do you adjust the ALT then?

 

[Urwumpe]

Well how do you adjust the ALT then?

By the touchdown points.

And yes, syntax error in the code: Your comment removes the last line and does not remove the comma ahead of it.

 

[martins]

Also ALT is no standard parameter of Orbiter.

Actually I think it probably is in Orbiter 2016 (haven't got the sources handy at the moment to check).
The reason is that due to the compressible touchdown points in Orbiter 2016, the touchdown points are no longer sufficient to determine the equilibrium position of an idle (landed) vessel. Instead, Orbiter now uses the ALT and AROT entries to determine those parameters.

The alternative would be to start the scenario with each vessel active, allowing it time to settle in its equilibrium state before switching it back to idle. But that has its own problems.

  ALT -60.000
  AROT -28.841 8.183 95.517

So where are these values coming from, and how do you know that they don't reflect correctly what you see in the simulation?

 

[Urwumpe]

Instead, Orbiter now uses the ALT and AROT entries to determine those parameters.

Oh ... that's problematic with all those add-ons that use the new API and a ALT parameter, didn't know it yet.

So, the "spring forces" are not saved per vertex?

 

[gattispilot]

So where are these values coming from, and how do you know that they don't reflect correctly what you see in the simulation?

So ALT and AROt are calculed based off touchdown point info?


Don't know. I had another vessel the slstower I added and it was above the surface.

Well I would saw since the y value on the touchdown point is .01 then -60 is wrong.

I will fix that comma and see it is rights the vessel

 

[jedidia]

Just thought I'd throw this in here, in case it got overlooked in the Orbiter2016 thread.
There is an issue with scenario editor placing vessels with compressed touchdown points (usually the front one, at least in my tests) when setting the location. As a result, the vessel is prone to take a hop. I haven't yet quite figured out what influences the magnitude of that hop, probably the stiffness of the attachment point.
The force is released as soon as the first force acts on the vessel. I think this is where GattisPilot's problem with his rover flipping upside down comes from. The issue is barely visible with the DG (it is visible on the moon, but negligible), but I also had an appreciably massive vessel almost flipping itself on its back after placement due to this issue.

 

[martins]

Oh ... that's problematic with all those add-ons that use the new API and a ALT parameter, didn't know it yet.

You mean the "ALT" tag was already used by addons? I didn't consider that possibility. But given that Orbiter's use of "ALT" is quite intuitive (altitude of CoG over surface), would an addon use a different definition? Also, Orbiter makes use of the "ALT" entry only for landed vessels, which is (I assume) exactly where addons would not use it - so maybe they can coexist?

In the worst case, I can change the ALT tag, although that means I'll have to fix every single scenario ...

So, the "spring forces" are not saved per vertex?

Well, the spring parameters are defined for every touchdown point, but the resulting displacement at equilibrium can be quite difficult to compute analytically. I could probably have saved the displacement of every touchdown point in the scenario instead of vessel position (POS, ALT) and orientation (AROT), but ultimately the two are equivalent.

 

[martins]

Just thought I'd throw this in here, in case it got overlooked in the Orbiter2016 thread.
There is an issue with scenario editor placing vessels with compressed touchdown points (usually the front one, at least in my tests) when setting the location. As a result, the vessel is prone to take a hop. I haven't yet quite figured out what influences the magnitude of that hop, probably the stiffness of the attachment point.
The force is released as soon as the first force acts on the vessel. I think this is where GattisPilot's problem with his rover flipping upside down comes from. The issue is barely visible with the DG (it is visible on the moon, but negligible), but I also had an appreciably massive vessel almost flipping itself on its back after placement due to this issue.

Ok, I'll look into that. It may be that the scenario editor does try to predict the compression analytically and gets it wrong.

 

[Urwumpe]

You mean the "ALT" tag was already used by addons? I didn't consider that possibility. But given that Orbiter's use of "ALT" is quite intuitive (altitude of CoG over surface), would an addon use a different definition? Also, Orbiter makes use of the "ALT" entry only for landed vessels, which is (I assume) exactly where addons would not use it - so maybe they can coexist?

I can imagine a few reasons to use ALT as well (Alternative), and I am almost sure that at least one unreleased add-on on my HDD makes use of such a parameter in that sense. Unreleased, its very easy to fix.

But any change in reserved words in the scenario files should maybe be communicated a bit louder, since we have no distinct namespace for orbiter standard parameters and custom add-on specific parameters.

 

[gattispilot]

So is there a way to have the vessel NOT bounce along the terrain? I guess you could make the vessel super heavy but then you would need a larger force to move in

 

[martins]

So is there a way to have the vessel NOT bounce along the terrain? I guess you could make the vessel super heavy but then you would need a larger force to move in

No that's not a good recipe.

Heavier -> requires stiffer suspension -> increases eigenfrequency of the suspension -> less numerically stable.

With a stiffer suspension, a given error in the touchdown point displacement would result in higher forces and a bigger bounce.

What about this for a quick fix:

Instead of creating the vessel as landed on the ground in the scenario editor, create it floating at a small height, let it drop to the ground, and wait until it settles and switches to idle. Then save the scenario. This should write out the correct POS, ALT and AROT values. When you re-load that scenario, the vessel shouldn't bounce on activation.

 

[gattispilot]

No that's not a good recipe.

Heavier -> requires stiffer suspension -> increases eigenfrequency of the suspension -> less numerically stable.

With a stiffer suspension, a given error in the touchdown point displacement would result in higher forces and a bigger bounce.

What about this for a quick fix:

Instead of creating the vessel as landed on the ground in the scenario editor, create it floating at a small height, let it drop to the ground, and wait until it settles and switches to idle. Then save the scenario. This should write out the correct POS, ALT and AROT values. When you re-load that scenario, the vessel shouldn't bounce on activation.

How would you do that. Is there a height setting?
So make the suspension weaker?

What I am trying to do. A have a vessel like a Lunar rover, car and then apply forward thrust and then vessel follows the terrain.

 

[martins]

How would you do that. Is there a height setting?

Yes. In the state vector tab. Do you know how to use the scenario editor?

So make the suspension weaker?

That depends on your rover. A weaker suspension is more compressed at equilibrium, so you need enough ground clearance.

 

[gattispilot]

Yes. In the state vector tab. Do you know how to use the scenario editor?

That depends on your rover. A weaker suspension is more compressed at equilibrium, so you need enough ground clearance.

Ok. I will check it out when I get home.

So what if the dampness was high to keep the vessel from bouncing

 

[martins]

So what if the dampness was high to keep the vessel from bouncing

I would urgently recommend to read up on damped harmonic oscillators http://hyperphysics.phy-astr.gsu.edu/hbase/oscda.html, https://en.wikipedia.org/wiki/Harmonic_oscillator, etc. If you understand the role of the various parameters in the underlying DE, it's easier to predict how changing them affects the behaviour of the system.

 

[gattispilot]

Ok. So it sounds like Critically damped or Over damped. It what I need.

---------- Post added at 03:14 PM ---------- Previous post was at 01:39 PM ----------

cleaned up the code but the vessel is still straight up

static const DWORD ntdvtx = 3;
static TOUCHDOWNVTX tdvtx[3] = {
	{ _V(0, .001, 20), 1e5, 1e2, 0.5, 0.005 },
	{ _V(-15, .001, -20), 1e5, 1e2, 0.5, 0.005 },
	{ _V(15, .001, -20), 1e5, 1e2, 0.5, 0.005 }
	//{ _V(0, 5, 0), 1e5, 1e2, 0.5 }// new point just to make a closed shape (more are not needed as the crawler is unlikely to get upside down)
};

---------- Post added 10-15-16 at 07:11 AM ---------- Previous post was 10-14-16 at 03:14 PM ----------

If I add this vessel it is alt-60. If I exit and copy the alt and Arot from the sc4 version it places it correctly. But if I move it in Scenario editor it places it below and 90 degrees out.

#define STRICT
#define ORBITER_MODULE
#define ENG		1
#define START	2
#include "orbitersdk.h"
#include "SLSCRAWLER.h"
#include "SLSCRAWLERMESH.h"




static const DWORD ntdvtx = 3;
static TOUCHDOWNVTX tdvtx[3] = {
	{ _V(0, .001, 20), 1e6, 1e5, 1.6, 0.1 },
	{ _V(-15, .001, -20), 1e6, 1e5, 3.0, 0.2 },
	{ _V(15, .001, -20), 1e6, 1e5, 3.0, 0.2 }
	//{ _V(0, 5, 0), 1e5, 1e2, 0.5 }// new point just to make a closed shape (more are not needed as the crawler is unlikely to get upside down)
};
//LAND_PT1=(0,-2.866,17)
//LAND_PT2 = (-3.96, -2.866, -4.3)
//LAND_PT3 = (3.96, -2.866, -4.3)
VISHANDLE MainExternalMeshVisual = 0;

void SLSCRAWLER::clbkSetClassCaps(FILEHANDLE cfg) {
	// physical specs
	SetSize(6.08);
	SetEmptyMass(MASS);
	SetCW(0.9, 0.9, 2, 1.4);
	SetWingAspect(0.1);
	SetWingEffectiveness(0.1);
	SetCrossSections(_V(12.16, 15.99, 9.39));
	SetRotDrag(_V(0.1, 0.1, 0.1));
	if (GetFlightModel() >= 1) {
		SetPitchMomentScale(1e-4);
		SetBankMomentScale(1e-4);
	}
	SetPMI(_V(3.75, 3.48, 2.23));
	SetTrimScale(0.05);
	SetCameraOffset(_V(0, .7, 3.121));
	SetTouchdownPoints(tdvtx, ntdvtx);
	

	// visual specs
	iMeshMain = AddMesh("SLSCRAWLER");
	SetMeshVisibilityMode(iMeshMain, MESHVIS_ALWAYS);



}

---------- Post added at 08:15 AM ---------- Previous post was at 07:11 AM ----------

This is so weird. Another vessel is the same way. 90 degrees out and below the surface.

Not sure if I am missing some bit of code

 

[DaveS]

Make sure that the mesh is rotated -90°s around the X axis before exporting it to msh.

 

[gattispilot]

Thanks. The mesh is correct in both. Z axis runs fore and aft and y up/down. x left/right.
But when i placed a DG there it is above and correct attitude

 

[DaveS]

Thanks. The mesh is correct in both. Z axis runs fore and aft and y up/down. x left/right.
But when i placed a DG there it is above and correct attitude

It isn't correct. Your screenshot shows the mesh being vertical in the top view when it should be horizontal. Below is a screenshot showing the correct orientation:

 

[gattispilot]

Here is the dg, shuttle A and my crawler. All oriented the same.