[AR] Re: Flight Controller Features
- From: Henry Spencer <hspencer@xxxxxxxxxxxxx>
- To: "arocket@xxxxxxxxxxxxx" <arocket@xxxxxxxxxxxxx>
- Date: Tue, 12 Jan 2016 17:35:59 -0500 (EST)
On Tue, 12 Jan 2016, Ben Brockert wrote:
Back in the day, attitude was a physical state of an actual mechanical
gyroscope that could be measured at any point.
Or not, as the case might be. In the Apollo LM, for example, the abort
guidance system used strap-down gyros whose output had to be integrated in
software. Moreover, the critical information was not just attitude, but
also velocity and position, and both primary and abort systems had to
integrate *those* mostly in software. Plus little sidelines like
correcting for gyro drift, which was an issue even for stabilized-platform
attitude sensors.
The idea that those computers could be rebooted easily because, well,
after all, they didn't have to remember anything or maintain continuity
for anything important, is sheer ignorance. No, things were not that easy
for software in the old days.
In a modern MEMS/FOG/RLG strapdown system, attitude is just a filtered
integration of data against a starting state. If something goes wrong
that corrupts that attitude information, or a reboot wipes that data,
it's not possible to continue.
True, which means the software must do its best to ensure that such
information does *not* get corrupted or wiped, not permanently. You can
always imagine disastrously bad cases where loss is inevitable, but far
more often, clean recovery is possible, given careful design. Oddly
enough, the techniques that were used back in the old days -- to meet
exactly such requirements -- are still relevant today, with adjustments.
When it's important enough to pay the price, that is, which is a
non-trivial decision.
You could add a bunch of new and mostly useless sensors that can derive
attitude from scratch, or you can proceed with the reasonable plan that
the flight computer can run for a few minutes without rebooting, like
every modern computer in the world.
Or you could write the software so that crucial information in memory
survives a reboot, in case one should happen by surprise -- say, because
you goofed.
Apollo computers could and normally did run for whole missions -- many
days -- without rebooting. The reboots during the Apollo 11 landing were
not due to the computer being unreliable; they were due to a human
oversight that resulted in the computer becoming overloaded, as tasks
stacked up during a complex phase of flight. Are such things really
unthinkable for rocket flights today?
Henry
Other related posts:
