Necessary change: Unmanned recovery option

[Daniel Nazar]

It seems like the best idea if we're to continue using the shuttle is
to make sure, when possible, that it puts itself in an orbit where it
can dock with the ISS if there is damage detected to the re-entry
protection system, and the astronauts can live off the remaining
resources in the shuttle and the ISS until we can get up either Soyuz
capsules or another shuttle to bring them down. However, the one
problem with this type of idea is... what do we do with the damaged
shuttle?

It might be possible to attempt an on-orbit repair, but such a repair
couldn't be guaranteed to be 100% workable, so it seems too risky to
have pilots try to bring it down, as they'd be seriously risking their
lives. And with only three remaining shuttles, they're too valuable
to just discard in orbit and leave to burn up and fall into the
Pacific Ocean.

I suggest the shuttles be refitted to allow them to make an unmanned
landing. This shouldn't be at all difficult; from what I understand,
the shuttle is already capable of landing itself via onboard computer,
with the exception of two problems, the initial undocking from the
ISS, and the landing gear. The landing gear problem is artificial, as
it's possible to have the computer lower the landing gear, and the
only reason this isn't currently done is protests from the astronaut
corps that they would become irrelevant if the shuttle could land
itself entirely; it should be a very simple issue to add computer
control of the landing gear into the shuttle system. (The Russian
Buran shuttle, designed at the same time as our own, was able to
perform landings entirely autonomously, and did so once, conducting an
entire flight without crew.)

If it's also possible to set up the computers so that the shuttle
could reliably undock from the ISS without a pilot aboard, then it
would be possible to have the damaged (and possibly repaired-in-orbit)
shuttle land itself unmanned, thus posing no danger to the crew by
allowing them to be recovered by safer means and still allowing the
shuttle to be recovered seperately, examined and dissected for
evidence of the problem, and hopefully repaired and returned to
service, without posing any threat to human life.

It would be best in this instance to limit the recovery landing sites
to Edwards because of the large landing area available at and around
the designated landing strip (the reasons it was used for the first
shuttle landings in the first place) and also so that the shuttle
would fall harmlessly into the Pacific if it is still damaged beyond
recovery and broke up during descent, without shedding debris on a
populated area. I find it unlikely that the shuttle would make it
through descent phase and then suffer a breakdown and fall onto
populated California during the very short time it passes over such,
but still, if this is deemed too much of a risk to human life, the
damaged shuttle could be diverted to an even more isolated landing
site, such as Johnston Island in the Pacific, which is not only
isolated and allows the shuttle to land without passing over any major
populated areas, but is also a military site with the capacity to deal
with hazardous chemicals and thus seems more likely to be able to
handle the landing of a damaged shuttle, considering the threat of
hydrazine exposure on or after landing.

A short summary:

Before the shuttle is returned to service, funding should be applied
to remove the artificial limitation that prevents the shuttle from
landing autonomously. This way, if a shuttle were damaged, it could
still be recovered without having crew aboard that would be endangered
by the damage. Considering both the monetary and the
political/historical value of the shuttle, the small amount of money
it would take to ensure unmanned recovery is possible seems more than
worth it, as it would give us the benefit of potentially bringing back
a damaged shuttle without risking another tragic loss of human life.

[Jorge R. Frank]

(Daniel Nazar) wrote in
om:

> It seems like the best idea if we're to continue using the shuttle is
> to make sure, when possible, that it puts itself in an orbit where it
> can dock with the ISS

Effectively, this means only flights to ISS, period.

> I suggest the shuttles be refitted to allow them to make an unmanned
> landing. This shouldn't be at all difficult; from what I understand,
> the shuttle is already capable of landing itself via onboard computer,
> with the exception of two problems, the initial undocking from the
> ISS, and the landing gear. The landing gear problem is artificial, as
> it's possible to have the computer lower the landing gear

Umm, no, it's not - not without hardware and software upgrades. There is no
command path from the computers to the gear, and no software logic in the
computers to send the command.

> If it's also possible to set up the computers so that the shuttle
> could reliably undock from the ISS without a pilot aboard

No computers needed for this - the departing crew simply sets all the
cockpit switches in the proper positions (APU(s) on, OMS engines in
ARM/PRESS with the helium press/vapor isol valves open, APDS powered up
with circuit protection off, etc). The one sticking point is pressing the
actual UNDOCKING pushbutton, but the MMACS guys may have a workaround for
that to allow the signal to be sent from ISS. The undocking would be
performed with the orbiter on the plus or minus Rbar, to take advantage of
orbital mechanics to increase the separation rate. After undocking, the
ground can uplink the deorbit burn targets and also uplink (DEU-equivalent)
all the keyboard entries the crew would have made, like maneuvering to the
deorbit burn attitude, EXEC'ing the deorbit burn, and maneuvering to EI
attitude.

> Before the shuttle is returned to service, funding should be applied
> to remove the artificial limitation that prevents the shuttle from
> landing autonomously. This way, if a shuttle were damaged, it could
> still be recovered without having crew aboard that would be endangered
> by the damage.

As stated before, it is not just removing a limitation; it is adding
command paths (preferably multiple redundant command paths to prevent
inadvertant gear lowering) and software logic. Capability for safe orbiter
disposal is under development and should be ready for return-to-flight, but
unmanned intact return capability will have to wait until later.

--
JRF

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

[Jan C. Vorbrüggen]

> Umm, no, it's not - not without hardware and software upgrades. There is no
> command path from the computers to the gear, and no software logic in the
> computers to send the command.

So there is actually seperate wiring going from the cockpit switch to the
actuators in the two gears? So the shuttle isn't 100% fly-by-wire, as we
were lead to believe 8-)...

Does this also apply to the deployment of the air data probes?

Jan

[Eric Pederson]

"Jorge R. Frank" wrote:
>
> (Daniel Nazar) wrote in
> om:
>
> > It seems like the best idea if we're to continue using the shuttle is
> > to make sure, when possible, that it puts itself in an orbit where it
> > can dock with the ISS
>
> Effectively, this means only flights to ISS, period.
>
> > I suggest the shuttles be refitted to allow them to make an unmanned
> > landing. This shouldn't be at all difficult; from what I understand,
> > the shuttle is already capable of landing itself via onboard computer,
> > with the exception of two problems, the initial undocking from the
> > ISS, and the landing gear. The landing gear problem is artificial, as
> > it's possible to have the computer lower the landing gear
>
> Umm, no, it's not - not without hardware and software upgrades. There is no
> command path from the computers to the gear, and no software logic in the
> computers to send the command.
>
> > If it's also possible to set up the computers so that the shuttle
> > could reliably undock from the ISS without a pilot aboard
>
> No computers needed for this - the departing crew simply sets all the
> cockpit switches in the proper positions (APU(s) on, OMS engines in
> ARM/PRESS with the helium press/vapor isol valves open, APDS powered up
> with circuit protection off, etc). The one sticking point is pressing the
> actual UNDOCKING pushbutton, but the MMACS guys may have a workaround for
> that to allow the signal to be sent from ISS. The undocking would be
> performed with the orbiter on the plus or minus Rbar, to take advantage of
> orbital mechanics to increase the separation rate. After undocking, the
> ground can uplink the deorbit burn targets and also uplink (DEU-equivalent)
> all the keyboard entries the crew would have made, like maneuvering to the
> deorbit burn attitude, EXEC'ing the deorbit burn, and maneuvering to EI
> attitude.
>
> > Before the shuttle is returned to service, funding should be applied
> > to remove the artificial limitation that prevents the shuttle from
> > landing autonomously. This way, if a shuttle were damaged, it could
> > still be recovered without having crew aboard that would be endangered
> > by the damage.
>
> As stated before, it is not just removing a limitation; it is adding
> command paths (preferably multiple redundant command paths to prevent
> inadvertant gear lowering) and software logic. Capability for safe orbiter
> disposal is under development and should be ready for return-to-flight, but
> unmanned intact return capability will have to wait until later.
>

Would a separate processor and relay package, only plugged into the
system by the crew for this purpose be an option? This would avoid
the possiblity of uncommanded deployment under normal conditions, since
there would be nothing to to cause it.


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

[Dosco Jones]

"Michael R. Grabois ... change $ to "s"" > wrote
in message ...
> On Wed, 09 Jul 2003 11:25:19 +0200, Jan C. Vorbrüggen
> > wrote:
>
> > > Umm, no, it's not - not without hardware and software upgrades. There
is no
> >> command path from the computers to the gear, and no software logic in
the
> >> computers to send the command.
> >
> >So there is actually seperate wiring going from the cockpit switch to the
> >actuators in the two gears? So the shuttle isn't 100% fly-by-wire, as we
> >were lead to believe 8-)...
>
> No, I think it's more like when you press the button, stuff happens and a
valve
> opens. The valve allows hydraulic fluid to go down some lines, and the
pressure
> in those lines moves the actuators.
>
> If the hydraulic system is down for whatever reason, the pyros will cause
the
> actuators to move.


The hydraulics simply unlock the gear for deployment. Gravity does the
rest. There are back-up pyro charges to force the gear down if they get
stuck.

Dosco

[Steve Wachowski]

"Dosco Jones" > wrote in message
thlink.net...
> The hydraulics simply unlock the gear for deployment. Gravity does the
> rest. There are back-up pyro charges to force the gear down if they get
> stuck.

That's not quite right either. The pyros fire to open the uplock hooks if
hydraulic system 1 fails to do it. Gravity, bungee springs and airflow do
the rest.
Look here:
http://www.spaceflight.nasa.gov/shuttle/reference/shutref/orbiter/lgear/overview.html

Taken from this page:
http://www.spaceflight.nasa.gov/shuttle/reference/shutref/orbiter/

--
Steve Wachowski
KSC OPF3 Technician
The opinions above are mine and mine alone.
I do not represent NASA or my employer.

[Michael R. Grabois ... change $ to \s\]

On Thu, 10 Jul 2003 16:45:35 GMT, "Dosco Jones" > wrote:

>
>The hydraulics simply unlock the gear for deployment. Gravity does the
>rest.

Yes and yes.

>There are back-up pyro charges to force the gear down if they get
>stuck.

No. The pyros will fire if the gear is sensed to still be up one second after
the button is pushed. It's the backup in case the hydraulics can't get to where
it's supposed to go for whatever reason (it's only hyd system 1 from APU 1, and
there are a handful of electrical buses that if they fail can cause the valve
to fail closed).

[Daniel Nazar]

"Jorge R. Frank" > wrote in message >...
> (Daniel Nazar) wrote in
> om:
>
> > It seems like the best idea if we're to continue using the shuttle is
> > to make sure, when possible, that it puts itself in an orbit where it
> > can dock with the ISS
>
> Effectively, this means only flights to ISS, period.
>

Well, this is just setup, and irrelevant to the main point I was
making. Assuming we don't go to the ISS, that we go to an alternate
orbit, to service the Hubble or something, and a shuttle becomes
stranded, then the crew is recoverable via another shuttle or
spacecraft launch instead of flights to the ISS. But either way, the
end result is an abandoned shuttle, which was the point I was trying
to get to.

> > I suggest the shuttles be refitted to allow them to make an unmanned
> > landing. This shouldn't be at all difficult; from what I understand,
> > the shuttle is already capable of landing itself via onboard computer,
> > with the exception of two problems, the initial undocking from the
> > ISS, and the landing gear. The landing gear problem is artificial, as
> > it's possible to have the computer lower the landing gear
>
> Umm, no, it's not - not without hardware and software upgrades. There is no
> command path from the computers to the gear, and no software logic in the
> computers to send the command.

Well, I didn't mean to state that the shuttle is currently capable of
this, since it isn't--however, the hardware and software that would
need added are really minimal. I mean, you only need to really add
one physical switch to initiate the gear's hydraulic/gravity-powered
drop system, and then the gear does the rest itself. So you need one
SPST (on/off) switch built in, and wired to the computer, and enough
code added into the computer to be able to turn one switch on--it
doesn't even have to turn the switch off again once it's triggered,
since the gear won't be retracted again by the computer. You're
talking about adding enough code to inititate a single extra
switch-flip at NASA's command. This cannot possibly be a very
difficult upgrade.

In other words, while the shuttle can't do this now, it should be VERY
easy to make the shuttle do this. Hell, I wonder if it'd be possible
to build a switch that worked without requiring new computer
code--say, a switch that was wired in to monitor the computer's
already-given output on altitude/height from runway, and automatically
throw itself at the right time without the computer having to send any
new commands for this switch to work. That's a more complicated
switch, but it wouldn't be a criticality switch since even if it
didn't function it wouldn't endanger the crew (what with it being used
only on unmanned approaches) and, with this type of maneuver limited
to very open-area runways like Edwards, wouldn't endanger anyone on
the ground either. That's a more complicated approach, but it means
no tampering with the computers themselves, and since the switch
doesn't have to be criticality reliable, it could probably be
engineered much faster than by having to go back and revise the
shuttle's computer.

And the concept of "orbiter disposal" that you mention is exactly what
I'm objecting to--by adding a single extra switch into the shuttle and
wiring that single switch into the computer either so the computer
throws it or it has a monitoring component that throws it
automatically when the shuttle reaches the proper altitude, we
wouldn't have to ever worry about 'disposing' of an orbiter, making
recovery possible even without endangering a crew.

[Jorge R. Frank]

(Daniel Nazar) wrote in
m:

> "Jorge R. Frank" > wrote in message
> >...
>> (Daniel Nazar) wrote in
>> om:
>>
>> > It seems like the best idea if we're to continue using the shuttle
>> > is to make sure, when possible, that it puts itself in an orbit
>> > where it can dock with the ISS
>>
>> Effectively, this means only flights to ISS, period.
>
> Well, this is just setup, and irrelevant to the main point I was
> making. Assuming we don't go to the ISS, that we go to an alternate
> orbit, to service the Hubble or something, and a shuttle becomes
> stranded, then the crew is recoverable via another shuttle or
> spacecraft launch instead of flights to the ISS. But either way, the
> end result is an abandoned shuttle, which was the point I was trying
> to get to.

Well, why didn't you say so in the first place? :-)

>> > I suggest the shuttles be refitted to allow them to make an
>> > unmanned landing. This shouldn't be at all difficult; from what I
>> > understand, the shuttle is already capable of landing itself via
>> > onboard computer, with the exception of two problems, the initial
>> > undocking from the ISS, and the landing gear. The landing gear
>> > problem is artificial, as it's possible to have the computer lower
>> > the landing gear
>>
>> Umm, no, it's not - not without hardware and software upgrades. There
>> is no command path from the computers to the gear, and no software
>> logic in the computers to send the command.
>
> Well, I didn't mean to state that the shuttle is currently capable of
> this, since it isn't

You really have this problem with expressing yourself clearly, don't you...
:-)

> --however, the hardware and software that would
> need added are really minimal.

> This cannot possibly be a very
> difficult upgrade.

I take it you've never seen NASA's shuttle software upgrade process. There
really are *no* trivial upgrades, but I agree that in the grand scheme of
things, this is a fairly small one.

> And the concept of "orbiter disposal" that you mention is exactly what
> I'm objecting to--by adding a single extra switch into the shuttle and
> wiring that single switch into the computer either so the computer
> throws it or it has a monitoring component that throws it
> automatically when the shuttle reaches the proper altitude, we
> wouldn't have to ever worry about 'disposing' of an orbiter, making
> recovery possible even without endangering a crew.

Oh, I'm not saying that intact unmanned return is impossible, or won't
happen. Just that it won't happen before return-to-flight. Probably not
even the first software upgrade *after* return-to-flight - that upgrade
(OI-30) is already "closed". But it could happen on the next one.

--
JRF

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