SSU Development Thread (2.0 to 3.0)

[Urwumpe]

Due to the problem of using libUltra explained by SiameseCat I thought that we were stuck with C++. In that case between Qt and WxWdigets it will be Qt IMHO. However, it's true that doing communication between applications may be easier in other languages.

---------- Post added at 11:44 ---------- Previous post was at 11:41 ----------

Also, on the other side you have the SSU lib code which is C++ too. So if you have to communicate with a C++ compiled app (SSU) maybe it makes sense to use C++ for the client too (SSUToolbox/MCC).

I don't agree on having to use libUltra. It is a nice to have, but the amount of really useful code for a mission control application is tiny there. It is not that much, as that we will really have any benefits from depending on it.

What matters is not the implementation, but the algorithm. Also, I see libUltra as something for real-time simulation, which will always be designed for faster calculations in Orbiter than perfect accuracy or simple to understand.

We can't make one C++ library that is perfect for all applications, having a Java or C# library that has some intersections with libUltra, but then having spaceflight related functions for visualization and not all the Orbiter-specific stuff would be smarter.

I feel like you oversophisticate things - and that I get this feeling should be a terrible warning sign, because oversophisticating things is usually my job here.

Also: We should use the toolbox and the mission control application as primary research driver to get a better working Mission file format. What we currently have was a first quick shot at it and I would like to keep the next iteration close to it, but as you can easily see, it is extremely limited and not even slightly suitable for the task. We should define a better format that can be used by such an external application without too many considerations of how this will work with the SSU vessel module. Otherwise, we are already thinking about the problems we will have in 10 years, and not about the problems that are directly in front of us.

I think, I should maybe make the JavaFX prototype a project independent of SSU and for all Orbiter or non-Orbiter projects and leave you some room here to do yours. Just as some kind of comparable project.

 

[SiameseCat]

I don't agree on having to use libUltra. It is a nice to have, but the amount of really useful code for a mission control application is tiny there. It is not that much, as that we will really have any benefits from depending on it.

I think libUltra will be quite useful for the orbital mechanics stuff, which will be a major part of SSUToolbox/MCC.

We can certainly rewrite the relevant code in C# or Java if we need to. But I don't really think there's a big advantage in using C#/Java instead of C++. As far as the UI goes, I'm not sure there's a big difference between C++ and C#/Java (Goth might now more about this than I do, my UI experience is mostly with C#). I don't have any experience with sending/receiving data over a network connection, but we'll probably have to do this in C++ anyways on the Orbiter side.

 

[Urwumpe]

I think libUltra will be quite useful for the orbital mechanics stuff, which will be a major part of SSUToolbox/MCC.

Will be - right now it isn't.

Also, I doubt that it makes sense to use the same algorithms in a vessel as we use in mission control/Toolbox.

Also, the communication with this mission control could be implemented as in multiple layers, with the actual network interface being implemented in a DLL, which could be written in C# or C++ - without being integrated part of SSU.

 

[Goth]

As far as the UI goes, I'm not sure there's a big difference between C++ and C#/Java

Languages like C# are in theory more easy to do GUI with, but in practice Qt for example is very easy so this is not a problem.

I don't have any experience with sending/receiving data over a network connection, but we'll probably have to do this in C++ anyways on the Orbiter side.

That was exactly my point.

---------- Post added at 21:32 ---------- Previous post was at 21:29 ----------

multiple layers

Overcomplicating things. (joke)

 

[Urwumpe]

Overcomplicating things. (joke)

Would have the advantage, that the network interface is not limited to SSU or even limited to a single vessel - multiple vessels could share one interface. And it would be possible to replace parts, without being forced to recompile everything.

Nothing beats a good network stack.

 

[SiameseCat]

Will be - right now it isn't.

Not sure what you mean by that. libUltra already has some orbital mechanics code, so we can start using libUltra stuff in SSUToolbox/MCC without any changes to libUltra.

Also, I doubt that it makes sense to use the same algorithms in a vessel as we use in mission control/Toolbox.

In general, I don't see any reason not to share algorithms. A lot of tasks (rendezvous burn targeting, state vector propagation, etc.) have to be performed by both SSUToolbox/MCC and SSU.

Also, the communication with this mission control could be implemented as in multiple layers, with the actual network interface being implemented in a DLL, which could be written in C# or C++ - without being integrated part of SSU.

The impression I have is that calling C# DLLs from C++ is a pain. Unless there are serious problems with writing network code in C++, I think we should stick to C++ here.

 

[Urwumpe]

Not sure what you mean by that. libUltra already has some orbital mechanics code, so we can start using libUltra stuff in SSUToolbox/MCC without any changes to libUltra.

That there isn't much of it yet. I would even go so far to estimate, that 99% of the functions that you need are still missing.

Well, anyway, this isn't my decision here.

 

[Face]

The impression I have is that calling C# DLLs from C++ is a pain.

Considering that in the current episode (creating a very simple GUI dialog) C# beat the 2 C++ alternatives in terms of functionality, I think this is a bit surprising. A newbie (by his own words) picked it up quickly and integrated it into a C++ application (Orbiter) with only little "calling" overhead.

All the while the other alternatives don't/can't do the same, although being written in the very same language, without the benefits of managed environment. If anything, I'd get the impression from this that C++ GUI frameworks are a pain to call from C++...

 

[Urwumpe]

Considering that in the current episode (creating a very simple GUI dialog) C# beat the 2 C++ alternatives in terms of functionality, I think this is a bit surprising. A newbie (by his own words) picked it up quickly and integrated it into a C++ application (Orbiter) with only little "calling" overhead.

I have the same impression, especially since even the very simple network interface of Qt is still a lot more effort to implement and maintain, than the .NET or Java alternatives.

All the while the other alternatives don't/can't do the same, although being written in the very same language, without the benefits of managed environment. If anything, I'd get the impression from this that C++ GUI frameworks are a pain to call from C++...

Yes, sort of. Qt is the most comfortable there, but still, you can't compare Qt to XAML or JavaFX, its a completely different universe.

 

[SiameseCat]

Considering that in the current episode (creating a very simple GUI dialog) C# beat the 2 C++ alternatives in terms of functionality, I think this is a bit surprising. A newbie (by his own words) picked it up quickly and integrated it into a C++ application (Orbiter) with only little "calling" overhead.

All the while the other alternatives don't/can't do the same, although being written in the very same language, without the benefits of managed environment. If anything, I'd get the impression from this that C++ GUI frameworks are a pain to call from C++...

You're right, if you use managed C++, calling C# code is easy. I was thinking in terms of calling C# from unmanaged code. I'm a little bit concerned about adding managed code to a large project like SSU which currently uses only unmanaged code, although there shouldn't be any problems.

---------- Post added at 10:32 PM ---------- Previous post was at 10:30 PM ----------

I have the same impression, especially since even the very simple network interface of Qt is still a lot more effort to implement and maintain, than the .NET or Java alternatives.



Yes, sort of. Qt is the most comfortable there, but still, you can't compare Qt to XAML or JavaFX, its a completely different universe.

Can you explain what the difference is? I haven't used XAML or JavaFX, but the Qt code looks fairly similar to .NET WinForms.

 

[Face]

You're right, if you use managed C++, calling C# code is easy. I was thinking in terms of calling C# from unmanaged code. I'm a little bit concerned about adding managed code to a large project like SSU which currently uses only unmanaged code, although there shouldn't be any problems.

But the example project Goth made is unmanaged C++ code calling managed .NET code (it doesn't matter if it is managed C++ code or managed C# code, both get compiled to .NET, anyway). That's what a mixed-mode assembly is for: it houses both unmanaged and managed code. This is also precisely what makes it so easy to create the calls.

I think you confused the demonstration of an advanced flow in Goth's example (unmanaged C++ Orbiter code calls managed .NET classes inside mixed-mode MCC DLL, which in turn late-binds and demand-loads a managed .NET application to integrate and show the dialogs of it inside Orbiter) with a strict requirement to do it so. He could also have early-bound any .NET DLL and used its types right within the managed C++ classes in the MCC DLL, or simply implemented all of the WinForms code within it.

The way he is doing it now just demonstrates the unmatched ability to create a stand-alone application that can be snapped-in into Orbiter as well. Whether or not the data-link is then done via sockets to achieve a stand-alone connection to Orbiter is an application aspect and has nothing to do with the framework choice.

I can understand your concern about the managed code in the unmanaged project, though. However, this is only because of the advanced requirement of having the .NET runtime installed, something you can't easily bundle in an add-on distribution. If other approaches (besides the obvious and cumbersome direct WinAPI tinkering, of course) allow for a better deployment story, that is certainly a plus. Knowing how .NET is ubiquitous in modern Windows environments, I just think it is a weak plus.

You will find feature-rich .NET DLLs to be very small, simply because of the huge class library already inside the .NET framework. This could also count as a deployment plus on the .NET side.

But anyway, I think the simple truth is that the only willing contributor for this application is Goth ATM. He is also happier with the Qt route, and less experienced in C# AFAIK. That would already make the decision IMHO. If anybody wants to go the Java or .NET route nevertheless... hey, it is open-source, nobody is excluded, right?

 

[DaveS]

I'm currently working on the Centaur stuff, and I have come across a launch anomaly. It is that ascent events, especially second stage events, occur too early. I have logged the events to consistently occur 30 seconds too early. This the 3G throttling and MECO zero thrust.

This is simulating the STS-61G mission. This is with a historically mass accurate Centaur, CISS and a Galileo mass simulator. And I'm using 109% thrust level with maxed out FRCS and OMS/ARCS propellant levels.

According to everything I have read on the STS-61G mission, this mass combination should leave me well short of the MECO apogee of 240.76 km (130 n.mi) planned for the Centaur missions. Yet, the vehicle is able to reach it and well beyond!

I'm not sure what is going on here.

---------- Post added at 11:20 PM ---------- Previous post was at 08:59 PM ----------

Another data point discovered: The hard coded empty mass is set to that of Columbia, the heaviest orbiter in the fleet, at 81100 kg. There is no way Columbia would have been able to fly STS-61G with that mass as it required Atlantis, the lightest orbiter and the engines at 109% FPL.

For comparison's sake the dry mass of Atlantis as of 2 October 2000 was recorded at 79382.25 kg.

 

[SiameseCat]

I'm currently working on the Centaur stuff, and I have come across a launch anomaly. It is that ascent events, especially second stage events, occur too early. I have logged the events to consistently occur 30 seconds too early. This the 3G throttling and MECO zero thrust.

This is simulating the STS-61G mission. This is with a historically mass accurate Centaur, CISS and a Galileo mass simulator. And I'm using 109% thrust level with maxed out FRCS and OMS/ARCS propellant levels.

According to everything I have read on the STS-61G mission, this mass combination should leave me well short of the MECO apogee of 240.76 km (130 n.mi) planned for the Centaur missions. Yet, the vehicle is able to reach it and well beyond!

I'm not sure what is going on here.

---------- Post added at 11:20 PM ---------- Previous post was at 08:59 PM ----------

Another data point discovered: The hard coded empty mass is set to that of Columbia, the heaviest orbiter in the fleet, at 81100 kg. There is no way Columbia would have been able to fly STS-61G with that mass as it required Atlantis, the lightest orbiter and the engines at 109% FPL.

For comparison's sake the dry mass of Atlantis as of 2 October 2000 was recorded at 79382.25 kg.

Can you check the ET/SRB masses?

---------- Post added at 09:10 PM ---------- Previous post was at 09:04 PM ----------

Also, I think the SSME specifications (thrust & ISP) changed a bit over time. This might have some effect on the Centaur missions.

It might be a good idea to test one of the ISS missions and see if there is still significant overperformance.

 

[GLS]

Well, I think it's a 2 part problem:
> the orbiters back then were heavier (had more "structural stuff" that was changed/removed in the late 90s "diet" for ISS, but had only 3 cryo tank sets (or 4 in Atlantis and Discovery? :idk; there was only the LWT (I don't think we do the differentiation between ET versions); not sure we have the mass of the SSMEs included; and also there was more weight due to the Centaur piping in the aft.
> the SSMEs had slightly different performance, (don't remember exactly at this time of the night but) as the SSME upgrades went along, the engines got heavier and (slighty) less efficient.

 

[DaveS]

Well, I think it's a 2 part problem:
> the orbiters back then were heavier (had more "structural stuff" that was changed/removed in the late 90s "diet" for ISS, but had only 3 cryo tank sets (or 4 in Atlantis and Discovery? :idk; there was only the LWT (I don't think we do the differentiation between ET versions); not sure we have the mass of the SSMEs included; and also there was more weight due to the Centaur piping in the aft.
> the SSMEs had slightly different performance, (don't remember exactly at this time of the night but) as the SSME upgrades went along, the engines got heavier and (slighty) less efficient.

The different ETs are simulated properly in terms of dry masses.

Centaur plumbing mass would have been around 135 kg (not much at all due to the smallness of the plumbing).

The hard-coded empty mass seems to be with everything optional included (RMS, Ku band DA, Orbiter docking equipment (airlock/ODS)).

The three lightweight orbiters all clocked in at an generic weight of 67950 kg at rollout from final assembly in Palmdale.

 

[GLS]

Had a couple of slow days and decided to take another look into my idea for vehicle configuration (in this post). So I basically moved most of the code from the Atlantis constructor, and placed it just after the loading of the mission file. Fired up a scenario and got into orbit just fine (yes, not much of a test :lol.
One easy-to-spot bug is if the configuration file line in the .scn is somewhere in the middle of the other entries, it will probably CTD, because most systems would still not have been created. A possible fix for that would be: 1) reading the .scn file lines into a buffer; 2) finding the configuration file line in the buffer and load it; 3) load appropriate subsystems and stuff; 4) give the rest of the lines in the buffer to the subsystems or back to orbiter.
So, it's a different way of loading the systems, I don't see any drawbacks from it, and we gain more capability in vehicle configuration.

What does everybody else think?

 

[DaveS]

When I was testing and working out the ascent data for STS-61G I noted an issue with the ET post-SRB sep, namely that its texture changes to that of the SLWT instead of maintaining it's LWT texture. I suspect the same is true for the SWT.

 

[DaveS]

Just to give an update on what I'm currently working on:

While going over the current LC-39 element meshes, I discovered size flaws in just about everything, except for the orbiter.

Just to give an example: The ET LH2 tank too long. According to the schematics in the SLWT Systems Definition Handbook (SDH) the length of the LH2 from the intertank flange to the aft dome is 22.8 m. Currently it sits at 23.65m. Not only that the LH2/LOX tanks don't have the same diameter!

And the intertank door as well as the ETCA are located in the wrong areas of the intertank.

I haven't checked the SRB segments yet for any issues. I'm still working on the SLWT mesh.

 

[DaveS]

I have now checked the SRBs, they're good. And the redone ET is coming along nicely.

 

[SiameseCat]

When I was testing and working out the ascent data for STS-61G I noted an issue with the ET post-SRB sep, namely that its texture changes to that of the SLWT instead of maintaining it's LWT texture. I suspect the same is true for the SWT.

I can add a scenario file entry (BURNT_TEX_NAME) to specify the texture to be used after SRB sep.