SSU Crawler Transporter development

[Urwumpe]

But we do have the not so small issue that it is broken in Orbiter 2016 which pretty much renders the Crawler useless. So couldn't we use this as an opportunity to at least test it (the AddForce method)?

Sure. But I doubt it will be overly stable. Sadly I see little other options right now in 2016.

 

[gattispilot]

Where is the code for the crawler. I want to see if I can compile it and maybe fix the 2016 issue

 

[DaveS]

Where is the code for the crawler. I want to see if I can compile it and maybe fix the 2016 issue

All the SSU source code is in our SVN repository on SourceForge.net. I have written a tutorial on how set up and up to date SSU installation here: http://www.orbiter-forum.com/showthread.php?t=30336

 

[Urwumpe]

In "Orbitersdk/Space Shuttle Ultra/Crawler/"

 

[gattispilot]

Thanks. But I didn't see it that folder in this zip:
https://sourceforge.net/projects/shuttleultra/

 

[DaveS]

Thanks. But I didn't see it that folder in this zip:
https://sourceforge.net/projects/shuttleultra/

That's because that's the actual release archive. The sources are separate from the release files.

 

[gattispilot]

ok That makes sense but isn't that the latest release? So where would the code be if not in the latest release?

 

[DaveS]

ok That makes sense but isn't that the latest release? So where would the code be if not in the latest release?

Here: http://www.orbiter-forum.com/showthread.php?p=545270&postcount=262

 

[gattispilot]

Thanks. I got it. I was looking at the change touchdown points. But not sure if that could be applied to another vessel.

	// check distance from pads; adjust touchdown points to simulate going up ramp
	for(unsigned int i=0; i<vhLC39.size(); i++) {
		//VESSEL* pV=oapiGetVesselInterface(vhLC39[i]);

		VECTOR3 rpos = CalcRelSurfPos(vhLC39[i], vs);

		if(UpdateTouchdownPoints(rpos)) break;
	}

	// jack crawler
	if(!Eq(jackHeight, JACKING_HEIGHTS[targetJackHeightIndex], 0.001)) {
		if(jackHeight < JACKING_HEIGHTS[targetJackHeightIndex])
			jackHeight=min(jackHeight+0.0025*simdt, JACKING_HEIGHTS[targetJackHeightIndex]);
		else
			jackHeight=max(jackHeight-0.0025*simdt, JACKING_HEIGHTS[targetJackHeightIndex]);
		UpdateTouchdownPoints();
	}
	// jacking height may change when going up ramp, so always update height
	double avgHeight = jackHeight + (curFrontHeight-curBackHeight)/2.0;
	port_JackHeight.SetLine(static_cast<float>(avgHeight/JACKING_MAX_HEIGHT));

 

[DaveS]

New ticket, https://sourceforge.net/p/shuttleultra/tickets/149/

 

[DaveS]

I have the fixed the CTD/Freeze issue in D3D9Client RC-1, but there's new issue: The Crawler spins at a rapid rate when launching the Crawler test scenario.

 

[DaveS]

I wonder if the spin issue is due to improperly calculated touchdown point stiffness? Like everything in Orbiter, they're frame rate dependent and D3D9Client yields much higher frame rates which could explain why it doesn't show in the inline client.

 

[Urwumpe]

I wonder if the spin issue is due to improperly calculated touchdown point stiffness? Like everything in Orbiter, they're frame rate dependent and D3D9Client yields much higher frame rates which could explain why it doesn't show in the inline client.

Could be, if the initial state and the equilibrium is too far away.

 

[DaveS]

Could be, if the initial state and the equilibrium is too far away.

After a few tests, I beginning to think that our current propulsion code which is based on teleportation is completely broken in the 2016 edition. I ran a few tests by letting the crawler fall down and it never settled, just kept on going through the terrain/ground forever. I even modified the touchdown points to have a more sensible orientation (all of them in a single flat plane). I would not be surprised actually as the motion code dates back to the 2005 edition of Orbiter. I really think it's time for it go.

 

[Urwumpe]

After a few tests, I beginning to think that our current propulsion code which is based on teleportation is completely broken in the 2016 edition. I ran a few tests by letting the crawler fall down and it never settled, just kept on going through the terrain/ground forever. I even modified the touchdown points to have a more sensible orientation (all of them in a single flat plane). I would not be surprised actually as the motion code dates back to the 2005 edition of Orbiter. I really think it's time for it go.

I think you are right there, it can't work well with the new terrain code anyway.

But I have no good idea yet how to replace it by something better. Maybe AddForce for the 4 track units. But I don't know how much force and friction we need for getting a good motion. I don't even want to say realistic there.

 

[DaveS]

I think you are right there, it can't work well with the new terrain code anyway.

I have tried out the crawler implemented by fred18 in his multistage2015 and it is very solid. Maybe we could ask for his permission to use his code in a truly generic Crawler? Something like a Crawler Transporter Ultra (CTU) that is completely LV agnostic.

 

[Urwumpe]

I have tried out the crawler implemented by fred18 in his multistage2015 and it is very solid. Maybe we could ask for his permission to use his code in a truly generic Crawler? Something like a Crawler Transporter Ultra (CTU) that is completely LV agnostic.

I think that is the goal there. The more components of SSU can be used outside SSU, the less bugs we will have in them, coarsely said. Same with building new spacecraft on the code of SSU. Stepping out of the Space Shuttle context there helps us getting better code (because different use cases are possible that we can't test right now)

 

[fred18]

Surely you have my permission. Be aware that for the orbiter2016 official version I had to implement a hack to make it work because defstateex was not saving the arot parameter. Now martin has solved it in the svn version of orbiter so the hack is no longer needed. It's anyway easy to understand in the code, and i'm always available if i can be of any assistance, just let me know

 

[jarmonik]

I have the fixed the CTD/Freeze issue in D3D9Client RC-1, but there's new issue: The Crawler spins at a rapid rate when launching the Crawler test scenario.

I tried the "CT-1 road test" scenario and the crawler seems to rotate very fast with the D3D7 inline engine too. Scenario doesn't start with D3D9. (Latest Orbiter Beta)

I have seen that kind of behavior before and it was animation initialization problem. Based on how it looks, feels like an animation matrix that rotates the entire crawler by 90 degs is applied every frame.

 

[DaveS]

I tried the "CT-1 road test" scenario and the crawler seems to rotate very fast with the D3D7 inline engine too. Scenario doesn't start with D3D9. (Latest Orbiter Beta)

I have seen that kind of behavior before and it was animation initialization problem. Based on how it looks, feels like an animation matrix that rotates the entire crawler by 90 degs is applied every frame.

Interesting. Which SSU revision are you using that are causing the the no start with D3D9Client? I did check in a fix for that a few days ago which landed on revision 2534.