Board index FlightGear Development Spaceflight

Space Shuttle

Discussion about development and usage of spacecraft

Re: Space Shuttle

Postby amalahama » Tue Aug 30, 2016 6:16 am

Hi Thorsten,

I'd like to improve DPS displays with a specific font to make them closer to reality. I found in each dps_XX.nas several "printf" calls, but I cannot see how X,Y label coordinates are defined. I checked PFD.svg, but all DPS pages labels are defined at X=30, Y=40, overlapping themselves. Could you please shed some light please?

Regards!

P.S-> I think there is a bug in SPEC 50 display. HAC circle seems to be static, but it should change with height, since HAC is a cone, not a cilinder. SCOM 7.4-8, 7.4-2
amalahama
 
Posts: 107
Joined: Mon Mar 28, 2016 9:54 am

Re: Space Shuttle

Postby Thorsten » Tue Aug 30, 2016 10:00 am

Font selection is done by canvas as

Code: Select all
my_text_element.setFont("font_you_prefer.ttf")


The text elements are the same entities the .setText is applied to. I don't know if there's an elegant way to change default fonts globally (might be useful here, because otherwise it's sure a lot of typing...)

Positioning of all text elements is done in the SVG (you're probably not looking at the right place). Note that changing the fonts can potentially screw up all formating as it requires for instance a space to have a certain pixel size - so this needs to be done carefully.

P.S-> I think there is a bug in SPEC 50 display. HAC circle seems to be static, but it should change with height, since HAC is a cone, not a cilinder.


It's not a bug, it shows what guidance is actually doing at the moment, i.e. leading you around a cylinder.
Thorsten
 
Posts: 10740
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle

Postby Thorsten » Tue Aug 30, 2016 6:23 pm

FYI, there's currently a lot going on with orbital DAP selection - I'm wiring up the in-cockpit panel, which requires to change some of the RCS control logic as well (some modes work per-channel, and we can't have all option in all OPS). Expect transient breakage in the devel version while this is going on, and the current scheme based on m, shift-m and control-m will be changed and partially phased out.
Thorsten
 
Posts: 10740
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle

Postby Hooray » Thu Sep 01, 2016 8:20 pm

you can set up a font mapper, and you can set up an appropriate osgText/CanvasText hierarchy and then use props.copy() to use that as a template
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: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: Space Shuttle

Postby amalahama » Fri Sep 02, 2016 7:16 am

Yes, but apart of switching fonts I would need also to rearrange the labels (because of different sizes), and I don't know where it's defined - I tried looking in the SVG and in each dps_XX.nas page, but no success.

Regards
amalahama
 
Posts: 107
Joined: Mon Mar 28, 2016 9:54 am

Re: Space Shuttle

Postby Thorsten » Fri Sep 02, 2016 7:31 am

SVG text element:

Code: Select all
   <text
         sodipodi:linespacing="125%"
         id="p_dps_rel_nav_label33"
         y="30.178572"
         x="43.928574"
         style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
         xml:space="preserve"><tspan
           style="font-size:14px;fill:#ffffff"
           y="170.178572"
           x="352.928574"
           id="tspan3112"
           sodipodi:role="line">POS</tspan></text>


Look from below, y=170.17 and x = 352.92 are the placement positions, not the upper x and y (no idea what they're for).

For DPS pages, the layout formula given row and col of a text element is

x = (col - 1) * 9.5 + 10.9
y = (row-1) * 14.0 + 30.17

and they're pretty much all (98% or so) positioned to spec as in the DPS dictionary.
Thorsten
 
Posts: 10740
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle

Postby amalahama » Fri Sep 02, 2016 9:21 am

Ah thank you, I only saw the first two X,Y which are the same for all text labels :S. Whilst I'm sure (and it looks like so) text is positioned properly w.r.t. row/columns, I've been looking real MEDS screen pictures and I think the overall DPS page should be wider and higher. I found a capture of the DPS design spec in an AIAA paper and it seems the work resolution is 969x702 px, with MEDS being 1024x1024.

Regards
amalahama
 
Posts: 107
Joined: Mon Mar 28, 2016 9:54 am

Re: Space Shuttle

Postby Thorsten » Fri Sep 02, 2016 9:54 am

Ah thank you, I only saw the first two X,Y which are the same for all text labels :S. Whilst I'm sure (and it looks like so) text is positioned properly w.r.t. row/columns, I've been looking real MEDS screen pictures and I think the overall DPS page should be wider and higher.


You can apply to each DPS screen a scale transformation (and a translation) globally - there's no need to change label positions, it'll keep the row/col layout.
Thorsten
 
Posts: 10740
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle

Postby Thorsten » Sat Sep 03, 2016 7:07 am

Migration to orbital DAP pushbuttons should now be complete. The most important changes are:

* 'm' now toggles between RHC and THC, you get a screen message to say which one you currently have as there's no indicator in the cockpit (in the real thing, you know which one you're touching of course) - OMS TVC is no longer selectable manually as a DAP, a programmed OMS burn selects it automatically.

* 'shift+m' is de-activated - vernier thrusters, low-z mode or DAP A/B are now chosen via pushbuttons

* the FG-native HUD shows a unique string for each DAP in case you're confused what the current selection is

* nose only and tail only options are selectable on SPEC 20, all implemented settings on SPEC 20 will be honored by DAP A and B - so gains, attitude and rate deadbands and pulse durations can be chosen as needed - note that the settings can end up being useless or wasteful, there's no safeguards

* pulse durations aren't exact in every channel - in particular low-Z pulsed mode seems to require some attention

* Vernier thrusters now have free and pulsed modes - not sure whether anyone actually needs those, but just in case

Short of distinguishing between normal and high-z and PRI and ALT thruster selections, that's a near-complete functionality of the panel. Enjoy!
Thorsten
 
Posts: 10740
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle

Postby Thorsten » Sun Sep 04, 2016 7:25 am

Flight controller power switches are now implemented - so make sure the controller power is on before trying to fly manually, otherwise you'll get zero control input. There's a test on the view number done, so you can control from pilot view fine if the commander-side controller is switched off or damaged.
Thorsten
 
Posts: 10740
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle

Postby amalahama » Mon Sep 05, 2016 6:43 am

Hooray wrote in Thu Sep 01, 2016 8:20 pm:you can set up a font mapper, and you can set up an appropriate osgText/CanvasText hierarchy and then use props.copy() to use that as a template


Changing just one small text element works fine with "setFont", but I can't do the same when it's a group. Trying to apply "setFont" to "p_ascent" group (which gathers all specific elements from this page) fails miserably. I realised that not all elements from this group are text labels, so within inkscape I split up the group into a TEXT group and a PATH group, applying setFont to the former, but also I failed miserably. In despair, I left everything as it was, and changed the SVG text font directly in inkscape; it worked well in inkscape, but FlightGear seems to use another generic font, ignoring what has been defined in inkscape (so I also failed miserably).

Any ideas? Changing fonts label per label is impractical, there should be a way to change font as a group, or use it as a default....

Regards!
amalahama
 
Posts: 107
Joined: Mon Mar 28, 2016 9:54 am

Re: Space Shuttle

Postby Thorsten » Mon Sep 05, 2016 7:28 am

Hooray sketched it:

you can set up a font mapper, and you can set up an appropriate osgText/CanvasText hierarchy and then use props.copy() to use that as a template


(don't ask me to translate it... it'd take some delving into things).

I wonder if there's a cheaper hack just re-defining the font mapping function on the canvas directly... But it seems the canvas developers did not forsee the need to do font changes by group :-(
Thorsten
 
Posts: 10740
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle

Postby amalahama » Mon Sep 05, 2016 10:52 pm

Yay! I kind of make it, I had to modify a bit the svg.nas file so the svg parser can swallow the type font, so no need of messing up with the dps_XX.nas files. The font has been developed for SSU project, so all the credit is for them. I think it should be a bit bolder though, although the result is already very appealing

Image

This is the real thing:

Image

Regards
amalahama
 
Posts: 107
Joined: Mon Mar 28, 2016 9:54 am

Re: Space Shuttle

Postby Thorsten » Tue Sep 06, 2016 6:02 am

Sweet...

From an aesthetic POV, I actually like the current fonts better, but whatever brings us closer to reality :-) Please post your code changes and let's consult the canvas maintainers whether this can go into mainline.

Also, please ascertain licensing of the fonts (from the context I gather LGPL, so that ought to be okay) - we just need to be sure.
Thorsten
 
Posts: 10740
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle

Postby Thorsten » Tue Sep 06, 2016 10:55 am

Been tinkering with SPEC 94 - we now have in principle the capability to drive the RMS arm automatically, i.e. just enter a target attitude and position into SPEC 94 and put the RMS switch into the AUTO OPR CMD position and the arm will move there - no more driving it manually (or even driving single joints).

It's still a bit quirky though and for some reason doesn't manage to hold attitude exactly... I need to delve into the low level stuff again, I suspect there's a wrong number somewhere.

And no reach limit checks done yet - it will mindlessly drive it till something bad happens (I hope software stop, but I haven't tried...)

The generalization to also support fully automated sequences by just have a Nasal script pushing a sequence of target points is straightforward I guess (though I don't really see a need for this right now).
Thorsten
 
Posts: 10740
Joined: Mon Nov 02, 2009 8:33 am

PreviousNext

Return to Spaceflight

Who is online

Users browsing this forum: No registered users and 2 guests