Board index FlightGear Development Spaceflight

Space Shuttle

Discussion about development and usage of spacecraft

Re: Space Shuttle

Postby Thorsten » Mon Apr 18, 2016 4:00 pm

That's correct I think - it led you to a fairly reputable site on spaceflight details. I've also linked it on some of the wiki pages for background information.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Space Shuttle

Postby Hooray » Mon Apr 18, 2016 6:30 pm

nice ... in the pre-google days, we would use all kinds of "meta-search engines" and still get good results - these days, 99% of our searches (mine included) lead to google - maybe not always the best choice

BTW: when I searched for PEG-4, I came across your topic on the orbiter forum, I was surprised seeing that you were even involved there and doing all the shuttle/fg related promotion you have been doing - and noticed that you asked about reusing display-related code, and possibly "collaborating", referring to this: http://www.orbiter-forum.com/showthread ... stcount=46
Thorsten wrote:My question wasn't so much about license but about, well, let's say collaboration. Since everyone needs displays, it could make sense to just code a display rendering module which everyone uses for instance so there'd be no need to share any code (or to be even able to code). But you answered that on the side.

We're strictly GPL - which sort of makes sense with commercial applications involved. Also, I've come to appreciate the virtue of work not being lost in case a contributor moves on to something different (or dies) and you can't ask any more. And of course the Linux distributions also take licensing pretty seriously, so there's some effort in content auditing for license complicance done.


Is that supposed to suggest that you are contemplating to make your work avavailable to the orbiter folks ?

Like you pointed out, fg stuff is usually GPL (or LGPL in the case of SimGear), but it would definitely be possible to reuse Canvas-based MFDs using a different simulator - it's mainly a matter of coming up with a form of IPC (inter-process-communications) module that can act as the bridge between what your MFD code "expects" from FlightGear, and what is actually provided by orbiter.

Note that this may seem far-fetched to most people around here, but it's actually a very common thing in the FSX/X-Plane communitities, i.e. having 3rd party middleware for glass-cockpit like functionality (think project magenta).

Technically, it's not only possible, but would also be feasible by hooking up a standalone version of fgfs that merely displays the shuttle's Canvas-based MEDS, while it is driven by inputs from an external simulator - e.g. using the generic protocol and/or some other IPC mechanism to exchange relevant data between fgfs and orbiter (sort of like Torsten's fgpanel for Canvas/MFDs)

I am not familiar with orbiter or the technology/rendering stack it is using, but in OpenGL/OSG land it is possible to make an OpenGL texture (FBO/RTT) available to another process, so that it would be possible to render an interactive screen and have it show up in another process.

(Note that the middleware/IPC-based route would address any/all legalities, i.e. it would be perfectly legal for orbiter to reuse GPL'ed modules like that - which is ironically also the main threat that HLA support may sooner or later bring to fgfs ... absent adoption of the Affero GPL)
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Space Shuttle

Postby amalahama » Mon Apr 18, 2016 8:50 pm

Thorsten's shuttle is far, far more advanced than SSU. Yes, they have a nice 3D cockpit, and RMS implementation is quite complete (inverse kinematics included), but avionics are very crude at this point. I also trend to admit that Orbiter is a more practical platform to simulate the shuttle. But for the time being, even without PFD, PEG-4 and Entry AP :roll: , Thorsten's work is the best so far :)

Regards!
amalahama
 
Posts: 149
Joined: Mon Mar 28, 2016 10:54 am

Re: Space Shuttle

Postby Hooray » Mon Apr 18, 2016 8:58 pm

right, my actual question was about Thorsten's postings, which could be read to suggest that the MFD (display) work could be reused by the Orbiter folks - in fact, it seems that while everything is closed source, most addons are not - and there's a fairly well-documented SDK.

Technically, a Canvas texture can be treated like an image, updated at a rate of say 20 hz, and streamed to another process/application - including Orbiter. At that point, all that would be needed to show a Canvas display (texture) like the MEDS is a way to constantly fetch/update that texture in the host application. And that could be accomplished using a custom addon.

So it would be possible to have such fgfs screens show up in another application like Orbiter - for those screens to be meaningful, they would obviously require a way to interact with the host application, i.e. an I/O format to exchange host events (think keyboard/mouse interaction), but otherwise it's mainly a matter of bridging the gap between what fgfs/jsbsim provide to the MEDS routines and what Orbiter has to offer.

Don't get me wrong, I am not saying that this should be done, just pointing out that it's technically possible for Canvas-based displays to be reused/shown by another process/application, and that the degree of IPC needed to make this work would be comparatively lightweight compared to re-creating such avionics from scratch (see the MEDS related comments by the Orbiter folks, which suggest that the FG/Canvas and SVG based approach is very much superior to their development workflow).

Anyway, the code for this sort of thing is readily available in FlightGear - e.g. Torsten modified the screenshot handler code so that he can stream fgfs imagery via http/mongoose (Phi) - the same code could be adapted to stream a single Canvas camera to another process (e.g. VLC for starters)

Besides, the Orbiter folks are apparently working on decoupling their rendering from the simulation loop, too: http://www.orbiterwiki.org/wiki/Orbiter ... on_Project
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Space Shuttle

Postby Thorsten » Tue Apr 19, 2016 6:08 am

As for my involvement in the orbiter forum - I happen to know a few things on spaceflight and astrophysics, so I can help answer user questions there, as well as have information exchanges with some specialists there. It's often easier to simply ask a question than to try to find the solution in detail. And naturally since we have a spacecraft, I'm happy to give a status update as there are probably more people interested in flying the Shuttle in a spaceflight community than here.

If you read the full context, I was mainly curious on how the development model technically works. In particular, orbiter has dozens of spacecraft addons, and they all have displays - so it'd make sense for them to be able to share display code among each other. But from the answer given, it seems that's not done. I wasn't even contemplating sharing the FG technology for the purpose. Since we're GPL, I have no issue should this happen of course, and I'll be happy to answer questions to the point should I be asked, but I won't lose any sleep over trying to make this happen.

Also, note that our air/spacecraft design is forced to be compartmentalized by the very design of JSBSim and canvas. Here it's already clear how the command flow to systems look like (input properties), how it's processed (channels of JSBSim elements) etc. - so there's a natural and very reasonable separation what is part of the state of the system vs. what is part of the state of a display.

(For instance, temperatures as systems states are typically in K, but temperatures as part of the display state are typically F). Unless you had pretty much the same separation in your simulation, being technically able to port the display wouldn't help you too much.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Space Shuttle

Postby Thorsten » Tue Apr 19, 2016 7:17 am

RMS implementation is quite complete (inverse kinematics included)


If by inverse kinematics you mean the manual augmented RMS driving modes like ORB UNL where you drive the end effector position and orientation with the stick and the joint angles adjust to that input, I have implemented some of that as well. There's no END EFF mode with a dedicated camera, but for instance ORB UNL should work. It just doesn't work up-front, because the latching position for the RMS arm is inside the software stop region, so you need to drive the arm via joint angles into the region where the augmented mode starts working.

I haven't tested this in a while, and there was always a quirk with the Euler singularity when attaching the end effector from above, but in principle it's there.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Space Shuttle

Postby amalahama » Tue Apr 19, 2016 9:12 am

Interesting, thank you. I will have a look when I get some time. There is no RMS entry in the wiki, right?

EDIT: Sorry, you actually wrote a RMS tutorial in the general Space shuttle page, I was looking for it in the Orbital Operations page, my fault

Regards!
amalahama
 
Posts: 149
Joined: Mon Mar 28, 2016 10:54 am

Re: Space Shuttle

Postby Hooray » Tue Apr 19, 2016 3:57 pm

Richard wrote in Fri Apr 15, 2016 9:34 pm:At the moment we're waiting for someone to volunteer to draw [... the PFD... ] as I think it's beyond our abilities currently. I spent many hours trying to draw it and didn't really get anywhere. If someone can draw (in SVG) the PFD then we animate it; it's just the basic drawing that I struggle with, all of those ticks and circles seem to require inkscape skills that I don't have...


Looking at the complexity of the PFD on the shuttle, I agree, it seems like tons of work to re-create this manually - in fact, it may be much less work to create the SVG for this procedurally using a bit of Python code (via Inkscape and/or standalone, obviously, the alternative would be directly using Nasal/Canvas and OpenVG paths-to be fair, there are some tools to semi-automatically convert raster images to vector graphics, but the results are usually poor).

http://florian-berger.de/en/articles/cr ... om-python/
http://codeboje.de/pysvg/
https://pypi.python.org/pypi/svgwrite/
http://code.activestate.com/recipes/325 ... in-python/


Image
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Space Shuttle

Postby Thorsten » Tue Apr 19, 2016 7:05 pm

I don't have any inkscape skills, but imagining to draw it in a vector program, it's going to be tedious. Okay - pretty much all about the Shuttle avionics is. I'm working since 1 1/2 weeks on the SPEC 23 page (the RCS thruster management). We have lots of thrusters (I guess close to 50). Each of them can fail in three different ways (on, off, leak), can have automatic deselection inhibited, can be manually deselected and has a priority assigned.

You count the properties that need to be managed internally... In addition the display shows the whole propellant flow to each of the pods,...

There's no real shortcut with any of this. Someone who has at least a workflow ready just has to slog through it, and then it's done.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Space Shuttle

Postby Hooray » Tue Apr 19, 2016 7:32 pm

I don't know anything about the requirements, but if the corresponding SVG elements are basically "identical" or can be created in a parametrized fashion, you could automate this to some degree; the relationship here is not unlike static textures vs. procedural texturing - the svg.nas module really only supports a tiny subset of Inkscape markup (SVG/XML), and that tiny subset is mapped to OpenVG primitives in the form of Canvas.Path elements.

In other words, Canvas.Path is definitely lower-level, and more feature-rich, than the current svg.nas module and its supported functionality. However, none of this is mutually exclusive - in fact, the parser works such that it clones some elements via props.copy() - and the same approach could be used to augment SVG files, e.g. by treating an element as a template that is the parameterized and procedurally added/instantiated multiple times.

For the specifics, I would need to look at the corresponding SVG/XML markup you have already - but if the corresponding "page" has a number of more or less identical elements, that primarily differ in terms of their relative position, instancing, color etc - that would seem like a natural way to create such pages procedurally in a semi-automated fashion, as long as you have a single element "ready" that can be treated as a template for other instances of the same element.

Under the hood, this is exactly what the svg.nas module is doing when it translates SVG/XML to Canvas.Path elements - and referring to Richard's comments about tic marks, that is something where procedurally creating such marks would simply make sense, because it's mainly a for-loop that sets up the compass rose (or whatever it is).

For instance, the screenshot below is basically also depicting a vector image, but it would have taken too much time to create that manually (Inkscape) or to create the corresponding traffic files, so I ended up using a for-loop that would add a bunch of AI entities to the scenery aligned in a circle with an offset, so that the Canvas groups, and underlying Canvas.Path elements, would be automatically created:

Image

Presumably, most of the more experienced coders around here, would rather use code to create such elements procedurally than having to learn how to use Inkscape, and I guess that also applies to the PFD :lol:
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Space Shuttle

Postby Richard » Tue Apr 19, 2016 7:53 pm

Hooray wrote in Tue Apr 19, 2016 7:32 pm:I don't know anything about the requirements, but if the corresponding SVG elements are basically "identical" or can be created in a parametrized fashion, you could automate this to some degree;

Presumably, most of the more experienced coders around here, would rather use code to create such elements procedurally than having to learn how to use Inkscape, and I guess that also applies to the PFD


One of the things that I didn't get working was the program to create the SVG for the ADI ball thing. I managed to do it for the HUD ladder on the F-15, but it's messy and also quite tedious to do, maybe not as tedious as manually editting the SVG, but there is a tradeoff point. I reckon it probably took me longer to write the program to make the ladders than it would have taken to do it manually. I also started to draw the PFD manually so I could automatically fill in the intervening elements, but again I didn't get that working either. Drawing things in code is often also tedious because it takes ages (for me) to get everything aligned right. This is where I prefer inkscape, with a bit of SVG editting.

So as always, it's not a simple as "let's just write a program to do it".
Richard
 
Posts: 810
Joined: Sun Nov 02, 2014 11:17 pm
Version: Git
OS: Win10

Re: Space Shuttle

Postby Hooray » Tue Apr 19, 2016 8:00 pm

One of the things that I didn't get working was the program to create the SVG for the ADI ball thing.


I think the "ADI ball thing" was once mentioned before, IIRC when omega95 was working on the ADI for the SpaceShipOne (?); I think we arrived at the conclusion that SVG was for 2D and not particularly suitable for coming up with 2D vector graphics representing a 3D model that needs to be animated/rotated later on.

Omega95 ended up requesting support for 3D models to be added to the Canvas system, so that he could load an actual 3D model of a sphere and rotate/animate that using properies.

Again, I don't know anything about the shuttle avionics or the MFDs/PFD in particular, but I once came up with code for loading arbitrary 3D models into a Canvas element, and it took roughly 50 lines of C++ code (adapted from standard OSG examples), with the rest being solely boilerplate for inheriting a child class from Canvas::Element, i.e. took much less time than it would have taken me to create a 3D ADI in Inkscape:

http://wiki.flightgear.org/Canvas_Sandbox#CanvasModel
Image
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Space Shuttle

Postby Richard » Tue Apr 19, 2016 9:05 pm

Hooray wrote in Tue Apr 19, 2016 8:00 pm:
One of the things that I didn't get working was the program to create the SVG for the ADI ball thing.


I think the "ADI ball thing" was once mentioned before, IIRC when omega95 was working on the ADI for the SpaceShipOne (?); I think we arrived at the conclusion that SVG was for 2D and not particularly suitable for coming up with 2D vector graphics representing a 3D model that needs to be animated/rotated later on.


I'm damn sure if the avionics manufacturers managed to animate this on 1990's tech then we can do it in canvas and svg with the tech we've already got. I'm prepared to bet that there isn't a line of 3d code in the original, and that any 3d effect that you see would be easily reproduced with a bit of trig.
Richard
 
Posts: 810
Joined: Sun Nov 02, 2014 11:17 pm
Version: Git
OS: Win10

Re: Space Shuttle

Postby Hooray » Tue Apr 19, 2016 10:12 pm

Undoubtedly, you must be correct about that - I think that conclusion was based on weighing the pros/cons (i.e. pain vs. gain) of figuring out all the trigonometry required to rotate a sphere and animate things correctly vs. simply taking an actual 3D sphere and hooking it up to a few properties (especially given that our cockpits are traditionally built exactly that way, i.e. a bunch of sequentially applied transformations).

Besides, I was wrong about the aircraft involved, it seems, it was the SpaceShip2:

viewtopic.php?p=164243#p164243
viewtopic.php?f=71&t=17278&p=164260&#p164260

In other words, if someone figures out the math for this, that would also be useful elsewhere.

Image
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Space Shuttle

Postby amalahama » Tue Apr 19, 2016 10:34 pm

Yes, ADI ball is 3D in the real thing, though the implementation looks pretty basic

https://www.youtube.com/watch?v=xNSqhjA3JfM

https://www.youtube.com/watch?v=ifZJL9fGwtk

Honestly, I'd not be so worried about the visual aspect of PFD, but with the complex functionality, since there are several modes depending on flight phase and pilot customization. I'd rather prefer a proper implementation of all modes (including HSI as well of course) with just interim visuals (until SVG/procedural is available) than the other way around.

A small request: It's possible to make an option to assign num pad to shuttle keypad? I hate typing with the mouse, I have enough with my bank's sign-in page :)

Regards!

P.S -> By the way, Orbiter's SSU is under common license, IIRC. If they agree to donate its virtual cockpit for FG Shuttle, would it be possible to import it? Their cockpit is very mature and almost all main panels are already available, and my impression is that labels are more readable. Just saying.
amalahama
 
Posts: 149
Joined: Mon Mar 28, 2016 10:54 am

PreviousNext

Return to Spaceflight

Who is online

Users browsing this forum: No registered users and 2 guests