SDK Question Touchdown points definition 2016

[martins]

I'm not sure I follow... I need the distances proportional to each other. Is a+b not proportional to sqrt(a^2 + b^2)?

Well, no. Consider

x1 = 2, z1 = 0
x2 = 1, z2 = 1

According to your code they have the same proportional distance, but in fact it is 2 and sqrt(2), respectively.

 

[jedidia]

:facepalm:

Right, off I go to fix some code.
Thanks a lot!

 

[gattispilot]

It looks like your initial touchdown points are in array, right?
Can you post your code for that?

 

[jedidia]

It's just a simple array of TOUCHDOWNVTX, like you'd pass to orbiter. I just run it through that function before that to set the stiffness values. But really, if your points are static and you know where they are at compile time, it's much more sensible to calculate this stuff more thouroughly by hand. This is really just a hack to get not-completely-wrong values for touchdown points of which I don't know where they will be when the simulation runs.

 

[gattispilot]

oh. I think one thing that may/maynot be an issue is the touchdown points and docking with bases/vessels landed.

In 2010 is was easy except you couldn't dock with a landed vessel. But the ground was level.

Now you may have a base placed on a slope so the docking vessel may need to adjust to dock?

For me I got the vessels to drive on the ground but the surface mesh stills eats through. I guess it will till a way to raise the vessel based off surface height at each wheel is figured out.

 

[martins]

One more point on the code:

When you detect a touchdown point to coincide with the CoG projection, you set its load arbitrarily to 1. Instead, I would simply throw an exception and abort in this case, since with 3 touchdown points you can't get a stable configuration when one point is below the CoG.

Or if you do want to allow it, you would also have to make sure that the loads of the two other points are set to 0.

 

[jedidia]

When you detect a touchdown point to coincide with the CoG projection, you set its load arbitrarily to 1. Instead, I would simply throw an exception and abort in this case, since with 3 touchdown points you can't get a stable configuration when one point is below the CoG.

Or if you do want to allow it, you would also have to make sure that the loads of the twol other points are set to 0.

Good point!

oh. I think one thing that may/maynot be an issue is the touchdown points and docking with bases/vessels landed.

I lost you there, or you lost me... I don't understand how you made a link from my algorithm to vessels being docked in landed state. They have nothing at all to do with each other.

 

[gattispilot]

Well if a base vessel is landed it might be tilted based on terrain. To properly dock you would have to match the angle.

I would think there would be a way to set the TD so the mesh/vessel are level

 

[jedidia]

I would think there would be a way to set the TD so the mesh/vessel are level

There would be, but I don't do that. The user is responsible for choosing an adequately flat place to build his base

 

[gattispilot]

On this I thought about making a Ummu vessel. Use the Ummu as a mesh and low amount of thrust so the Ummu could "walk". But I never could have a good touchdown point equation or code so the Ummu could climb a hill.

I think once it was done then maybe someone could make Ummu for 2016?

 

[jedidia]

I think once it was done then maybe someone could make Ummu for 2016?

We'll have to wait for Dan, and he'll probably wait for 2016P1 to avoid the danger of having to do it over again. As far as I know Dan's work strategy, he plans ahead and sets aside a considerable block of time for add-on development, but only once a year or so. So it could be a while until he starts working on it, but once he starts he'll be moving fast.

 

[vchamp]

Is it possible to make a vessel not change it's elevation depending on how strong is the gravity of the body where it is landed? For example, on Earth bottom of my vessel is below the surface, on Mars - slightly above, on Moon - higher than on Mars. I want it to have the same elevation on all bodies.

I also don't understand why my vessel is elevated on Mars and Moon even though I defined touchdown points with the vertical coordinate equal to the lowest point of my mesh.

 

[GLS]

Is it possible to make a vessel not change it's elevation depending on how strong is the gravity of the body where it is landed? For example, on Earth bottom of my vessel is below the surface, on Mars - slightly above, on Moon - higher than on Mars. I want it to have the same elevation on all bodies.

I also don't understand why my vessel is elevated on Mars and Moon even though I defined touchdown points with the vertical coordinate equal to the lowest point of my mesh.

The touchdown points in Orbiter 2016 are like this:

So they are not like the legs of a chair, but actually like real suspension, with some travel. For the same touchdown point parameters, a heavier vehicle will sink more than a lighter one. Your vehicle will be lighter on the Moon than on Earth, thus it will sink less on the Moon.
If the vertical movement of the gear was animated, it would look so much more natural... I haven't looked at this in detail, so I can't say if it is easy or possible.

A maybe-not-so-quick and dirty fix to your request would be setting touchdown parameters based on the mass of the planet you are landing on.

 

[jedidia]

I haven't looked at this in detail, so I can't say if it is easy or possible.

Difficult. On a flat surface it kinda works since you can work with the altitude of the vessel to work with your animations, but that only applies if your craft lands on all points at the same time.
There is currently no way to get the compression of touchdown points, so animating them individually to look realistic on an uneven surface is quite a task, requiring you to figure out the exact world coordinates of your touchdown points and then finding out terrain altitude at those points. I think I made a request for a method to query current compression a while back.

In any case, @Vchamp, the only thing you really need is to get your suspension parameters straight. Preferably for the highest gravity environment you expect to land in, the rest will work fine with that.

 

[vchamp]

The touchdown points in Orbiter 2016 are like this

Now I understand better what is stiffness and damping in touchdown points spec, thanks to this graphic. Still this part of Orbiter SDK is confusing, stiffness and damping can be only big numbers in a narrow range, otherwise it won't work. I wish SDK was more dev friendly here and it was easier to define touchdown points. Some good tutorial about it would be handy, seeing how important it is, almost every creator of a vessel will face the need to define these params.

What makes it even more confusing is that suspension works not only by compression but expansion too, it seems. When we define coordinates of TDP it is not the lowest possible point of ground contact, it may be lower on low-gravity bodies and the mesh will be elevated above ground. It is going to be a hard task to make a workaround that changes the params of TDP depending on the current gravity.

In any case, @Vchamp, the only thing you really need is to get your suspension parameters straight. Preferably for the highest gravity environment you expect to land in, the rest will work fine with that.

I don't understand what do you mean by "straight".
If I define parameters so that the mesh touches the ground where it should in the highest gravity, then in lower gravity it will be elevated. Increasing stiffness makes the vessel jump into void.

 

[4throck]

You will always have "sinking" vessels because the graphics don't follow the terrain exactly.
And you will get different results between the inline graphics and the external client.
So don't waste time trying to fix that, it's just the way Orbiter works.
Go with the best compromise for your vessel.

If you like "cargo cult" programming, here's something that works reasonably well:

// point, stiffness, dampening, isotropic/lateral friction coefficient, longitudinal friction coefficient (only used for first 3 points)
const double totalweight=MASS+FUEL+RCSFUEL;
const double xtx_target=-0.1;
const double xtst=(-1)*(totalweight*9.80655)/(3*xtx_target);
const double xtda=0.9*(2*sqrt(totalweight*xtst));

static const DWORD ntdvtx_geardown = 4;
static TOUCHDOWNVTX tdvtx_geardown[ntdvtx_geardown] = {
	{_V( -4,-1,-4), xtst,  xtda, 30.0,30},
	{_V(4,-1,-4),  xtst,  xtda,  30.0,30},
	{_V(4,-1,4), xtst,  xtda, 30.0,30},
	{_V( -4,-1,4), xtst,  xtda,  30.0}
};

 

[jedidia]

If I define parameters so that the mesh touches the ground where it should in the highest gravity, then in lower gravity it will be elevated.

Ah. You mean the gear will sink into the ground (somehow I was of the impression that you hull's sinking into the ground, though in hindsight it's pretty obvious that you were talking about the landing gear). Yes, that's nearly unavoidable, at least on uneven surfaces. On an even surface, the animation shouldn't be too tough to synch with the vessel altitude.

 

[fred18]

On an even surface, the animation shouldn't be too tough to synch with the vessel altitude.

Altitude and attitude: it s not given that the vessel will land flat i think

 

[Majid]

If you like "cargo cult" programming, here's something that works reasonably well:

// point, stiffness, dampening, isotropic/lateral friction coefficient, longitudinal friction coefficient (only used for first 3 points)
const double totalweight=GetMass();
const double xtx_target=-0.1;
const double xtst=(-1)*(totalweight*9.80655)/(3*xtx_target);
const double xtda=0.9*(2*sqrt(totalweight*xtst));

static const DWORD ntdvtx_geardown = 4;
static TOUCHDOWNVTX tdvtx_geardown[ntdvtx_geardown] = {
	{_V( -4,-1,-4), xtst,  xtda, 30.0,30},
	{_V(4,-1,-4),  xtst,  xtda,  30.0,30},
	{_V(4,-1,4), xtst,  xtda, 30.0,30},
	{_V( -4,-1,4), xtst,  xtda,  30.0}
};

This code results in the HCLV laying on its side like so:

I have tried everything and best I got is this:

static const DWORD ntdvtx_geardown = 3;
			static TOUCHDOWNVTX tdvtx_geardown[ntdvtx_geardown] = {
				{ _V(0, -30, 0), 1e5, 1e5, 2, 2 },
				{ _V(-2.5,-30,-1), 1e5, 1e5, 2, 2 },
				{ _V(2.5,-30,-1), 1e5, 1e5, 2, 2 }
			};

No matter what I try, I cannot get it to point towards the sky. I will hail the probe many times on behalf of anyone that helps.

 

[fred18]

This code results in the HCLV laying on its side like so:

I have tried everything and best I got is this:

static const DWORD ntdvtx_geardown = 3;
			static TOUCHDOWNVTX tdvtx_geardown[ntdvtx_geardown] = {
				{ _V(0, -30, 0), 1e5, 1e5, 2, 2 },
				{ _V(-2.5,-30,-1), 1e5, 1e5, 2, 2 },
				{ _V(2.5,-30,-1), 1e5, 1e5, 2, 2 }
			};

No matter what I try, I cannot get it to point towards the sky. I will hail the probe many times on behalf of anyone that helps.

From a very quick overview it seems to me that you have your coordinates wrong. In order to have a tail sitter they should surely have the z component constant (usually negative).

For general purpose I usually use 3 points at 120 degree from each other with z constant.

I think they should look like
V1= 0 , +y , -z
V2 = +x , -y , -z
V3 = -x , -y, -z

I d use trigonometry and say
Radius =5
Z_offset =-30
V1 = 0, radius , z_offset
V2 = radius*sin(120), radius*cos(120), z_offset
V3 = radius * sin(240), radius *cos(240), z_offset

Pseudo code written from mobile phone...