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.
