4 ms·

The Ingenuity drone also on Mars now uses a Snapdragon processor running Linux. This is not radiation hardened IIRC, but it reboots so fast that it is in contro

The Ingenuity drone also on Mars now uses a Snapdragon processor running Linux. This is not radiation hardened IIRC, but it reboots so fast that it is in control again before it hits the ground in case the computer borks due to radiation flipping bits in flight. EDIT: Found the article again: https://spectrum.ieee.org/automaton/aerospace/robotic-exploration/nasa-designed-perseverance-helicopter-rover-fly-autonomously-mars https://spectrum.ieee.org/automaton/aerospace/robotic-explor... I'm not sure where I got the reboot thing from, I think HN in a thread after the Perseverance landing

retSava 6y ago
Would love to see the considerations that went into that design! Does it try to keep state across such a reboot? Is the first course of action to try to deduce whether it's about to crash? Is every sensor reading done multiple times to reduce risk of reading wrong (typically, such sensors are basic and doesn't employ error checks or such)? Does it try to understand why the OS crashed and do any graceful degradation, eg "fine, don't use that sensor then"?
- moftz 6y ago
  You can filter the sensor data to get rid of any "sparkles". You can also add in power controls for the sensor so that you can reboot them when they either stop responding or send too much erroneous data.
mercora 6y ago
this assumes a bitflip would result in an immediate reboot which is not even that likely i think. detecting these failures probably requires redundant systems and luck i guess.
- tzs 6y ago
  You could simply assume that any significant deviation from the planned flight profile is due to bit flips and reboot. That might miss bit flips that don't affect the flight profile, but those do not need a real time response. Bit flips in collected data for example could probably be found afterwards when the data is analyzed. Heck, it might even make sense to figure out what the minimum time, T, is such that something can go wrong that a reboot will fix fast enough to save the mission but only if the reboot happens within T seconds of the onset of the problem. Then just reboot every T seconds regardless of whether you know of something actually wrong.

retSava 6y ago

Would love to see the considerations that went into that design! Does it try to keep state across such a reboot? Is the first course of action to try to deduce whether it's about to crash? Is every sensor reading done multiple times to reduce risk of reading wrong (typically, such sensors are basic and doesn't employ error checks or such)? Does it try to understand why the OS crashed and do any graceful degradation, eg "fine, don't use that sensor then"?

moftz 6y ago
You can filter the sensor data to get rid of any "sparkles". You can also add in power controls for the sensor so that you can reboot them when they either stop responding or send too much erroneous data.

mercora 6y ago

this assumes a bitflip would result in an immediate reboot which is not even that likely i think. detecting these failures probably requires redundant systems and luck i guess.

tzs 6y ago
You could simply assume that any significant deviation from the planned flight profile is due to bit flips and reboot. That might miss bit flips that don't affect the flight profile, but those do not need a real time response. Bit flips in collected data for example could probably be found afterwards when the data is analyzed. Heck, it might even make sense to figure out what the minimum time, T, is such that something can go wrong that a reboot will fix fast enough to save the mission but only if the reboot happens within T seconds of the onset of the problem. Then just reboot every T seconds regardless of whether you know of something actually wrong.