Space Shuttle

[Thorsten]

How is the RMS intended to work? Can I use my joystick to move the end effector? I'm using the direct drive but it's super low effective. Mode selected is ORB UNL, in which I guess I can control X,Y,Z position in body axis with the hand controller.

I don't have a joystick, so I tested this with the keyboard and mouse only, but yes, if you're outside the software stop region of the joints, the flight control device should be controlling the end effector (just make sure the Shuttle DAP is an an inertial attitude hold...).

Or, if you're lazy, you just punch in the target coordinates/attitude and let the automatic control routines drive the RMS arm.

By the way, enabling the CCTV would be a fantastic plus for RMS handling.

The patch which would enable that seems to have vanished into some nirvana - I don't know whether it's been worked on still, whether it's reviewed - all I know that it's not been committed so far

[amalahama]

I'm pretty sure I'm doing something wrong, but still no joy on making RMS work manually. I followed the manual closely this time, I brought RMS out of the soft limits using the direct drive, I executed the automatic sequence and it works but... when I select ORB UNL, press enter and move the joystick... nothing happens. I tried to change from RHS to THS to see if that makes any difference (pressing m key) but a lady keeps reminding me that the action is not allowed... (it's possible only to switch on pilot station it seems...). By the way, after the automatic sequence is over, I also tried to switch back to SINGLE and move it manually using direct drive and for some reason didn't work either.

Regards

[Thorsten]

It seems you're right, for some reason the drive mode is not set - I'll have a look.

[Hooray]

By the way, enabling the CCTV would be a fantastic plus for RMS handling.

The patch which would enable that seems to have vanished into some nirvana - I don't know whether it's been worked on still, whether it's reviewed - all I know that it's not been committed so far

If you are referring to Icecode GL's work that is based on F-JJTH original patch - it's actually working. Stuart offered to help with the review/integration, and getting this committed.
Admittedly, all of us were busy with other things at the time.

In the meantime, a few other folks started using this already by patching their own builds.
More recently, I've been in touch with TheTom asking him if he's currently around to help with getting this integrated in the next few months.

I've forwarded the patch to cyrfer, who asked for it - as well as offering his help with extending this - so if in doubt, I'd suggest to get in touch with him (that is, if the feature should not all of a sudden show up in the simgear commit logs).

That being said, the patch itself is actually rather simple - as long as your aircraft (spacecraft) has custom views that you want to show up on such a MFD, it will work "as is" - because all that you are essentially doing is adding a new canvas "view-cam" element to the canvas, and telling it the view-number to show.


http://wiki.flightgear.org/Howto:Canvas ... ra_Element

[Thorsten]

In the meantime, a few other folks started using this already by patching their own builds.

That's the one, yes.

I won't include this in the Shuttle as long as the patch is not in a release, so this ain't helping us so much at the moment, but thanks for the update.

[Hooray]

right, that makes sense - I wasn't suggesting that you'd prepare anything.
Like I said, from an fgdata/fgaddon integration standpoint, all that is needed for this to work is a dedicated "RMS" specific view for the view-manager, and a button/switch to enable to the RMS mode.
Someone who knows how to view a raster image via the MFD screen, would also be able to update a property and the view-number, everything else is handled by the C++ code.

[Thorsten]

I'm pretty sure I'm doing something wrong, but still no joy on making RMS work manually.

If you pull from the devel repository, I just pushed a fix.

I haven't checked all eventualities yet (there's the GUI, the 3d cockpit controls and the software override controls on SPEC 95 all of which are supposed to play nice), but at least using cockpit controls and 'm' to switch from translation to rotation I was able to control the RMS arm properly.

This one frankly baffles me - the only explanation I have how this slipped by testing is that at some point we reverted one commit too much and ended up never restoring the functionality.

[wlbragg]

In the meantime, a few other folks started using this already by patching their own builds.
I've forwarded the patch to cyrfer, who asked for it

Any chance you could forward this to me so I can work with it. I've been interested in this since its conception. Maybe I can get a head-start on a SpaceShuttle implementation.

[amalahama]

If you pull from the devel repository, I just pushed a fix.

It works like a charm now, thanks! I only checked selecting ORB UNL with cockpit controls, not PDRS override though.

Question: Is the 3D cockpit model UV unwrap available in any Shuttle folder? I would like to experiment a bit with cockpit textures

Regards!

[wlbragg]

Is the 3D cockpit model UV unwrap available in any Shuttle folder?

There really is no UV unwrap. The model interior is comprised of two meshes and two texture sheets.
cockpit-ste5.blend and fwd-cockpit-text-map-x.xcf
cockpit-detailed.blend and aft-cockpit-text-map-x.xcf

Plus there is some shader magic to give some grain to some of the surfaces.

[Thorsten]

Well, I guess the cockpit blend files are what you need - at least in the uv-editor of blender I can see how it's all mapped, and the files Wayne indicated are the master resources from which the cockpit visuals are derived, so they're the entry point for any official changes.

Some more detail in parts of the cockpit would not be a bad idea - though I suspect we need a third texture sheet for the job...

[Octal450]

Hi Thorsten,
Did you correct the color of the FDAI yet? I am always confused

Kind Regards,
Josh

[Thorsten]

No, adding proper orbital targeting was higher in the priority list...

But to ease your confusion - sky in space outside: black, current ADI representation of sky: black

[Octal450]

Makes sense

I did get that it was backwards, but especially in reentry, I get confused.

Kind Regards,
Josh

[wlbragg]

suspect we need a third texture sheet for the job...

Or a professional modeler needs to unwrap the model and completely re-organize the texture files. From my limited knowledge of modeling I think if this had been organized and optimized from the start it may have been enough room. It was too far along at the point I started adding detail and I was too inexperienced in modeling to have attempted to start over, even though that would have been the best time to start over.
Even without an "unwrapping" there is still room for improvement in the base textures, but the current resolution (space) restricts a lot of the potential improvements.
One needs to know that any change or rework requires compliance with the method we use in the creation of light maps, ie: no overlapping objects. Not to mention some changes would require the generation of new light maps. So there is a pain to gain element involved.
I use the "Draw other objects" in the UV editor portion of Blender to make a pseudo UV map. There may be one of these saved and added to the Gimp file as a reference overlay. But it would probably not portray the most current work to the texture sheets.