[AR] Re: LEO radiation shielding

  • From: Craig Fink <webegood@xxxxxxxxx>
  • To: arocket@xxxxxxxxxxxxx
  • Date: Sat, 21 Dec 2019 08:39:43 -0800

Hey Uwe, I've found FPGA interesting since their beginning.  When I was
school, the University had an Analog Computer for control systems
development of Flight Control systems, have these Analog Algorithms made it
into the FPGA? Or has it remain more digital where the FPGA are more of the
interface, and if a lot is still digital, are multiple systems ever
implemented where an analog mode is included?

Speaking of Control Systems, fresh out of College, with my first real job
working GN&C on Space Shuttle I was assigned to help with the On-Orbit post
flight report for STS-1 and STS-2.  One of the problems these first few
flights was in attitude control, the gains were wrong resulting in
excessive fuel usage. Essentially, banging back an forth from positive
limit to negative limit, hosing out propellant. Things haven't changed much
in 40 years with Starliner as the NASA administrator is talking about the
problem.
https://youtu.be/NpQlxN4xbKM?t=85
Here he's saying the attitude tried to maintain "to precise" an attitude
window, which isn't the problem, it's the gains were wrong. The precise
tolerance just means it takes much less time to get from the +side to the
-side, so it hosed fuel out faster.  But even with a very loose attitude
window, if the gains are wrong, it's going to be banging back and forth
(+-+-+-+-+-+ firings) from one limit to the other. Forty years and no
progress, haven't these people heard of auto gains? It's such a simple
thing to implement, especially for a new vehicle it's flight
characteristics are fuzzy. From a single axis prospective, if the control
went from + to - or - to +, gain = 0.99 * gain, reducing the next thruster
firing on the other side of the window. It's the simplest of iterative
algorithms that quickly would stop the control system from banging back and
forth in it's window. Quickly, the gain is reduced so that only thruster on
one side of the attitude window will fire. On the flip side, if the gain is
to small, only thrusters on one side of the attitude window will fire,
either the + side (+++++++ firings) or the - side (--------- firings) and
the attitude never crosses the center of the window (zero) then gain = 1.01
* gain.

When the Space Shuttles attitude control gains were finally tuned properly
(manually), the attitude plots were really pretty. Thruster firings in one
direction only, with a nice long drift through the commanded attitude then
back down to the same side of the window, bouncing off one side (bouncing
ball) of the window only. No commanded force fights between opposing
thrusters. So "precise attitude control" will have more frequent but
shorter thruster firings in one direction only, while "loose, sloppy
attitude control" will have fewer but longer thruster firings in one
direction only. Fuel usage for both precise and loose attitude control
should be exactly the same when thrust pulses are only fighting the
external moments which is the same in both cases.


On Sat, Dec 21, 2019 at 1:39 AM Uwe Klein <uwe@xxxxxxxxxxxxxxxxxxx> wrote:

Am 21.12.2019 um 09:15 schrieb Henry Spencer:
What nobody had noticed, until the postmortem after the failure, was
that the misbehavior was always in the first test of the day, after the
hardware had been powered down overnight.  Internal nodes inside FPGAs
can hold charge for a surprisingly long time after the power has been
turned off, and this can make a difference in how the system powers up
again, especially if the designer hasn't paid enough attention to
forcing clean reset on power-up.  When they did *long* power-downs, the
problem was reproducible.

It is essential that you have a reliable "power good" mechanism
and that it works in both directions
  Power Up AND Power Down and that it is not dependent on any min
rise/fall times ( aka  Brown Out protection )

Next step is creating a known start condition.
it can be a good idea to have a nonvolatile reset counter.

And you don't connect pyros directly to FPGA outputs.
Add some Interlock or other mechanism should be in between.
like sequential action to trigger a pyro device.

Uwe



-- 
Craig Fink
WeBeGood@xxxxxxxxx

Other related posts: