Space Shuttle - Development

[wlbragg]

May be temporarily, just for the time to have a canvas end effector camera (woo, that would be cool!).

I can't get this out of my head. There are other options to simulate this if a true canvas camera is not yet feasible, but I have to have the xyz position numbers and orientation of both the end effector wrist and the object.

If you grab with the wrong roll of the end effector

Can we compute, even marginally, the difference between the roll of the end effector and the object were grappling?

I did notice it looked like we only look at x/y/z position for proximity to attach, is that right?
But "orientation" can be almost anything?

[eatdirt]

Code: Select all

I have to have the xyz position numbers and orientation of both the end effector wrist and the object.

That's certainly "possible", but getting payload orientation in the frame of end effector sounds like quite some maths, I am not sure they're all there already. Thorsten knows.

Thinking about it, a very easy way to have the same information would be to have an additional view, sitting on the end effector and looking where it points to (the end effector x,y,z and attitude are calculated, maybe available as props as well). Possibly with a fixed field of view, and some "hud" lines mimicking the pattern of the original camera? In other words, let's OpenGL do the complicated calculations

[wlbragg]

a very easy way to have the same information would be to have an additional view,

Hum, that's food for thought.

[Thorsten]

That's certainly "possible", but getting payload orientation in the frame of end effector sounds like quite some maths, I am not sure they're all there already. Thorsten knows.

Okay - if we can settle on not using the word 'simple' to characterize the problem let me share my thoughts so far:

We could - potentially - require (within tolerance) agreement in pitch, yaw and roll when grabbing. This is somewhat complicated, but the reverse problem (setting the right angles when releasing) is solved.

Of course the real issue when doing this are - once again - the Euler singularities, and in this case we have a whopping two of them in the game - the effector can be singular in its own coordinate system and it can be singular after rotating to the LVLH coordinate system (or whatever system we grab in, could also be inertial). That... probably means we have not only the two poles of the sphere of potential orientation cut out of what the numerics does, but also two rings which move dependent on relative orientation.

Basically it sounds like a recipe to create the next series of complaints and bug reports.

You'll quickly see where this is going once you start storing offset angles and hence have a third coordinate rotation in the game - which also brings its own Euler singularity.

So my impression is that this rapidly sounds like a really bad idea, and that - rather than comparing angles, what we actually need to propagate and compare is triplets of unit vectors - they're more stable (like the launch DAP does the initial roll right in the Euler singularity - how does it cope? It just poses a condition for the tail fin pointing vector rather than a roll angle)

And... guess what - that's not there. And it's not a small thing to quickly add either. If anyone wants to get working - be my guest, but my priority is the flight dynamics testing /fixing and the manual, I don't consider this a priority.

(Going from there, modeling the whole process is actually fiendishly complicated. Suppose you have a payload latched in the bay, and you attach the arm with a 10 deg offset. That'd work, but the payload won't move to adjust the offset even if you unlatch because it can't penetrate into the bottom of the bay. So the slack in the effector / arm itself will take the load (where is it - in the effector itself, in the structure of the arm, in the joints?) - right till you start lifting, and then the object is no longer held by the bay structure and start to wobble around the attachment point, with the slack in the effector/arm now damping the wobble. So not only would we need a model of the Shuttle structure / payload interaction but also a model for the distribution of slack across the RMS.)

But "orientation" can be almost anything?

It can be literally anything, we impose no condition. Only in grossly incorrect orientations it's kind of hard to find the right spot, because the position tolerance is small.

Thinking about it, a very easy way to have the same information would be to have an additional view,

That'd (probably) be reasonably easy, yes.

[Hooray]

Space Shuttle - Development

On the other hand, we don't have the luxury of having an end effector camera that project the image of the grapple target onto a pattern . So either we forbid any mismatch of roll angle greater than, let's say 10 degrees, and the grabbing becomes even more challenging, or we stay like this and tolerate mismatch? May be temporarily, just for the time to have a canvas end effector camera (woo, that would be cool!).

FWIW, we've been discussing a handful of experimental Canvas/Camera patches over the years, most recently Jules and Fernando took those and updated them to bring them up to par with the latest development in the rendering department (mainly Compositor + CompositeViewer):

https://wiki.flightgear.org/Hackathon_P ... and_Canvas


At the time, the main motivation was to add support for FLIR cameras, payload views and tail cams/gear cameras.
However, there are obviously overlapping requirements - and Jules has been working on an improved view manager implementation which he calls "step view": https://wiki.flightgear.org/StepView

Originally, Jules was looking for use-cases to adopt CompositeViewer: https://wiki.flightgear.org/CompositeViewer_Support
So, if in doubt, please file a dedicated feature request for this sort of thing: https://sourceforge.net/p/flightgear/codetickets/

As you can surely see, many pieces for this are already in place (including the C++ patches to end up with a working aircraft specific view) - at least in composite-viewer mode, it would not seem like that much work to support a corresponding canvas "view" element.

Again, from a core standpoint, it would make sense to raise this question on the devel list, since both, Jules and Fernando are most likely to notice related topics there.
Alternatively, do consider filing a feature request
Based on what we've got already, I don't think it will take very long for this to materialize at this point - primarily thanks to the Compositor and CompositeViewer efforts. But it would obviously help to see how many end-users/aircraft developers express their interest/support in this sort of thing (at some point, the CompositeViewer work was a bit controversial and people seemed hesitant to jump onto that bandwagon - so it would help if the community of fgdata contributors could understand that these two efforts are very much related to anything involving custom Canvas cams, and spread the word accordingly).

In the meantime, even just sharing how you envision the new camera system to work might help shaping Jules' StepView system along the way

[Thorsten]

I've been busy writing some logic to prevent impossible payload selection from happening, for instance we allow both OMS kit and HST - which visually overlap. So there'll soon be a check whether a particular payload slot is already occupied.

Otherwise I think I'll add more switch positions to the saved state - in my test I noticed that the radiator cooling was insufficient to keep the freon temperature low enough, so I deduced that some piece of equipment had to be still on (as a side note, it's kinda cool that we can do that by just observing the temperature...) - it turned out the way I had used the resume state feature the engine controllers were still on and heating my freon.

While pondering the mysteries of thermal control, of course a very simple thing occurred to me as well - the real radiator has a thermostat which lets part of the flow by-pass the radiator if it gets too cool - which is why it doesn't throw a low freon temperature alarm all the time. Which is what I'll add...

[eatdirt]

And it's not a small thing to quickly add either. If anyone wants to get working - be my guest,

It would really be an overkill at this stage, fully agree. Plus, we're already getting the visuals of not perfect alignment at grabbing time. As soon as you're not correctly aligned, you get jumps, it is enough for training! I'll play with an extra view though, that could be useful. Maybe 2 extra views, one for the end effector, the other for the docking collar, I just need to do a bit of reading to check where they are exactly and their field of view.

I had used the resume state feature the engine controllers

I've noticed this indeed (also He isolation valves are not saved, but they don't drain power...). I am amazed you found that by looking at freon temps
Coincidence, but I am exactly at the radiator section in the SCOM, I've discovered that the 4 forward are double sided and can separate from the payload bay doors by 30ish degrees for allowing even more cooling (mission specific), just amazing!

But it would obviously help to see how many end-users/aircraft developers express their interest/support in this sort of thing

Thanks for the pictures Hooray, well, that would be... *perfect*. I'll make a post of the devel list, the real Shuttle has indeed quite a few cameras, if this become standard FG in the future, that will open a lot of possibilities. Especially if the plan is to embed a view!!!!

[eatdirt]

@Wayne.

The auto-docking scenario to ISS is ready. It is there (branch HST)

https://sourceforge.net/u/dirteat/fgspaceshuttledev/ci/HST/tree/

And the procedure that you should respect for having a chance to dock is this one:

1) Start with no fancy option (I assume you have 2020.3.6 and you will respawn above BKIF), something like this (the mdu-groups is to load faster, you can omit it if you need all displays functional)

Code: Select all

fgfs --fg-aircraft=/home/chris/.Aircraft --aircraft=SpaceShuttle-mission --prop:/sim/config/shuttle/mdu-groups=1


2) Once the welcome screen disappears and you're in the Shuttle, press "P" and pause the simulation (ultra-important)

3) Go the the menu Save/Resume -> Scenarios and browse to select "ISS auto-docking", engage it

4) Wait for the 3D model to load, you're still paused (ultra-important). You can check on the external views when the monster appears

5) Once ISS is there, unpause (P again) and watch the Shuttle getting docked into it

Most of the tweaking is in Scenarios/iss-auto-docking.xml, you can adjust by tiny bits if something is not suitable.

PS: I suspect that if you don't start with the exact same conditions above (and in particular above BKIF), the auto-docking may fail, J3 gravity in action

Let me know how it goes!
Cheers,
Chris.

[wlbragg]

Thanks, I'll be checking it out tomorrow.

[wlbragg]

Chris,

Works great and boy does it have me incentivized for a couple things.

I have a question though, what is the deal with the size mismatch and positions of the docking collar of the ISS and the Shuttle, any comments or knowledge about that?

If you can point me to any images of the Shuttle interior at the docking compartment and any closeups of the exterior connection. I haven't looked at any of the docs I have yet, SCOM, etc, so I may already have some visuals. But I wouldn't turn down someone pointing me to some good images.

EDIT:
A quick Google search shows what looks to be the docking collar a good 5 - 10 feet farther to the aft of the bay?
Is the ISS just missing part of the docking mechanism or is incorrectly sized, or both?

Hum, other images, not so much. Different configurations?

Or is that actually a Soyuz capsule we are docking to?

So, is it a bad thing to dock and cause the entire space station to start spinning? You think the gang at NASA are gonna be pissed?

[eatdirt]

So, is it a bad thing to dock and cause the entire space station to start spinning?

Glad it works!
Yea, that is not normal procedure, I did not tune the velocity for a gentle docking, this gives less time for transverse deviations by doing so. So docking hard makes the ISS spinning in FG yes. The proper way is really to dock very very slowly.

For the tolerances in docking and attitude, Thorsten can clarify, but they are pretty narrow yes. l'll dig into some documents about the docking collar, I don't have an answer right now to your questions. I even don't know how ISS gets its attitude and is prevented from spinning after real docking (gyros?).

Edit: Gyros and thrusters (from wikipedia):

Zvezda uses gyroscopes (reaction wheels) and thrusters to turn itself around. Gyroscopes do not require propellant; instead they use electricity to 'store' momentum in flywheels by turning in the opposite direction to the station's movement. The USOS has its own computer-controlled gyroscopes to handle its extra mass. When gyroscopes 'saturate', thrusters are used to cancel out the stored momentum.

Docking mechanism seems to be APAS95: https://en.wikipedia.org/wiki/Androgynous_Peripheral_Attach_System#APAS-95

The mock-up, if it is a good mock-up, these pictures provide some details: https://spaceflightnow.com/shuttle/sts135/120905airlock/.

The SCOM has also nice 3D drawing page 2.19-1!

Posted by gingin a bit later, airlock details are section 6.0 in https://www.nasa.gov/centers/johnson/pdf/383445main_eclss_21002.pdf


From the inside, quite nice, never seen these pictures before: http://www.collectspace.com/news/news-121911b.html

I am linking a few here:

From mid deck towards airlock entrance



From the airlock entrance towards mid deck (we see the door there?)



From the inside, looking to the door that should be opened once docked



Towards the bay, EVA exit:

[Thorsten]

Or is that actually a Soyuz capsule we are docking to?

I fear it is, though it's not terribly obvious in the lowres model...

So, is it a bad thing to dock and cause the entire space station to start spinning?

If you want to just visually be docked to ISS, try setting

/controls/shuttle/ISS/docking-flag

to 1 with the property browser.

***

I've been looking at why we trip the freon loop alarm all the time yesterday, and it turns out to be 'interesting'.

So how the simulation is coded is: The system tries to maintain a constant temperature in the cabin. Now, all running equipment ends up heating the cabin with its power level, so during normal operations we might have some 12 kW of heater in the cabin (I've tested that with the engine controllers on that goes up to 16 kW).

In addition, the sun may or may not warm the cabin, dependent on attitude.

Via the fans and the water loops, the cabin temperature is connected to the freon loop, so we end up heating freon with 12+ kW. That freon ends up being 'hot' and the flow is split into two parts by a controller - part is fed into the radiator assembly, part just by-passes it and keeps its hot temperature. The freon in the radiator is cooled, with an efficiency that depends on freon temperature (the higher the temperature the better it radiates off heat), solar irradiation (if the radiator panels are brightly lit, they cool less) and in principle also earth irradiation - the radiator doesn't dump more than 17900 kW in any case.

So, the freon out temperature is driven by a) how hot is the incoming freon b) how efficient does the radiator operate and c) what fraction of the freon is diverted into the radiator.

In normal operations, we would thus divert about 2/3 of the freon flow into the radiator assembly to get the equivalent of 12 kW cooling which would determine the evaporator out temp. Say that situation corresponds to 275 K.

Now, what I observed is that the valve setting actually changes from about 0.4 to 0.85 during operations, the interior temperature correspondingly oscillates around the 293 K set temperature and can be up to half a degree more or less - and the valve setting leads to a corresponding oscillation in the evap out temperature which I saw ranging from 260 to 282 K.

So it's not the case that the radiator is working too well - the 17900 kW obviously contain some spare for a heat-producing payload and then some more if the panels are raised. The problem is rather that the minimum of the oscillation hits the alarm temperature.

(I assume that there is a low T alarm in the first place because that would indicate that the either the power consumption is really low or the heating power isn't transferred properly to the freon, so the low T alarm isn't a problem with the freon but rather with heat production.)

And the reason for the oscillation of course is that the temperature controller is a P-controller - which struggles with the long lag from valve setting to interior temperature change, hence it does what a P-controller does, it oscillates. I believe what it should be is rather a PD controller to dampen out the oscillations, and then we'd see more the equilibrium behavior.

Now, of course to tune it properly might be a handful of work still - and if someone else would confirm the oscillations in the evaporator temperature that'd be nice. But al least that's why I think we're seeing so much freon alarms.

[eatdirt]

if someone else would confirm the oscillations in the evaporator temperature that'd be nice

Nice findings! You got me trying to understand how many w.h are in one btu...
I am confused about the "evaporator temperature", I suspect you're testing this on orbit with all evaporators off right? EVAP OUT and RAD OUT should give roughtly the same values? Should we monitor freon flow as well?

NB: I think we have also things switching on and off in the electric power consumption (based on fuel cell voltages changes), maybe all these thermal controls for hydraulic etc... Could they be also responsible of these thermal oscillations?

[GinGin]

Very interesting . I will have a look on what you mentionned during next week tests.
Time to go through the eclss workbook

@EatDirt: in FG, rad and evap out output the same value .

[GinGin]

That workbook https://www.nasa.gov/centers/johnson/pdf/383445main_eclss_21002.pdf

is really interesting for the thermal management