So far with the controller we are talking about in this thread it has
been done where 2 controllers are running and you can switch between
them. You can shut one down and upload the entire firmware over on the
other (In flight!) it is much more possible to poll 3 flight computers
with the off board computer in another case.
You could also switch manually in flight to the second controller.
Schemes such as these might be useful at some point on certain projects.
However the goal here is to get all of rocketry up to speed with modern
controllers and doing all the fun stuff you can do because of them.
-------- Original Message --------
Subject: [AR] Re: Flight Controller Features
From: Ben Brockert <wikkit@xxxxxxxxx>
Date: Tue, January 12, 2016 12:05 pm
To: "arocket@xxxxxxxxxxxxx" <arocket@xxxxxxxxxxxxx>
Back in the day, attitude was a physical state of an actual mechanical
gyroscope that could be measured at any point. 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.
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 can go with Henry's flight controller LARPing.
On Tue, Jan 12, 2016 at 1:51 PM, rebel without a job
<rebelwithoutajob@xxxxxxxxxxx> wrote:
The usual reason for a reboot is that errors in data or code have
accumulated to the point where the program’s state has diverged from
reality in some way.
The question then becomes how much state preservation would be considered
helpful, given that the point of the reboot is to discard and then rebuild
that state.
My thoughts: Preservation of immediate sensor data is a good idea.
Preservation of historical sensor data is almost always a good idea, if the
historical sensor data has been verified in some way so that bad sensor
data has been purged. Otherwise the restarted program could take up the
bad sensor data and recreate the error that led to the rebooting.
Preservation of computed or aggregate state representing the physical model
may not be a good idea. The computed state may have been generated from
bad sensor data and contributed to the divergence. Reverifying the
historical sensor data upon reboot is a good safety precaution.
On the other hand, rebuilding of internal program control state is almost
always helpful.
Perhaps a non-reboot reset is the optimal solution. Upon detection of
divergence between the internal flight model and sensor data, the first
step would be to restart the software from a known good condition, then
verify the historical sensor data and then rebuild the flight model. This
provides some resilience to minor programming or sensor errors.
If a rebuilding of the flight model and program control state fails, the
next step would be an orderly shutdown in the safest possible configuration
(backup fuel and oxidizer valves closed, flight control servos disengaged,
most electric busses depowered, pressurization tank vented if it is likely
to fail catastrophically if full upon landing, parachute deployed, etc)
Kevin
(also thanks to those who sent me the pendulum rocket fallacy upthread and
the information on battery-powered motor gimbals)
On Jan 12, 2016, at 10:34 AM, Robert Watzlavick <rocket@xxxxxxxxxxxxxx>
wrote:
I wasn't going to bring up restart protection but since you mention it,
yes there's various levels of rebooting. I have a copy of the AGC book
and it's interesting to see how they implemented it. I was considering
implementing a primitive version of restart protection, maybe just storing
the current vehicle state (in-air, on- ground, etc. not necessarily state
vector but that could be done too). I believe the Netburner has a small
block of SRAM that's not cleared on a reset but now I can't remember if
it's on the CPU card itself or on the dev board. I could always add a
small serial memory device. I measured about 300 ms from reset to first
line of a user program running. Not too bad but a small vehicle could move
a lot in 300 ms making it tricky to use the state vector. If I get a
reboot and I think it's already flying, I plan to continue sending data
but not touch any valves and rely on the backup timer or ground signal for
deployment.
