Board index FlightGear Development Spaceflight

Space Shuttle - Development

Discussion about development and usage of spacecraft

Re: Space Shuttle - Development

Postby wlbragg » Wed May 26, 2021 12:04 am

Believe it or not I hadn't gotten bitten by Euler singularity yet until just now. After straightening out all the angles of the RMS arm I got both the arm model and the CCTV overlay model to be visible again but froze one of the joints.

I've seen this type of model disappearing from view at certain angles before. Also after all the extreme angle rotations and translations the CCTV model or the view or the arm or any of the 3 are not at the original alignment.

I think it is going to take a lot of time and effort to debug all that could be going wrong. At the moment my biggest obstacle is not being able to capture the payload (HST).
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7574
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

Re: Space Shuttle - Development

Postby eatdirt » Wed May 26, 2021 12:19 pm

Ok, let me try to separate the many things you have asked!

First of all, I assume you have not modified the .ac files I've tuned. They were: hst.ac, SPARTAN-201.ac, TDRS_demo.ac and rmsArm.ac. If yes, be very careful, any change of scale, or origin, will destroy the tuning. If in doubt, try back the original files to see if this is the cause of the problem. Also, I've added texture files for SPARTAN and TDRS, the one giving the target on the grapple fixture!
If you want, I can put the blender files somewhere to update your repository of 3D objects. Notice that you can already add the grapple fixture: https://curl.irmp.ucl.ac.be/~chris/upload/fg/ss/grapple_fixture/

1) Catching Hubble.
The active grapple is the one closest to to the RMS arm when HST is in the payload bay. With the RMS view, ensure that you have the grapple fixture target and stick just in the middle of the view! In other words, the end effector X,Y,Z should be around
X=7.8
Y=0.75
Z=0.10
and it should have an attitude close to:
P close to 90 deg (this is Euler), so realistically should be 82-84 degrees.
Y = 0
R = 180 (mind the roll!!!)

2)
"The arm eventually also disappeared"


I suspect you mean, from the SRMS view, in some attitude the arm becomes translucent whereas it is still visible in other views. I've seen that too and interpreted it as some openGL clipping conditions being triggered. I don't know what can trigger this as the view is always out of the arm. Maybe some rough approximations made by the graphic drivers induce this effect (I've seen this before with the "red cut" in Earthview). This one is tricky to solve as being really at the graphic level.

3)
Also after all the extreme angle rotations and translations the CCTV model or the view or the arm or any of the 3 are not at the original alignment.


This can happen only if you pass over the Euler singularity, I mean you push the pitch larger than P=90 degrees and move the arm back in the bay by yawing at more than 180 degrees. If you have done so, yes, I expect the alignment to be broken. But if you go back to P < 90 degrees and Y < 180, you should recover the original state.

4)
After straightening out all the angles of the RMS arm I got both the arm model and the CCTV overlay model to be visible again but froze one of the joints.


Here, I suspect this is not Euler at all [Euler is point 3) above] but you have reached the STOP of the RMS. The joint angles have software stop limitations (as coded in our Shuttle and also in reality).

If you reach one of them, you cannot move the arm anymore. You should take SINGLE mode and move the offending joint angle back to an allowable value. For instance, if you have pushed the elbow too deeply in its "unnatural position" , you have to reduce its angle value for a while to make it functional again. To be more specific, internally, that angle assumes a value, let's say 200 degrees. You have to reduce it to 180 degrees to start seeing the elbow moving again. But while you're reducing its value, nothing is happening (unless you monitor the property tree), which can be very confusing and disturbing. Also, if you make a mistake and increase its value to values larger than 200 degrees, the elbow will remain locked and it is very likely that you'll never be able to unlock it again. Within the payload specialist view, a talkback indicates "STOP" when this is happening.

In conclusion, 1) and 4) should be no problem, but 3) being Euler is likely to be unfixable! Concerning 2), that should be fixable, but we need to understand more what triggers this graphic clipping of the close object.

Let me know how it goes!
eatdirt
 
Posts: 1012
Joined: Wed Aug 15, 2018 3:06 pm

Re: Space Shuttle - Development

Postby wlbragg » Wed May 26, 2021 3:47 pm

Thanks Chris, that all makes sense. I will have to test again, this time staying within known tolerances. The only thing that puzzles me, and I'll have to test it again to verify it, is that when I had the end effector positioned correctly, by correctly I mean from the exterior view it looked like it was lined up correctly, in the CCTV view the target was not in the center of the target, it was way off to a side almost out of view. That doesn't seem to line up with what you said I should be seeing. But I'll have to test it again after referancing your post.
The disappearing model issue happened with both the CCTV overlay and the arm itself. My first impression was that it disappeared consistently after traversing past 45 to 90°, somewhere in that range
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7574
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

Re: Space Shuttle - Development

Postby wlbragg » Wed May 26, 2021 3:52 pm

Thanks Chris, that all makes sense. I will have to test again, this time staying within known tolerances. The only thing that puzzles me, and I'll have to test it again to verify it, is that when I had the end effector positioned correctly, by correctly I mean from the exterior view it looked like it was lined up correctly, in the CCTV view the target was not in the center of the target, it was way off to a side almost out of view. That doesn't seem to line up with what you said I should be seeing. But I'll have to test it again after referancing your post.
The disappearing model issue happened with both the CCTV overlay and the arm itself. My first impression was that it disappeared consistently after traversing past 45 to 90° pitch, somewhere in that range. What I couldn't tell is if that was with a combination of joints or just a single joint. I also didn't verify if that was with yaw as well. I don't understand why though, it's not like we don't push all our other views, at least some of them, well past those angles in all planes.
To verify, I pulled a fresh development copy and moved just my CCTV model and texture and code over to that. So I know I captured model your changes.
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7574
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

Re: Space Shuttle - Development

Postby eatdirt » Wed May 26, 2021 8:59 pm

The disappearance is tricky. Even a (P,Y,R)=0,0,0, it occurs when the arm translates into some region. Also, if you zoom in within the RMS view, the arm usually reappears, so it really smells a near object clipping.

I have been trying to understand it more, and it is also present in the other views. For instance, this is Heli view zooming in (I searched for a while before finding it):

rmsclip_vp9.webm

If someone has an idea on what is going on, any hint welcome!

@Wayne: I wanted to add that driving the RMS in augmented mode, with the joystick and rudder pedals, is easier than toying only with the joint angles. Everything is detailed in Thorsten's book, the flight manual, section "Payload Handling".
The automatic mode in SPEC 94 is the fastest, but a bit harder to learn and use I suspect. To confirm, I've tried again HST grappling in the payload bay on current devel snapshot, everything works fine for me.
eatdirt
 
Posts: 1012
Joined: Wed Aug 15, 2018 3:06 pm

Re: Space Shuttle - Development

Postby Thorsten » Thu Jun 10, 2021 6:14 pm

I've just pushed some fixes to Eileen which should hopefully improve stationkeeping for the more coarse modes - there used to be a small but persistent drift.

I wonder whether the same logical issues plague the Shuttle INRTL DAP - I'm guesing GinGin relaxed the deadbands a bit, and now I've seen attitude drift out of any reasonable deadband when I did entry attitude 20 minutes prior to the event - which used to work okay.

We should probably have a look at this...
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Space Shuttle - Development

Postby GinGin » Fri Jun 11, 2021 1:07 pm

I'm guesing GinGin relaxed the deadbands a bit


Yes, indeed.
Mainly the DAP A pri rate deadband (from 0.001 to 0.7) to avoid too much RCS wasting during DAP transition phase.
We can adjust it.

Original values:
Code: Select all
  <section-defined type="bool">false</section-defined>
  <dap-A-PRI-rot-rate type="double">1.0</dap-A-PRI-rot-rate>
  <dap-B-PRI-rot-rate type="double">0.5</dap-B-PRI-rot-rate>
  <dap-A-VRN-rot-rate type="double">0.1</dap-A-VRN-rot-rate>
  <dap-B-VRN-rot-rate type="double">0.05</dap-B-VRN-rot-rate>
  <dap-A-PRI-att-db type="double">0.12</dap-A-PRI-att-db>
  <dap-B-PRI-att-db type="double">0.15</dap-B-PRI-att-db>
  <dap-A-VRN-att-db type="double">0.12</dap-A-VRN-att-db>
  <dap-B-VRN-att-db type="double">0.15</dap-B-VRN-att-db>
  <dap-A-PRI-rate-db type="double">0.001</dap-A-PRI-rate-db>
 


Adjusted values
Code: Select all
<dap-A-PRI-rot-rate type="double">2.0</dap-A-PRI-rot-rate>
  <dap-B-PRI-rot-rate type="double">0.5</dap-B-PRI-rot-rate>
  <dap-A-VRN-rot-rate type="double">0.1</dap-A-VRN-rot-rate>
  <dap-B-VRN-rot-rate type="double">0.05</dap-B-VRN-rot-rate>
  <dap-A-PRI-att-db type="double">0.10</dap-A-PRI-att-db>
  <dap-B-PRI-att-db type="double">0.10</dap-B-PRI-att-db>
  <dap-A-VRN-att-db type="double">0.12</dap-A-VRN-att-db>
  <dap-B-VRN-att-db type="double">0.15</dap-B-VRN-att-db>
  <dap-A-PRI-rate-db type="double">0.07</dap-A-PRI-rate-db>





pushed some fixes to Eileen


Nice, need to get back a bit in Orbit to test the last commits

I should push the autolanding thing next week. Mainly ironing now.
I added a runway slope correction factor for the final flare to avoid too much dispersions when the runway is not flat (Mainly Vandenberg and Easter Island with a slope around 0.5°).

I am quite happy about the whole thing now. It does work well through a wide range of runways, atmospheric conditions, and Aim Point / Outer glide slope path (18/20).

15 kts X-wind in Easter Island sloped runway 10.
On the spot (2000 feet from runway threshold) and almost on targeted speed (195 kts).

Image
GinGin
 
Posts: 1580
Joined: Wed Jul 05, 2017 11:41 am
Location: Paris
Callsign: Gingin

Re: Space Shuttle - Development

Postby Thorsten » Sat Jun 12, 2021 6:58 am

So now the last thing we actually needed to fly manual is also automated. :D Should we install a coffee-machine on the flightdeck? Or some console game? Crew's goona be lazy...
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Space Shuttle - Development

Postby GinGin » Sat Jun 12, 2021 8:32 am

Thorsten wrote in Sat Jun 12, 2021 6:58 am:Crew's goona be lazy...


Actually , automatic landing ( in aviation or elsewhere) is more demanding than a manual one. Active Monitoring and a deep understanding of the logic are required for a quick take over in case of troubles.

I guess we need now to implement some ap actuator failure to force them out of the laziness :mrgreen:
It might be interesting during the dynamic 1.3 gish flare to have an ap disconnection
GinGin
 
Posts: 1580
Joined: Wed Jul 05, 2017 11:41 am
Location: Paris
Callsign: Gingin

Re: Space Shuttle - Development

Postby amalahama » Sat Jun 12, 2021 8:40 am

The real shuttle had autolanding, didn't it? I recall reading somewhere that it existed, but it was never used, so no feedback on how it behaved IRL.
amalahama
 
Posts: 149
Joined: Mon Mar 28, 2016 10:54 am

Re: Space Shuttle - Development

Postby GinGin » Sat Jun 12, 2021 10:20 am

amalahama wrote in Sat Jun 12, 2021 8:40 am:I recall reading somewhere that it existed, but it was never used, so no feedback on how it behaved IRL.


Yes, it has been developed since 1975.
It was tested during first test flights . So there are feedbacks on it and some papers about logic equations and gains.
That why I implemented it and why it works that well. Cleverer NASA people did the job before :mrgreen:
GinGin
 
Posts: 1580
Joined: Wed Jul 05, 2017 11:41 am
Location: Paris
Callsign: Gingin

Re: Space Shuttle - Development

Postby eatdirt » Sat Jun 12, 2021 11:02 pm

Or some console game? Crew's goona be lazy...


Let's destroy Gingin's work with some failure scenario then :)

And even without, I perfectly remember the state of my state vector after 4 days in space :oops:

@Wayne, I dunno how much progress you have made on the RMS view, but I suddenly realized that the deck views of the MP-carrier Vinson are doing exactly what we want! Superimposing some info, green cathodic tube color, perfect! I'll have a look to the code.
eatdirt
 
Posts: 1012
Joined: Wed Aug 15, 2018 3:06 pm

Re: Space Shuttle - Development

Postby eatdirt » Tue Jun 29, 2021 10:45 pm

I am trying to fly a MECO manually, throttling down to maintain low gs, the lever controlled by the joystick works like a charm. But, If I am late by a fraction of second compared to the expected AUTO MECO, I am exploding.
By the sound of it, the explosion follows the sound of the RCS firing; I am wondering if the RCS stabilization does not systematically kick in at a given VI, independently of whether the engine are still actually running?
eatdirt
 
Posts: 1012
Joined: Wed Aug 15, 2018 3:06 pm

Re: Space Shuttle - Development

Postby wlbragg » Tue Jun 29, 2021 10:50 pm

@Wayne, I dunno how much progress you have made on the RMS view, but I suddenly realized that the deck views of the MP-carrier Vinson are doing exactly what we want! Superimposing some info, green cathodic tube color, perfect! I'll have a look to the code

Great, I kind of set it aside as it was not working consistently and I didn't know how to fix it.
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7574
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

Re: Space Shuttle - Development

Postby Thorsten » Wed Jun 30, 2021 7:54 am

By the sound of it, the explosion follows the sound of the RCS firing;


I'd suggest to check why you're exploding, aka do 'limits' to 'soft', the corresponding message stream to 'active' and the on-screen message will tell you what limit you violated without actually killing you.



I am wondering if the RCS stabilization does not systematically kick in at a given VI, independently of whether the engine are still actually running?


No, it does not, it requires MECO confirmed, which is either auto-commanded MECO or all three cutoff buttons depressed (in case you can't do that because they're broken, you need to manually transit to OPS 104).
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

PreviousNext

Return to Spaceflight

Who is online

Users browsing this forum: No registered users and 1 guest