SDK Question Touchdown points definition 2016

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

Thank you!! :hailprobe: I used z-offset = -78

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


No, but it is something you can reasonably assume people will aspire to do, so you'll have at least a decent and relatively quick solution for the nominal case.
As I said, taking attitude and uneven surfaces into account makes the thing ridiculously complicated, up to the point of you essentially implementing your own collision detection. It's just not worth it.
 
Happy to see that the "copy-paste" example was useful.
I did some testing with 3 vs 4 points and found the 4 points over a larger area are more stable.
A smaller area will be more disturbed by local topography.
 
Not sure why my lander will not stay landed.

Code:
const double  LEM_DescentMASS = 626;				// Decent Stage empty mass [kg]
const double  LEM_DescentFUEL = 845;				// Decent Stage fuel capacity [kg]

Code:
const double pesototal=LEM_DescentMASS+LEM_DescentFUEL;
const double xtx_target=-0.1;
const double xtst=(-1)*(pesototal*9.80655)/(3*xtx_target);
const double xtda=0.9*(2*sqrt(pesototal*xtst));

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

Code:
SetTouchdownPoints (tdvtx_geardown, ntdvtx_geardown);
 
Not sure why my lander will not stay landed.

What is the symptom? Does it hop after landing, or does it fall over?
From the code I see it is a forward looking lander (like the Delta glider).

You could include one or more points to the top of the vessel (+y), as the new touchdown points define an enclosed volume of the vessel, not only a contact plane.

Things I try, when landed vessels behave strange:
- Reverse the circumferential direction of the touchdown points.
- Increase the spring stiffness and damping to very high numbers, making actually stiff supports, to avoid any unwanted bouncing. Then by trial and error reduce these factors until the behaviour is acceptable.
 
So what happens is I place the vessel where I want it and it pops into space.
Landed and then exit and reload and is now orbiting
 
Maybe it would help if you do not place it on the ground initially, but a meter above, then let it drop and settle down by itself?

Another try: Make one touchdown point shorter than the other 3.
 
Weird I drop from 1 meter and it landed good. Exit and reloaded and was good also.:)
 
Huh... I thought that compression of the touchdown points would be reflected in their position, but it isn't. How would I best go about hooking up gear compression to an animation?

The only way I can see currently is to calculate the altitude above ground of every individual touchdown point, but that seems excessive, seeing as orbiter doubtlessly does the same already. Is there any way to querry the altitude above/below ground or current compression of a given touchdown point?

I'm afraid this information is not (yet) exposed to the API. I'll see if this can be incorporated in an update. For now you are on your own, as far as computing the compression is concerned.

This would be a nice thing to have.
 
That's another topic on which it would be cool to have a "O2016 Touchdownpoints for Dummies" little guide that sums things in a convenient and ready-to-use way, because this remains an headbanging subject for many people (including myself). ?
 
That's another topic on which it would be cool to have a "O2016 Touchdownpoints for Dummies" little guide that sums things in a convenient and ready-to-use way
The problem is, I'm not sure if dummies are at all able to handle the 2016 touchdown points (or, rather, convex hull definition, because that's really what this is!), they might be too complex for that, and there's a thousand gotchas when working with them...
 
The problem is, I'm not sure if dummies are at all able to handle the 2016 touchdown points (or, rather, convex hull definition, because that's really what this is!), they might be too complex for that, and there's a thousand gotchas when working with them...

I understand that but I have the feeling it is one of the main reasons of O2016 relative popularity. We have to do something about it. Maybe a plugin module that would handle ground collisions and sort of simplify them (for the user) ? A "Touchdownpoints Client" ?
 
One could write a library with a generic abstraction to handle most of the hassle... but it takes a lot more math than was bestowed on me, I'm afraid. Also, it could only be used by people that write theirown C++ modules, unless something like spacecraft4 incorporated it.
 
That would already help a huge lot, and there's no reason it couldn't be incorporated in spacecraft4.

Now, as you say, we need a good coder that is also a math expert...
 
OK from my experiments a simple way to do it with "traditional" expendable tailsitters would be make some kind of "Universal Launchpad", stable and heavy enough so that docking a sounding rocket or a fully-fueled Saturn V wouldn't change anything. We could add built-in features, like auto-undocking (release clamps) when the docked stage thrust is 100%, or after a delay (part of a countdown sequence....)
 
Back
Top