Orbiter can save itself!
Bob Haller
Orbiters may save themselves
2/3/2006 5:18:00 PM
By: Chris Bergin
A new modification kit may be installed into all three of NASA's Space
Shuttle orbiters, enabling them to land back on Earth, unmanned, in the
event of an STS-300 scenario.
Such a modification would give the orbiters a fighting chance of
avoiding a ditching in the Pacific ocean, which is the current option
for a damaged orbiter, while its crew awaits rescue from the "safe
haven" of the International Space Station (ISS).
© NASA
Full Story
Currently, should an orbiter suffer what is deemed to be serious TPS
(Thermal Protection System) damage during ascent, the crew would take
up residence at the ISS until another orbiter could be launched to
bring the crew home.
Such a scenario would see the damaged orbiter being ordered to de-orbit
itself into the ocean - making way for the rescue ship to dock at the
ISS.
While this year's STS-121 is understood to be the only other Shuttle
mission to have an STS-300 support contingency, the option will remain
throughout the remaining launch manifest - bar the Hubble Space
Telescope servicing mission. It is stressed that the chances of such a
mission being required is very unlikely.
There has only been one unmanned return to Earth by a Space Shuttle
orbiter, successfully accomplished by a competitor from the Soviet
Union. The Russian Space Shuttle Buran made the unmanned flight -
including launch - in November 1988. The Shuttle was controlled only by
flight controllers on the ground, but only just managed to land safely,
following major problems during re-entry.
The NASA Shuttle orbiters already have a system that can automatically
perform most re-entry functions, with the pilot only taking over during
the final section of the return to the landing site. At present, some
key tasks - such as lowering the landing gear and deploying a pair of
probes that collect airspeed, altitude and temperature data during the
last moments of flight - require an astronaut at the controls.
'All of those things in a theoretical sense can be automated, but they
are not currently connected to the computer system,' said Space Shuttle
manager Wayne Hale last year.
However, a 'modification kit' is now understood to be available for
installation into the fleet, in time for STS-121.
If NASA decides to have the capability to attempt to bring home a
damaged orbiter, the ship would carry out the same procedure of
re-entry, as she would on a normal return to Earth.
The target landing site would be Edwards Air Force base in California,
with the option of waiving off the attempt should any of the automated
systems fail during re-entry, or if the damage started to affect the
controllability of the orbiter. Should that prove to be the case, the
orbiter would be ditched in the Pacific.
Officially, NASA claim the decision has not yet been made to install
the modification, although acknowledged work is being undertaken.
'The capability currently does not exist for the shuttle to return to
earth uncrewed,' said JSC PAO Kyle Herring, 'but there is some
engineering work ongoing that potentially might provide the technical
capability at some time in the future.'
Live updates for all three orbiters can be seen here:
http://forum.nasaspaceflight.com/category-view.asp?catlock=2
Bob Haller
Why not unman the shuttle converting it to FREIGHT ONLY and finish the
station?
If it wasnt for the risk to astronauts it wouldnt have that 2010 stop
flying date!
So the shuttle is launched unmanned, a ISS soyuz revendous with the
nearby shuttle or a dedicated ISS does the same. leaves a pilot onboard
shuttle who docks to ISS
meanwhile the soyuz returns to iSS!
Unmanned shuttle can run past the 2010 end date and fly till ISS is
complete or we run out of orbiters
the shuttle workforce is kept intact, the stations mdules all get
installed, the international partners are happy, and no life is risked
on the shuttle:)
This is a WIN WIN WIN for EVERYONE, and I support this idea!
Tater Schuld
"Bob Haller" <hal...@aol.com> wrote in message
news:1139074006....@f14g2000cwb.googlegroups.com...
Bob Haller
ummm look at Buran. could fly completly by robot >
Thats my whole point! Untill we get a heavy lifter unmanning the
shuttle is a expensive but functional alternative to NO heavy lift
capacity at all.....
I suggested this a long time ago and other posters here said unmanned
landing would be impossible:(
Now Nasa proposes basically the same thing!
Even if we lose a unmanned orbiter someday because theres no one
onboard to throw a switch, aty least all we lose is cargo.and a museum
piece
Chris Bennetts
> Now to the GREAT PART!
>
> Why not unman the shuttle converting it to FREIGHT ONLY and finish the
> station?
>
> If it wasnt for the risk to astronauts it wouldnt have that 2010 stop
> flying date!
That, and the wish to redirect shuttle funding to the moon mission.
> So the shuttle is launched unmanned, a ISS soyuz revendous with the
> nearby shuttle or a dedicated ISS does the same. leaves a pilot onboard
> shuttle who docks to ISS
Surely someone as risk-averse as yourself would realise that that leaves
the shuttle pilot with only the (unsafe) shuttle as a lifeboat in the
event of docking problems.
Lesser nits: you need at least 2, possibly 4 shuttle crew to perform a
docking; and Shuttle and Soyuz use incompatible docking systems.
> meanwhile the soyuz returns to iSS!
>
> Unmanned shuttle can run past the 2010 end date and fly till ISS is
> complete or we run out of orbiters
>
> the shuttle workforce is kept intact, the stations mdules all get
> installed, the international partners are happy, and no life is risked
> on the shuttle:)
The shuttle workforce will be kept fairly intact (minus some of the
orbiter guys) with the Stick and the SDHLV. The international partners
hardly matter any more. Your plan sees life risked on the equally
dangerous Soyuz instead.
> This is a WIN WIN WIN for EVERYONE, and I support this idea!
You didn't think it through, did you Bob?
--Chris
Bob Haller
> Now to the GREAT PART!
> Why not unman the shuttle converting it to FREIGHT ONLY and finish the
> station?
> If it wasnt for the risk to astronauts it wouldnt have that 2010 stop
> flying date!
That, and the wish to redirect shuttle funding to the moon mission. >
Ahh anyone REALLY believe were going back to the moon? The next
adminstration will have a new agenda....
--------------------------------------------------------------------------------------------------------------------
<> So the shuttle is launched unmanned, a ISS soyuz revendous with the
> nearby shuttle or a dedicated ISS does the same. leaves a pilot onboard
> shuttle who docks to ISS
Surely someone as risk-averse as yourself would realise that that
leaves
the shuttle pilot with only the (unsafe) shuttle as a lifeboat in the
event of docking problems.
Lesser nits: you need at least 2, possibly 4 shuttle crew to perform a
docking; and Shuttle and Soyuz use incompatible docking systems. >
soyuz when being moved from one docking port to another have
essentially no backup:( So we need 2 shuttle crew for docking:) That
leaves one to go back to ISS onboard Soyuz!
-----------------------------------------------------------------------------------------------------------------------
> meanwhile the soyuz returns to iSS!
> Unmanned shuttle can run past the 2010 end date and fly till ISS is
> complete or we run out of orbiters
> the shuttle workforce is kept intact, the stations mdules all get
> installed, the international partners are happy, and no life is risked
> on the shuttle:)
The shuttle workforce will be kept fairly intact (minus some of the
orbiter guys) with the Stick and the SDHLV. The international partners
hardly matter any more. Your plan sees life risked on the equally
dangerous Soyuz instead. >
Well last I heard the shuttle workforce will see a 40% cut, is that
fairly intact? Soyuz has launch boost escape, Shuttle:(
-----------------------------------------------------------------------------------------------------------------------
> This is a WIN WIN WIN for EVERYONE, and I support this idea!
You didn't think it through, did you Bob?
--Chris
As a matter of fact I did. If we dont care about the international
partners then why is that always the reason to keep the shuttle flying?
why fight it, it keeps the shuttle operating, till something better is
actually built, we can fly us crew on soyuz, thats now legal,
it appears to meet the conditions of today, true is costly but with
nasa everything is.
a 5 year delay in CEV may well see private industry filling the
need..........
Reply
Chris Bennetts
Bob Haller wrote:
> Ahh anyone REALLY believe were going back to the moon? The next
> adminstration will have a new agenda....
I do. Probably not for long, but long enough to spend an awful lot of
money on it.
>> Surely someone as risk-averse as yourself would realise that that
>> leaves the shuttle pilot with only the (unsafe) shuttle as a
>> lifeboat in the event of docking problems.
>
> soyuz when being moved from one docking port to another have
> essentially no backup:( So we need 2 shuttle crew for docking:) That
> leaves one to go back to ISS onboard Soyuz!
The comparision with Soyuz is invalid: Soyuz is a "safe" ship, while
your whole plan is based on the premise that the shuttle is not. If you
put crew on a free-flying shuttle, then the shuttle becomes their only
way down in the event of a docking system failure. Surely this is a bad
thing?
>> The shuttle workforce will be kept fairly intact (minus some of the
>> orbiter guys) with the Stick and the SDHLV. The international
>> partners hardly matter any more. Your plan sees life risked on the
>> equally dangerous Soyuz instead.
>
> Well last I heard the shuttle workforce will see a 40% cut, is that
> fairly intact?
Does that include the upstream workforce, or just the KSC guys?
> Soyuz has launch boost escape, Shuttle:(
Soyuz's launch escape system is not a silver bullet. Remember Soyuz 18a?
--Chris
Bob Haller
your whole plan is based on the premise that the shuttle is not. If you
put crew on a free-flying shuttle, then the shuttle becomes their only
way down in the event of a docking system failure. Surely this is a bad
thing? Chris >
No the safety board has required shuttle recertification to fly after
2010. It cant get recertified as a manned vehicle, since it lacks
launch boost escape, so if you remove the people from most or all of
the flight it can continue as a cargo vehicle and finish taking the
remaining modules to the station.
besides a shuttle that couldnt dock could still transfer the crew, 2 at
most to ISS or soyuz.
Dont think inside the box, since the box isnt your friend...
Bob Haller
> fairly intact?
Does that include the upstream workforce, or just the KSC guys?
Overall workforce reduction about 40% to 45% thats all wortkers, not
just kSC.
Since the major cost of shuttle is manpower, you cant cut costs without
cutting people...........
Tater Schuld
> <Bob Haller wrote:
>> Now to the GREAT PART!
>
>> Why not unman the shuttle converting it to FREIGHT ONLY and finish the
>> station?
>> If it wasnt for the risk to astronauts it wouldnt have that 2010 stop
>> flying date!
>
Yeah, but not on NASAs (or Rutans) back
> The next
> adminstration will have a new agenda....
well, Duh! If you want to go, you need to do something about it yourSELF,
and quit expecting others to do it for you.
Chris Bennetts
> < The comparision with Soyuz is invalid: Soyuz is a "safe" ship, while
> your whole plan is based on the premise that the shuttle is not. If you
>
> put crew on a free-flying shuttle, then the shuttle becomes their only
> way down in the event of a docking system failure. Surely this is a bad
>
> thing? Chris >
>
> No the safety board has required shuttle recertification to fly after
> 2010. It cant get recertified as a manned vehicle, since it lacks
> launch boost escape, so if you remove the people from most or all of
> the flight it can continue as a cargo vehicle and finish taking the
> remaining modules to the station.
But if you have a crew on board at all, it will have to be certified
*for those parts of the flight*, including adequate plans for
contingencies that may arise. Your plan does not deal with those.
> besides a shuttle that couldnt dock could still transfer the crew, 2 at
> most to ISS or soyuz.
Uhh, you want to do prox ops with an unmanned shuttle for the couple of
hours such a transfer would take (including some EVA prep, exiting the
shuttle, and the transfer itself)? Much safer just to ride the shuttle
home...
> Dont think inside the box, since the box isnt your friend...
Being outside the box doesn't automatically make something right.
--Chris
DA
> ummm look at Buran. could fly completly by robot
That's a good point. They say Buran barely avoided collision with one of
the escort jets during landing but that was 20 years ago. There was
probably no processor faster than Intel 286 (if that!) aboard Buran back
then. The orbiter is a fly-by-wire aircraft anyways which makes me think
the conversion should not be such great deal. I mean, would obviously cost
taxpayers couple hundred million dollars, but that's a fraction of the
cost of the lost one. Not even talking about people's lives!
While on the subject: wouldn't you make an automatic landing equipment a
part of your safety gear since the beginning anyways? Say, God forbid,
there was a de-pressurization accident and the crew has escaped to ISS or
even dead - wouldn't you want the bird back on Earth to find out what
happened and maybe even fix it?
--
##-----------------------------------------------##
Delivered via http://www.air-space.us/
The News and Discussions Platform for the Airspace Community
no-spam Web and RSS access to
sci.space.shuttle - 12185 messages and counting!
##-----------------------------------------------##
mma...@my-deja.com
> Such a modification would give the orbiters a fighting chance of
> avoiding a ditching in the Pacific ocean, which is the current option
> for a damaged orbiter, while its crew awaits rescue from the "safe
> haven" of the International Space Station (ISS).
And who's going to authorise bringing a damaged shuttle back to Earth
on computer control and risk having it break up over a populated area?
Is there any approach path to KSC which wouldn't have a significant
risk of dumping wreckage (or the entire shuttle if the re-entry damage
wasn't enough to destroy it but was enough to prevent it landing) into
a populated area? Best I can think of would be bringing it to KSC from
the south over Central America, which still means crossing Florida with
a shuttle which might not want to fly by that point.
Mark
Mika Takala
> Is there any approach path to KSC which wouldn't have a significant
> risk of dumping wreckage (or the entire shuttle if the re-entry damage
> wasn't enough to destroy it but was enough to prevent it landing) into
> a populated area? Best I can think of would be bringing it to KSC from
> the south over Central America, which still means crossing Florida with
> a shuttle which might not want to fly by that point.
>
> Mark
I read from somewhere that automated US shuttle would land on some island in
the pacific ocean and, if landing was successfull, then ferried back to
mainland/KSC. Now, if someone could list the runways with correct specs for
safe shuttle landing? :)
--
Mika Takala
mma...@my-deja.com
> I read from somewhere that automated US shuttle would land on some island in
> the pacific ocean and, if landing was successfull, then ferried back to
> mainland/KSC
Ok, that might work. I'm not sure where the emergency runways are in
the Pacific.
Mark
Jorge R. Frank
@g14g2000cwa.googlegroups.com:
The public risk for entry to each landing site is a function of crossrange,
and NASA can pick the deorbit opportunity with a desired crossrange.
That's somethat a moot point, because NASA has already decided that White
Sands will be the sole landing site for a remote-controlled orbiter. It has
a good combination of low public risk and a runway long enough to allow
safe rollout with neither chutes nor brakes.
--
JRF
Reply-to address spam-proofed - to reply by E-mail,
check "Organization" (I am not assimilated) and
think one step ahead of IBM.
Jorge R. Frank
news:43e926f9$0$28682$a82e...@reader.athenanews.com:
> Say,
> God forbid, there was a de-pressurization accident and the crew has
> escaped to ISS or even dead - wouldn't you want the bird back on Earth
> to find out what happened and maybe even fix it?
In that scenario, there is no possibility of getting the bird back,
automated landing or not, because the orbiter's avionics are air-cooled. If
the cabin depressurizes, the computers overheat and die, and that's the end
of it.
Jorge R. Frank
news:Xns9763BCAD...@216.196.97.131:
> That's somethat a moot point, because NASA has already decided that
"Somewhat", of course. D'oh!
Bob Haller
way faster than people. launch, routine in orbit activities, and
deorbit landing can be all run by remote or computer programs.
this leaves at most docking.
how much will it cost to build a soyuz shuttle docking adapter?
it could go as frieght in cargo bay, then live permanetely at station
till no longer needed.
white sands is a wonderful choice for automated landing.
best of all it keeps the workforce intact, and allows station
completion even beyond 2010
Ten Quidado
<mma...@my-deja.com> wrote in message
news:1139358103.5...@f14g2000cwb.googlegroups.com...
I don't recall any in the Pacific at the moment. Rapa Nui was slated for
TALs from Vandenburg.
Richard Lamb
I got such a hoot from "Space Cowboys"!
"Give me an on-board computer failure", and made it look So easy...
Dr John Stockton
dated Tue, 7 Feb 2006 10:33:44 remote, seen in news:sci.space.shuttle,
mma...@my-deja.com posted :
>
>And who's going to authorise bringing a damaged shuttle back to Earth
>on computer control and risk having it break up over a populated area?
>
>Is there any approach path to KSC which wouldn't have a significant
>risk of dumping wreckage (or the entire shuttle if the re-entry damage
>wasn't enough to destroy it but was enough to prevent it landing) into
>a populated area? Best I can think of would be bringing it to KSC from
>the south over Central America, which still means crossing Florida with
>a shuttle which might not want to fly by that point.
Central America is populated too; but I suppose you don't count
foreigners.
Any big runway on or near the East Coast of any ocean can be a
candidate.
ISTM that the Shuttle should have been designed for full autoland, but
with the connection between computer and landing gear being by an
electric cable or plug, always flown but normally unconnected, and
highly visible in both stowed and fitted positions from flight deck
seating.
Or designed to launch and land with zero crew and up to about 7
passengers, stowed as cargo in individual well-padded capsules.
--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 MIME. ©
Web <URL:http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms & links;
Astro stuff via astron-1.htm, gravity0.htm ; quotings.htm, pascal.htm, etc.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.
snidely
Dr John Stockton wrote:
[...]
> Any big runway on or near the East Coast of any ocean can be a
> candidate.
True, but see Jorge's post from yesterday that says the edict is "White
Sands".
> ISTM that the Shuttle should have been designed for full autoland, but
> with the connection between computer and landing gear being by an
> electric cable or plug, always flown but normally unconnected, and
> highly visible in both stowed and fitted positions from flight deck
> seating.
Jorge has previously posted about the shuttle modifications required to
autoland. Some are software, some are mechanical; I'm not sure of the
status of the implementation of the modifications, though.
/dps
tomcat
Edwards AFB has a nice long runway.
But why is 'autoland' so important. Nice to have. But I have noticed
a 'movement' toward taking the pilot out of the picture. Not good.
A human pilot is flexible and can deal with unpredicted situations. A
pilot can observe and make recommendations. An autoland system for
pilot emergencies makes sense. But capsules can come down intot he
mouths of volcanos or onto the sides of cliffs.
Not to mention the possibility of coming down on top of a blue billed
squater hen that is on the endangered species list.
And, autoland systems sometimes land in the center of runways so that a
really fast landing plane has to plow through the trees into whatever
lies beyond. Normally high tension wires get tangled with the fusalage
because they always encircle runways for some reason I cannot
comprehend.
So, why take the pilot out of the picture. Is it because they get
photographed a lot? Is it because they get hero status while the
engineers are in the shadows?
tomcat
snidely
>[...]
> Edwards AFB has a nice long runway.
See Jorge's post.
> But why is 'autoland' so important. Nice to have. But I have noticed
> a 'movement' toward taking the pilot out of the picture. Not good.
For the Shuttle, it is only being done as an emergency return
procedure. Without crew. That's what this thread is about.
And autolanding airliners is about to become commonplace, from what
people are saying. The crew will still be expected to pay attention,
but the computer will be doing more and more of the work, it seems.
/dps
Bob Haller
occasional screw up and must be overridden
tomcat
The crew had better pay attention. Nothing more scary than a computer
trying to land a plane. I hope the engineers don't pick the center of
the runway . . . again.
You see, supposedly pilots are to land in the center of the runway so
there is no chance of hitting the runway lip at the beginning, much
less the expensive lights with big strong steel poles holding them up.
Pilots, however, know that they can judge the runway lip quite well,
but the possibility of brake failure or a short runway or a hydro plane
situation or any one of a bunch of other possibilities might take them
off the end of the runway.
So, most pilots cheat a little and land just after the runway lip
anyway. It is the best place to land. But engineers read their little
books that say the cernter is best.
Also, GPS isn't perfect. Twenty feet to this side or that and you
might land on the tarmac, or more likely in the grass where drainage
ditches give you a bumpy ride. Well, any landing you walk away from is
a good landing. But, tell that to the maintenance materials people or
the aircraft owners!
In addition, an 'autoland' situation requires the pick of not one, but
one out of several maybe even 3 or 4 possible runways at a given AFB or
airport. Usually there is a 'shorty' runway in the bunch. Engineers
have to be very careful on selecting the 'right' runway.
Yes, autoland is a good idea -- but it won't replace pilots for a long
time yet. For emergencies only. Also, the possibility of rigging the
aircraft for 'drone' landing by ground pilot is pretty easy and
actually a little safer.
The overall truth is we need to begin building spaceplanes Now, not
twenty years from Now. The Shuttle was a great bird despite a couple
of bugs. But that was then and this is now.
tomcat
Jorge R. Frank
@f14g2000cwb.googlegroups.com:
> Dr John Stockton wrote:
> [...]
>> Any big runway on or near the East Coast of any ocean can be a
>> candidate.
>
> True, but see Jorge's post from yesterday that says the edict is "White
> Sands".
I've found at least one reference to a possible upgrade to Vandenberg to
allow it to be used as well. Probably won't happen, though.
>> ISTM that the Shuttle should have been designed for full autoland, but
>> with the connection between computer and landing gear being by an
>> electric cable or plug, always flown but normally unconnected, and
>> highly visible in both stowed and fitted positions from flight deck
>> seating.
>
> Jorge has previously posted about the shuttle modifications required to
> autoland. Some are software, some are mechanical; I'm not sure of the
> status of the implementation of the modifications, though.
The hardware (a 28 foot "spider cable" that runs from the ground command
interface logic controller in the middeck to each of the affected panels
on the flight deck) has been built. Actually two cables, one for flight
and one for testing. The affected switches/pushbuttons are auxiliary
power unit low/norm press and start/run, air data probe deploy, landing
gear arm/down, drag chute arm/deploy, and fuel cell reactant valve
closure.
The software mods (a patch to the entry software that lengthens the
deorbit burn "enable window", and enables antenna management during entry
without the backup flight system) are complete.
Both were tested successfully in the shuttle avionics integration lab
last November.
It's important to understand what this capability is, and even moreso,
what it *isn't*. NASA's term for it, "Remote Controlled Orbiter (RCO)"
tells you a lot. This is not an automated or autonomous capability; it's
a barebones, minimal capability to try to get a damaged vehicle back. It
requires inflight maintenance by the crew to install it and a
considerable amount of ground commanding (and ergo, long periods of good
solid comm) to operate it. No, I take that back - it requires some of the
most elaborately choreographed ground commanding that any spacecraft has
ever seen. It carries a considerable risk of vehicle loss, and therefore
should only be used as a last resort when the vehicle has been declared
unsafe for entry with the crew.
A fully autonomous capability would require more massive
software/hardware upgrades. It simply ain't going to happen before the
fleet retires.
Jan Vorbrüggen
> graphed ground commanding that any spacecraft has ever seen.
Have you run a sim of such an entry yet?
Jan
Jorge R. Frank
news:450bn7F...@individual.net:
> > No, I take that back - it requires some of the most elaborately choreo-
> > graphed ground commanding that any spacecraft has ever seen.
>
> Have you run a sim of such an entry yet?
As I wrote earlier, it's been tested in SAIL. I neglected to add that SAIL
is a simulator.
Jan Vorbrüggen
> is a simulator.
I know SAIL is a simulator - well, in this context; in a previous life, it
would have been the Stanford Artificial Intelligence Lab.
My question was whether you had run a sim of the whole choreography; I had
taken your previous reply to mean that the bits and pieces, in particular
the functionality of that piece of wiring, had been tested, but perhaps not
a complete entry.
Jan
Mika Takala
> what it *isn't*. NASA's term for it, "Remote Controlled Orbiter (RCO)"
> tells you a lot. This is not an automated or autonomous capability; it's
> a barebones, minimal capability to try to get a damaged vehicle back. It
> requires inflight maintenance by the crew to install it and a
> considerable amount of ground commanding (and ergo, long periods of good
> solid comm) to operate it. No, I take that back - it requires some of the
> most elaborately choreographed ground commanding that any spacecraft has
> ever seen. It carries a considerable risk of vehicle loss, and therefore
> should only be used as a last resort when the vehicle has been declared
> unsafe for entry with the crew.
>
> A fully autonomous capability would require more massive
> software/hardware upgrades. It simply ain't going to happen before the
> fleet retires.
By fully autonomous, do you mean that simply uploading deorbit command would
result in a successful landing on the first orbiter-selected time? That can
indeed be impossible in the timeframe available, and very very time critical
remote commanding of orbiter functions need to be made before and after
deorbit burn. But what happens after it?
I've been told that the orbiter could land itself after deorbit burn has
been made & correct entry software started, with the exclusion of the air
data probes, landing gear deployment and chute deployment. Does the remote
controlled orbiter scenario / software involve actual flying, similar to
current CDR/PLT stick flying, or would only those deployments be made
remotely?
--
Mika Takala
Jorge R. Frank
in news:4515liF...@individual.net:
A complete sim of the deorbit, entry, and landing was run in SAIL; the
commanding was done by SAIL test engineers. RCO hasn't been tested in an
integrated sim where a real flight control team would do the commanding,
since (to my knowledge) SAIL can't integrate with the MCC. The SMS can, of
course, but the RCO cable can't be installed there due to the panel wiring
being different from the real vehicles, plus the fact that the GCIL is
simulated in software, rather than having a real hardware GCIL like in
SAIL.
The other part of unmanned orbiter return, the unmanned undocking and
separation from ISS, *has* been tested in an integrated sim, with real
flight control teams doing the commanding. In this case, the hardware mod
("hotwiring" the undock pushbutton) had to be faked, since (again) the mod
procedure would not have worked in the SMS. I think this part has been
tested in SAIL as well but not in the same sim where RCO was tested.
Jorge R. Frank
news:b_NGf.5534$UE2....@reader1.news.jippii.net:
> Does the remote controlled orbiter scenario / software involve actual
> flying, similar to current CDR/PLT stick flying, or would only those
> deployments be made remotely?
The software does the stick flying. The remote commands handle the switch
throws, button presses, and keyboard entries otherwise done by the crew.
John Doe
> The software does the stick flying. The remote commands handle the switch
> throws, button presses, and keyboard entries otherwise done by the crew.
From a software load point of view, can the current orbiter computers
hold all of the software used between de-orbit burn and full stop on
runway, or must the crew unload and load new software at some point
during re-entry ?
Are there any plans to let the orbiter land itself on upcoming crewed
flights (with crew manually deploying landing gear and air data probes)
to really prove the software can autoland the orbiter in real life ?
How much ground control would be needed once de-orit burn has been made
until the shuttle comes to full stop ?
Assuming an empty orbiter doesn't self destruct and lands perfectly.
Would there be any issues with there being nobody inside to turn off
systems before ground crews can open the hatch ?
Could they bring the mobile lounge to the hatch right away after the
shuttle has stopped and use fans to create positive pressure in the
docking collar so that fumes from orbiter wouldn't affect ground workers
entering the shuttle to shut systems before they overheat ?
mma...@my-deja.com
> Central America is populated too; but I suppose you don't count
> foreigners.
At 5km/s you'll be across it _very_ quickly, so the odds of dropping
debris at precisely the right time to hit anyone on the ground during
those few seconds are slim: also, I'd presume that the US government
would be asking them for permission first.
> Any big runway on or near the East Coast of any ocean can be a
> candidate.
Provided the dying shuttle doesn't have to fly near major population
centers along the way.
Mark
snidely
mma...@my-deja.com wrote:
> Dr John Stockton wrote:
> > Central America is populated too; but I suppose you don't count
> > foreigners.
>
> At 5km/s you'll be across it _very_ quickly, so the odds of dropping
> debris at precisely the right time to hit anyone on the ground during
> those few seconds are slim:
If the track crosses Northern Mexico, much of the population should be
avoided, as I understand the distribution outside of a few centers
approaches 0 (Baja and Sonora tend to have a lot of heat and not much
water, making it difficult to farm).
/dps
Jorge R. Frank
> "Jorge R. Frank" wrote:
>> The software does the stick flying. The remote commands handle the
>> switch throws, button presses, and keyboard entries otherwise done by
>> the crew.
>
> From a software load point of view, can the current orbiter computers
> hold all of the software used between de-orbit burn and full stop on
> runway,
Yes, although several mode changes are required.
> Are there any plans to let the orbiter land itself on upcoming crewed
> flights (with crew manually deploying landing gear and air data
> probes) to really prove the software can autoland the orbiter in real
> life ?
No.
> How much ground control would be needed once de-orit burn has been
> made until the shuttle comes to full stop ?
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
> Assuming an empty orbiter doesn't self destruct and lands perfectly.
> Would there be any issues with there being nobody inside to turn off
> systems before ground crews can open the hatch ?
RCO has the capability to close the fuel cell reactant valves, which will
suffice for a quick-and-dirty emergency powerdown.
tomcat
software.
tomcat
John Doe
> > 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 ?
> 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 ?
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 ?
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 ?)
Are landing gear brakes automatically activated now ? Or is that
something you forgot in the above list ?
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 ?
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 ?
> 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 ?
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 ? Or
does it cause any loss of data that NASA would have liked to collect ?
Jorge R. Frank
> "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.
John Doe
> 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.
I would have thought that once the mods are in, they might try them with
a human crew able to take over if the automation doesn't work. Once
tested, NASA would then feel more comfortable (at least from a PR point
of view) about remote "Piloting" the shuttle back to earth.
> 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.
Interesting.
If they were to build a new shuttle today, would current computer
technilogy make it a better solution to automate based on conditions
instead of timer ? Or are there good reasons to by time instead of
conditions ?
> 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.
Are the brakes FWB via the computer ? or are they totally separate with
no possibility of computer activating brakes ?
> 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.
Once NASA announces that shuttles can be remotely de-orbited, won't
there be some pressure to use that at the first sign of trouble ? For
instance, if a few gap fillers stick out or a couple of missing /damaged
tiles in a non critical area, would PR issues put pressure on NASA not
take a risk and keep crew on station and bring shuttle back remotely ?
Jorge R. Frank
> "Jorge R. Frank" wrote:
>> 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.
>
> I would have thought that once the mods are in, they might try them
> with a human crew able to take over if the automation doesn't work.
> Once tested, NASA would then feel more comfortable (at least from a PR
> point of view) about remote "Piloting" the shuttle back to earth.
Once RCO is installed, I don't think a human crew *can* take over. The
photos I've seen show the switch panels *removed* in order to install the
RCO cable, so the switches would no longer be there for the crew to
operate. It's pretty much an either-or proposition: don't install RCO and
do a normal landing with the crew doing the switch throws, or install RCO
and do a remote controlled landing with the RCO cable energizing the
wires where the switches used to be.
Even if RCO were implemented otherwise, I still don't think NASA would
test it with a crew onboard. The only reason why NASA was able to
implement RCO as quickly and cheaply as it did was because RCO didn't
have to be certified safe for a crew. The explicit upfront assumption was
that there would be no crew aboard and that the entry corridor would be
chosen to minimize public risk on the ground. Put a crew onboard and
you're talking about either an expensive, time-consuming certification,
or exposing the crew to a higher risk than a normal entry. I don't see
that happening. I see this as a capability NASA hopes it never has to
use, and only when the choice is between disposing of a damaged orbiter
over the Pacific versus gaining a fighting chance of getting it back.
>> 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.
>
> Interesting.
>
> If they were to build a new shuttle today, would current computer
> technilogy make it a better solution to automate based on conditions
> instead of timer ? Or are there good reasons to by time instead of
> conditions ?
Don't be silly. NASA chose timetagged commands because that's how the
existing SPC capability works, not because they thought timetagged
commands were better. Remember, this is a barebones capability that makes
the absolute minimum changes to the existing orbiter. This is not how
NASA would implement autonomous return were it inclined to do so; it's
more of a clever MacGyver hack.
>> 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.
>
> Are the brakes FWB via the computer ? or are they totally separate
> with no possibility of computer activating brakes ?
I don't know.
>> 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.
>
> Once NASA announces that shuttles can be remotely de-orbited, won't
> there be some pressure to use that at the first sign of trouble ?
I'm sure there will be, from people who don't understand the relative
risks involved.
> For
> instance, if a few gap fillers stick out or a couple of missing
> /damaged tiles in a non critical area, would PR issues put pressure on
> NASA not take a risk and keep crew on station and bring shuttle back
> remotely ?
Safe haven is not a panacea. In the scenarios you mention, safe haven
would likely expose the crew to higher risk, and RCO would increase the
risk of losing the orbiter. You're also putting a rescue crew at risk
with a hurried launch.
And keep this in mind: The maximum safe haven duration runs the ISS
consumables to *zero* waiting for the rescue flight. Safe haven doesn't
just end with the rescue crew taking the stranded crew home; it very
likely ends with the ISS crew abandoning a depleted station. This is
*not* something you want to do if you don't absolutely need to.
Dr John Stockton
, dated Fri, 10 Feb 2006 13:49:34 remote, seen in
news:sci.space.shuttle, mma...@my-deja.com posted :
>Dr John Stockton wrote:
>> Any big runway on or near the East Coast of any ocean can be a
>> candidate.
>
>Provided the dying shuttle doesn't have to fly near major population
>centers along the way.
Major population centres tend to be built on continents rather than on
or in oceans. The East Coast of the Pacific runs from Alaska to Chile.
Shuttle launches go (more or less) Eastbound, and it can only turn
Westwards on the later stages of landing.
If someone got a sign wrong and Shuttle took off Westbound I guess it
might not make orbit. But one day you might see an Israeli shuttle
limping into Idlewild.
mma...@my-deja.com
> Major population centres tend to be built on continents rather than on
> or in oceans. The East Coast of the Pacific runs from Alaska to Chile.
And has plenty of major cities along it. You really want to drop a
shuttle into LA when it goes out of control on the way to Edwards?
Mark
John Doe
> Once RCO is installed, I don't think a human crew *can* take over. The
> photos I've seen show the switch panels *removed* in order to install the
> RCO cable, so the switches would no longer be there for the crew to
> operate.
OK. That explains well why NASA wouldn't try this kit with a crew on board.
For this to work, the RCO kit would have to be field installable, right
? Will they leave one on the station for a crew to install in a shuttle
if necessary, or will every shuttle have its own RCO kit with it at all
times ?
> Don't be silly. NASA chose timetagged commands because that's how the
> existing SPC capability works, not because they thought timetagged
> commands were better.
I was asking about the original design of the shuttle computers, not the
current patch. Were timed commands the only technologically possible
solution back when the shuttle was designed due to computer limitations ?
> I'm sure there will be, from people who don't understand the relative
> risks involved.
What happens if during re-entry, the shuttle looses communications, but
otherwise remains intact ? Would the shuttle still automatically switch
to "glider" mode at some timed event, and try to manage without the air
data probes ? Or would it continue to be in "re-entry interface" mode
and essentially become a controlled ballistic re-entry falling in some
random location ?
From the program point of view, would the "glider" mode be able to cope
without the air data probes, using inertial systems to estimate airspeed
?
Jorge R. Frank
> "Jorge R. Frank" wrote:
>> Once RCO is installed, I don't think a human crew *can* take over.
>> The photos I've seen show the switch panels *removed* in order to
>> install the RCO cable, so the switches would no longer be there for
>> the crew to operate.
>
> OK. That explains well why NASA wouldn't try this kit with a crew on
> board.
>
> For this to work, the RCO kit would have to be field installable,
> right ?
That's the idea. It would be installed by the crew after safe haven is
declared and before the crew egresses the orbiter for the station. For
the SAIL tests, the RCO cable was installed by STS-121 commander Steve
Lindsey.
> Will they leave one on the station for a crew to install in a
> shuttle if necessary, or will every shuttle have its own RCO kit with
> it at all times ?
I think there's only going to be one RCO cable, and it will either rotate
among the orbiters or be left on ISS.
>> Don't be silly. NASA chose timetagged commands because that's how the
>> existing SPC capability works, not because they thought timetagged
>> commands were better.
>
> I was asking about the original design of the shuttle computers, not
> the current patch. Were timed commands the only technologically
> possible solution back when the shuttle was designed due to computer
> limitations ?
I don't know.
>> I'm sure there will be, from people who don't understand the relative
>> risks involved.
>
> What happens if during re-entry, the shuttle looses communications,
> but otherwise remains intact ? Would the shuttle still automatically
> switch to "glider" mode at some timed event, and try to manage without
> the air data probes ? Or would it continue to be in "re-entry
> interface" mode and essentially become a controlled ballistic re-entry
> falling in some random location ?
The former. The guidance software will transition from entry to TAEM to
approach/landing on its own.
> From the program point of view, would the "glider" mode be able to
> cope without the air data probes, using inertial systems to estimate
> airspeed ?
The nav software tries to cope with the lack of air data by deriving it
from the onboard state. How well that works depends on how good the nav
state is, and what the winds are like. It may work, but introduces enough
risk that the ability to deploy the probes was deemed essential for RCO.
tomcat
(I am not assimilated yet either so I have to think one step ahead of
everybody.)
Today, inertial guidance is a little chip that can do miracles. Ring
lasers act as gryos accurately calculating speed and direction changes
regardless of cause. In fact, air data input is just about out of
date. So, inertial guidance will do well for the 'black out' period of
reentry.
GPS, however, is a little better overall since it combines current
location with speed over ground as well as location of the runway to be
used. So, switch back to GPS as soon as possible after 'black out'.
Computers can be programmed to do everything necessary including
applying the brakes on landing. Today, the brakes are anti-lock so
steady pressure is all that is needed. The parachute is deployed by a
pullout knob, but this could be accomplished by a simple piston as
well.
To what extent the Shuttle is fly-by-wire I don't know, but believe
that computers and avionics have been recently upgraded. So, with
fly-by-wire it is just necessary to insure proper inputs with a
separate computer, or multi-tasking program, handling position inputs
from I.G. or G.P.S., calculating the outputs to fly-by-wire based on
the current position vs. the final runway landing.
If the Shuttle's computers aren't capable of handling this then a
little stripped down PC can handle it just fine, feeding the outputs
into the Shuttle computers -- 3 pounds of extra weight, tops.
Countdown timers are almost as old fashioned as the paper tape computer
used during the Apollo Missions. Today, a sophisticated algorithim can
be used in that stripped down PC I mentioned. That should be a little
better than the old paper tape timer.
Boeing (McDonnel Douglas) used some glideslope programs in experimental
aircraft, so check them out. Why reinvent the wheel?
tomcat
Craig Fink
Not much wisdom in doing this as the Shuttle Program comes to a close,
would have been better to do it 20-25 years ago.
How is the Hubble Mission comming?
--
Craig Fink
Courtesy E-Mail Welcome @ WeBe...@GMail.Com
Jorge R. Frank
news:pan.2006.02.12....@GMail.Com:
> Sounds like a lot of fun, but a waste of time and money.
To some extent, yes, but it's a lot less time and a lot less money than a
full-up autonomous capability would have cost. Think of it as a cheap
insurance policy for the remaining orbiters.
> How is the Hubble Mission comming?
The first payload ops working group meetings are being held. A decision to
place the flight on the manifest won't be made unless the OBSS structural
dynamics DTO on STS-121 is successful. That DTO will determine if it's
possible to use the OBSS as an EVA platform for standalone TPS repair.
Dr John Stockton
, dated Sat, 11 Feb 2006 11:58:33 remote, seen in
news:sci.space.shuttle, mma...@my-deja.com posted :
I wrote "Any big runway on or near the East Coast of any ocean can be a
candidate."
Therefore Edwards would be a candidate, if it's on or near the coast.
Actually, it's not on the coast, but AIUI a significant distance inland.
If there's anything important between Edwards and the ocean, considering
the available directions of approach, then Edwards becomes a failed
candidate.
San Diego seems to have a runway close to the ocean; I don't know its
size. Likewise Antofagasta and Callao.
--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 MIME. ©
Web <URL:http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
PAS EXE etc : <URL:http://www.merlyn.demon.co.uk/programs/> - see 00index.htm
Dates - miscdate.htm moredate.htm js-dates.htm pas-time.htm critdate.htm etc.
Bob Haller
John Doe
> candidate."
>
> Therefore Edwards would be a candidate, if it's on or near the coast.
> Actually, it's not on the coast, but AIUI a significant distance inland.
On a planerary scale, Edwards is almost on the coast.
On a re-entry scale, Edwards is what, a minute inland ?
Consider that a damaged orbiter would break up over the pacific, well
before the coast. Consider where Columbia's debris fell versus target
landing area.
If the shuttle makes it to the coast over populated areas, it is because
it is still in one piece and likely won't fall on anybody's head/roof
and reach edwards. Once there, if it crashes or fails de deploy landing
gear, it won't kill anyone.
Jorge R. Frank
> Consider that a damaged orbiter would break up over the pacific, well
> before the coast. Consider where Columbia's debris fell versus target
> landing area.
>
> If the shuttle makes it to the coast over populated areas, it is because
> it is still in one piece and likely won't fall on anybody's head/roof
> and reach edwards. Once there, if it crashes or fails de deploy landing
> gear, it won't kill anyone.
This is a good example of the logical fallacy that the generals call
"fighting the last war" and I like to call "fitting a curve through one
data point."
Just because Columbia broke up at 200 kft doesn't mean that's the only
place an orbiter can be lost during entry. NASA's probabilistic risk
assessments show a highly substantial risk from TAEM on down, which for a
landing at Edwards would likely be over Los Angeles.
mma...@my-deja.com
> in a emergency situation they evacuate the ground track...
I can just see the US government evacuating the whole of LA in order to
try to save a broken shuttle....
Mark