Board index FlightGear Development Spaceflight

Space Shuttle - Bugfixes

Discussion about development and usage of spacecraft

Re: Space Shuttle - Bugfixes

Postby Thorsten » Wed Jan 15, 2020 7:00 am

Okay, we now have this interesting situation... we know the error is currently zero (because the property says so).

We know the integrator value has been driven to -0.17 in the case of joystick held but to -0.0149 in the case of joystick not held. For that to happen, the error must have been non-zero at some point in the past.

The error is computed like this:

Code: Select all
      <fcs_function name="systems/vectoring/pitch-rate-error">
      <function>
         <difference>
            <property>velocities/q-rad_sec</property>
            <product>
               <sum>
                  <product>
                    <property>fcs/elevator-cmd-norm-css</property>
                  <difference>
                     <value>1.0</value>
                     <property>systems/ap/launch/autolaunch-pitch-channel</property>
                  </difference>
                  </product>
                  <product>
                     <property>systems/ap/launch/pitch-cmd</property>
                     <property>systems/ap/launch/autolaunch-pitch-channel</property>
                  </product>
               </sum>
               <value>-0.2</value>
            </product>
         </difference>
      </function>
      </fcs_function>


We know that systems/ap/launch/pitch-cmd is zero. We know systems/ap/launch/autolaunch-pitch-channel is 1. We know it should always have been 1 because it is initialized to that value in SpaceShuttle-common.xml.

The stick command is only felt via fcs/elevator-cmd-norm-css (as it should) - but that is multiplied with (1 -systems/ap/launch/autolaunch-pitch-channel) - which is to say, with zero.

So about the only explanation I can think of is that we're seeing a buggy initialization sequence (like in the case of the brakes) - the functions are run, but the parameters are not yet set and default to zero.

Now, if that is true, the stick should not do a thing if you pull it after the splash screen disappears and the Shuttle sits on the pad (basically what I can do with the mouse or keyboard). It should only affect the integrator when you do this during the whole splash sequence.

Could you verify that - and if it works out, make a post to the mailing list (sadly, I'm temporarily out since my internet provider has issues with its webmail interface that doesn't connect to a mail server properly, and the backup mail server I'm using gets blocked by the list because of a spam history...)
Thorsten
 
Posts: 11698
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle - Bugfixes

Postby amalahama » Wed Jan 15, 2020 1:00 pm

Thorsten,

It's been quite a while since last time I run the Space Shuttle, but yesterday I lunched it and for some reason the MDU canvas background is transparent, I think it was dark grey before. That makes them almost impossible to read. I'm running FG 2018 still.

And BTW, is there a way to change the canvas size?

Thanks, best regards
amalahama
 
Posts: 130
Joined: Mon Mar 28, 2016 9:54 am

Re: Space Shuttle - Bugfixes

Postby eatdirt » Wed Jan 15, 2020 1:39 pm

apparently you (still) have AI enabled...


Just to say that I have recompiled fg with -fbound-check, and even with --disable-ai-traffic I have gotten a segfault after 10 runs or so. In my opinion, there might be a big stack overflow somewhere, which then would explain all this crazy nasal message errors sometime. If I remember correctly, without --fbound-check, by default, on gcc, stack overflow is detected only for small stack excess. If you get a big one, exceeding the trapped size, you're back to the 80s in terms of memory management.

EDIT: done
I'll try to catch the new one in gdb

It appeared again during a Lambert calculation:

Code: Select all
Thread 67 "fgfs" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fddc3faa700 (LWP 22380)]
0x00007fde3fc88cea in naObj (type=type@entry=2, o=0x67b201)
    at /usr/src/debug/simgear-2019.2.0-10.mga7.x86_64/simgear/nasal/misc.c:33
33          o->type = type;


It is at the same code location as in https://forum.flightgear.org/viewtopic.php?f=87&t=35077&start=270#p359816, but this time, I started fgfs with --disable-ai-traffic.

Moreover, at each iteration of the Lambert targetter, I can see the [SGExclusiveThread] popping out, and the last messages in the console before the segfault are:

Code: Select all
5948.14 [ALRT]:nasal      Lambert targeting to TIG 1 started...
 5948.14 [ALRT]:nasal      Current state vector:
 5948.14 [ALRT]:nasal      x: 1064919.08319442 y: -20073046.60099073 z: 7673873.916777525
 5948.14 [ALRT]:nasal      vx: 16671.89543550322 vy: 7874.740001264808 vz: 17920.06422188446
 5948.14 [ALRT]:nasal      t: 0
 5948.14 [ALRT]:nasal      Current position:
 5948.14 [ALRT]:nasal      lat: 20.89488409077897 lon: -110.311860944954
 5948.14 [ALRT]:nasal
 5948.14 [ALRT]:nasal      Setting target velocities to
 5948.14 [ALRT]:nasal      Target T1 vx: -4719.625144093297
 5948.14 [ALRT]:nasal      Target T1 vy: -4272.419161237776
 5948.14 [ALRT]:nasal      Target T1 vz: -4360.001023858786
 5948.14 [ALRT]:nasal      Starting targeting routines
 5948.15 [ALRT]:nasal      Current: 0 total: 0
 5951.77 [ALRT]:nasal      [SGExclusiveThread]  not finished - skipping
 5953.22 [ALRT]:nasal      [SGExclusiveThread]  not finished - skipping



The backtrace reads:
Code: Select all
#0  0x00007fde3fc88cea in naObj (type=type@entry=2, o=0x67b201)
    at /usr/src/debug/simgear-2019.2.0-10.mga7.x86_64/simgear/nasal/misc.c:33
#1  0x00007fde3fc88db4 in naNew (c=c@entry=0x25ff3cc0, type=type@entry=2)
    at /usr/src/debug/simgear-2019.2.0-10.mga7.x86_64/simgear/nasal/misc.c:72
#2  0x00007fde3fc88ead in naNewHash (c=c@entry=0x25ff3cc0)
    at /usr/src/debug/simgear-2019.2.0-10.mga7.x86_64/simgear/nasal/misc.c:96
#3  0x00007fde3fc7bee8 in setupFuncall (ctx=ctx@entry=0x25ff3cc0, nargs=0,
    mcall=mcall@entry=1, named=named@entry=0)
    at /usr/src/debug/simgear-2019.2.0-10.mga7.x86_64/simgear/nasal/code.c:342
#4  0x00007fde3fc7dab2 in run (ctx=ctx@entry=0x25ff3cc0)
    at /usr/src/debug/simgear-2019.2.0-10.mga7.x86_64/simgear/nasal/code.c:740
#5  0x00007fde3fc7ed60 in naCall (ctx=0x25ff3cc0, func=..., argc=argc@entry=0,
    args=args@entry=0x0, obj=..., locals=..., locals@entry=...)
    at /usr/src/debug/simgear-2019.2.0-10.mga7.x86_64/simgear/nasal/code.c:936
#6  0x00007fde3fc8bd7f in threadtop (param=0x3a92f640)
    at /usr/src/debug/simgear-2019.2.0-10.mga7.x86_64/simgear/nasal/threadlib.c:29
#7  0x00007fde400ec04c in start_thread () from /lib64/libpthread.so.0
#8  0x00007fde3dacf58f in clone () from /lib64/libc.so.6



Cheers,
Chris.
Last edited by eatdirt on Wed Jan 15, 2020 11:20 pm, edited 2 times in total.
eatdirt
 
Posts: 607
Joined: Wed Aug 15, 2018 2:06 pm

Re: Space Shuttle - Bugfixes

Postby eatdirt » Wed Jan 15, 2020 8:06 pm

Now, if that is true, the stick should not do a thing if you pull it after the splash screen disappears and the Shuttle sits on the pad


Yes, that is exactly what happens!!
eatdirt
 
Posts: 607
Joined: Wed Aug 15, 2018 2:06 pm

Re: Space Shuttle - Bugfixes

Postby eatdirt » Wed Jan 15, 2020 11:25 pm

Let me start another post about sound issues. I don't want to give too much details, but I am loosing randomly part of the Shuttle noise soon before SRB sep, like main engines sound, but not the buttons' click for instance. I suspect that is an issue I have related to openAL on my machine, and I am currently the only one having this.

Anyway, since I am paying attention now, could someone check if:

1) When you're sitting at the pilot's seat, entering commands onto the pilot's keypad and commander's keypad produces lovely "tic tic..."
2) When you're sitting at the commander's seat, entering command onto the commander's keypad and pilot's keypad does not produces any sound?

Thank you!
Cheers,
Chris.
eatdirt
 
Posts: 607
Joined: Wed Aug 15, 2018 2:06 pm

Re: Space Shuttle - Bugfixes

Postby legoboyvdlp » Thu Jan 16, 2020 8:28 pm

eatdirt wrote in Wed Jan 15, 2020 1:39 pm:
apparently you (still) have AI enabled...


Just to say that I have recompiled fg with -fbound-check, and even with --disable-ai-traffic I have gotten a segfault after 10 runs or so. In my opinion, there might be a big stack overflow somewhere, which then would explain all this crazy nasal message errors sometime. If I remember correctly, without --fbound-check, by default, on gcc, stack overflow is detected only for small stack excess. If you get a big one, exceeding the trapped size, you're back to the 80s in terms of memory management.


You got a reliable method to reproduce this (even if it takes >10 runs)?
Does it happen (across many runs) if you have the GC threading disabled?
User avatar
legoboyvdlp
 
Posts: 7706
Joined: Sat Jul 26, 2014 1:28 am
Location: Northern Ireland
Callsign: G-LEGO
Version: next
OS: Windows 10 HP

Re: Space Shuttle - Bugfixes

Postby eatdirt » Thu Jan 16, 2020 10:43 pm

I have encountered it 3 times only, so I cannot say it easily reproducible. It appears, however, only when doing trajectory calculations, got one in OPS 105, and two during Lambert targetting (I cannot be sure it is the same bug for OPS 105 as I was not running gdb behing). For the GC threading, I did not test yet with disabled, but I will... Up to the fact that something significant may only be obtained by not having a crash over more than 10 runs... :-/
eatdirt
 
Posts: 607
Joined: Wed Aug 15, 2018 2:06 pm

Re: Space Shuttle - Bugfixes

Postby eatdirt » Fri Jan 17, 2020 10:51 pm

Thorsten, I think something goes weird with the RDV windows closing in to ISS. Dunno if you have changed something?

First, I've seen again ISS jumping around, twice, by not much, but still, suddenly it jumps like one meter away. This happens at times during which the relative velocities are crazy, like thousand feet/s, random, and then they go back to the expected values. As you can see below, I am also monitoring RDV on SPEC 33, and Rdot there is always fine.

More interestingly, it seems that the RDV window reports something biased. Look, here I followed the RDV offsets

Image

Image

And I bounced, I was less than 1ft on x/y, very slow, correct attitude:

Image

Then, I followed what I am seeing, so centering the docking colar by eyes worked perfectly, the rdv windows was then displaying a few feet of offset on x/y.

Image

On the bright side, it is much nicer to do the docking by eyes :)

But still, if the ISS 3D model is at the right location, them something should be wrong between what RDV takes as ISS!? Let me know if you want me to monitor something next time I am trying.

Cheers,
Chris.
eatdirt
 
Posts: 607
Joined: Wed Aug 15, 2018 2:06 pm

Re: Space Shuttle - Bugfixes

Postby Thorsten » Sat Jan 18, 2020 6:15 am

More interestingly, it seems that the RDV window reports something biased.


Yes, it does (the manual explains this I believe) - the RR shows the distance from Shuttle center to ISS (and should not be used when in close proximity < 30 m or so), the dialog window actually has perfect information and shows the distance from the Shuttle docking collar to the ISS docking port. While the first is not zero when you're docked, the second is.

So using the window technically is a cheat.

Also, they're using two different code paths to compute distances - the window information is computed directly in the dialog, the REL NAV info passes through a host of sensor code, so a glitch in one does not necessarily affect the other.

First, I've seen again ISS jumping around, twice, by not much, but still, suddenly it jumps like one meter away.


Unless someone extends FG to add multiple FDMs and do the computation with the same JSBSim code that moves the Shuttle, we're unfortunately going to have to live with that. There's limits to what is possible to code aircraft-side.
Thorsten
 
Posts: 11698
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle - Bugfixes

Postby Thorsten » Sat Jan 18, 2020 7:14 am

but yesterday I lunched it and for some reason the MDU canvas background is transparent, I think it was dark grey before.


No, it was always transparent (so that one could see the shadows on the display background), but for some reason in old FG versions it wasn't shown such when patched to a separate window.

Now it's displayed as defined.

(And since it's a copy of the in-cockpit displays, we can't make it different in the dialog and in the cockpit).

And BTW, is there a way to change the canvas size?


I think if you actually want to change the canvas size you're in for a lot of work, because the whole positioning of elements inside the canvas is by explicit (x,y) coordinate position - so there's like 10.000 numbers you'd have to change.

If you want to change the size of the window that pops out, I believe that's easier to do though, you just change the numbers for the window size.
Thorsten
 
Posts: 11698
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle - Bugfixes

Postby eatdirt » Sat Jan 18, 2020 2:18 pm

the dialog window actually has perfect information and shows the distance from the Shuttle docking collar to the ISS docking port


Sorry, I may not have been clear. This is what I understood from the manual, indeed, but my post was to show that it does not. Following the dialog window, I cannot dock in spite of x,y,z < 1ft on the dialog window. I managed to dock only by the visual!

So, pictures 1, 2, 3 are snapshots while approaching using the dialog window only. Look at picture 3, z is vanishing, I should have docked then. But then I bounced. Picture 4, on the other hand, is by ignoring completely the dialog window and using visual only (I was unable to take a snapshot of the dialog window for picture 4 before docking as I was too busy to watch the docking colar, but the window dialog was off by a few feet!)
eatdirt
 
Posts: 607
Joined: Wed Aug 15, 2018 2:06 pm

Re: Space Shuttle - Bugfixes

Postby Thorsten » Sat Jan 18, 2020 2:53 pm

I'm not really sure how that would happen, because the docking condition check uses pretty much the numbers on the dialog.

There's an attitude check though, so zeroing coordinates is not enough to dock.
Thorsten
 
Posts: 11698
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle - Bugfixes

Postby eatdirt » Sat Jan 18, 2020 4:41 pm

There's an attitude check though, so zeroing coordinates is not enough to dock.


Yes, this what I thought at first, but the ADI ball is quite flat. Then remains the relative yaw compared to ISS, but picture 4 is like 30s after the bounce and the yaw on the ADI ball was the same, that's the picture just after docking:

Image

But, maybe, this has something to do with the "jumping". I'll try to get more info next time, if that happens again. Let's also say that this is with next...
eatdirt
 
Posts: 607
Joined: Wed Aug 15, 2018 2:06 pm

Re: Space Shuttle - Bugfixes

Postby Thorsten » Sat Jan 18, 2020 5:25 pm

that's the picture just after docking:


Devoid of information unfortunately as the docking process cancels non-zero attitude. Post-docking pictures will always show perfect attitude.
Thorsten
 
Posts: 11698
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle - Bugfixes

Postby eatdirt » Sat Jan 18, 2020 5:30 pm

Ok, good to know. Still ADI ball shows yaw 313 both cases!
eatdirt
 
Posts: 607
Joined: Wed Aug 15, 2018 2:06 pm

PreviousNext

Return to Spaceflight

Who is online

Users browsing this forum: AhrefsBot [Bot] and 0 guests