SSU Development Thread (2.0 to 3.0)

[Goth]

It may be the way to go, since things like shuttle internals, crew data, checklists, etc, are not known by Orbiter anyway. In that case Qt or anything C++ based would be ok for what concerns the GUI. And you solve the libUltra (or any other lib) problem.

---------- Post added at 16:13 ---------- Previous post was at 16:09 ----------

Let's say you want to retrieve crew information, you should do something like:
SSU DLL <-> Orbiter <-> MCC
Instead with a Orb:Connect/socket/whatever you would just do:
SSU DLL <-> MCC

Also, if you ever consider multiplayer you would have to go that route anyway...

 

[STS]

Instead with a Orb:Connect/socket/whatever you would just do:
SSU DLL <-> MCC
Also, if you ever consider multiplayer you would have to go that route anyway...

Not multiplayer, but "telemetry" clients connecting by orb:connect and requesting spacecraft data. For example, right now, engine status is not received by Orb:Connect when a burn is performed in SSU.

 

[Goth]

Yes, multiplayer meaning people doing the flight controllers.

Well, what should we use?

Orb:Connect may work only if you want state vectors or other Orbiter-specific stuff. After reading Orb:Connect docs I see that SSU specific information can't be passed since there isn't a generic get/send message function.

 

[GLS]

Right now the only use for MCC is FDO, for trajectory calculations.

Not necessarily: there's already some SSME/MPS data available in the GPCs, if there's a way to send it to the "MCC" we could have a "Booster display" giving additional insight about those systems. :thumbup:

 

[Urwumpe]

Not necessarily: there's already some SSME/MPS data available in the GPCs, if there's a way to send it to the "MCC" we could have a "Booster display" giving additional insight about those systems. :thumbup:

And we could also record and downlink SSME performance data after ascent, for further debugging.

I think a standalone application is the best solution, since this would also allow us more flexibility. It should just be platform independent enough to also support Linux systems, since quite many here use it as primary or secondary PC.

 

[Goth]

You're basically saying Qt. The problem is how to do the communication. I don't know where to start about this.

 

[Urwumpe]

You're basically saying Qt. The problem is how to do the communication. I don't know where to start about this.

No, thats not true. Please be correct, we can use there:

• C++ with Qt
• C++ with wxWidgets
• Python with PyQt
• Java with anything
• C#/.NET (On Linux with Mono)
• etc.

The C++ options would mean that we reduce the number of programming languages in the project, but I am strongly convinced, that Java or C# would be the better languages for the task of creating an application that is primarily a user interface for displaying and interacting with data received over a network connection. C++ simply means too much low-level programming for the task.

Especially since we would not need to recompile everything with C# or Java, but could use one package for both.

The simple problem is: I can't do it because I am too busy. So I have no base to do any decisions in SSU currently. I can only make recommendations.

 

[Goth]

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

 

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