Re: Orbiter can save itself!

John Doe <jdoe@xxxxxxx> wrote in news:43ED3C7B.6C92AC01@xxxxxxx:

"Jorge R. Frank" wrote:
Are there any plans to let the orbiter land itself on upcoming
crewed flights

No.

If NASA firms up plans to allow automated/remote control landings,
would such plans then be put in place to test it with humans as backup
?

NASA plans to allow remote control landings only as a last-ditch
contingency to salvage a damaged orbiter, and has no plans for automated
landings at all. So I would guess not.

Mode GNC computers to 303
Take GPS data to navigation
Mode SM computer to 201
APU press/start
Maneuver to entry attitude
Mode GNC computers to 304
Deploy air data probes
Take air data to guidance/control
Arm/deploy landing gear
Arm/deploy drag chute
Close fuel cell reactant valves

Is it correct to state that during re-entry interface when
communications cannot be relied on, the orbiter can function on its
own without any ground commanding ?

That's probably a fair statement. In the above list, the "mode to 304" is
5 minutes before entry interface, and the air data probes aren't deployed
until Mach 5, well after peak heating is over, so comm should be good by
then. And the time to Mach 5 (when the probes are deployed) should be
fairly predictable, so there should be no need to update the command (see
below).

Also, would all parameters needed for the full reentry/landing be
loaded prior to the de-orbit burn so that only very minor commanding
would be needed during actual flight ? or would ground need to upload
updated parameters to the orbiter during actual re-entry ?

Most of the commands would be sent up in advance as timetagged Stored
Program Commands (SPCs). For commands that are normally cued by
conditions other than time, the flight dynamics officer must predict the
time when that condition would be met. For example, the FDO would predict
the time the orbiter would arrive at Mach 5 and the SPC to deploy the air
data probes would be tagged with that time. If the prediction changes
during the entry, the ground would have to uplink another SPC. So the
commands need not be "real-time", but you do need enough good comm in
advance to get the command onboard.

Is there enough bandwidth available for ground to get usable video
feeds to remotely pilot the craft if needed ? Or would Video delay via
TDRS make remote piloting of shuttle unfeasable ? (Is it correct to
state that S-BAND can't provide full live video feed ?)

The latter. But since there is no way for the ground to remotely pilot
the craft, the question of bandwidth is moot.

Are landing gear brakes automatically activated now ? Or is that
something you forgot in the above list ?

I didn't forget it. There is no automatic braking, so the landing will
have to do without them. That's why the drag chute and a nice, long
runway are so important.

I realise that opening up the Shuttle's software to update it is a
huge undertaking with recertification etc. Do any of the changes
necessary to allow the orbiter to land via remote control involve
changing this software ? Or is it just a question of changing a few
parameters so that when a command comes it to deploy data probes, the
existing software knows to send some packet to a certain device on the
bus ?

The two necessary mods have already been done. One mod opens up the "burn
enable" window for the deorbit burn from 15 seconds to 3 minutes, to
allow the ground more time to uplink the "EXEC" keyboard-equivalent
command to start the burn. The other mod allows the entry software to use
the orbit systems management software to operate the antennas. This is
normally done by the backup flight system during entry, but RCO will not
use the BFS.

If they do need to open up pandora's box and change the actual
software, would it then be difficult to have stuff such as the chute,
landing gear etc deploy automatically upon reaching certain conditions
?

Fairly substantial to write, a bitch to certify.

RCO has the capability to close the fuel cell reactant valves, which
will suffice for a quick-and-dirty emergency powerdown.

Still how feasable would it be to bring someone to the hatch and
ingress the orbiter just after it has come to a full stop ? (for
instance, if the person is wearing a adequate suit.). Or is the
surface of the orbiter still too hot to touch, making the opening of
hatch impossible ?

I don't know.

Or if they just do that emergency shut down, does it cause any damage
to the orbiter that would require a fair amount of work to be reset ?

I don't know that either. But since the orbiter in question would already
be damaged and would almost certainly never fly again anyway, I don't
think NASA's all that concerned about additional damage after the bird is
on the ground.

--
JRF

Reply-to address spam-proofed - to reply by E-mail,
check "Organization" (I am not assimilated) and
think one step ahead of IBM.
.