nor suffered from catastrophic failure from temperature
My suspicion is the battery is much more vulnerable than the AVR processor.
Some general comments, how does one processor "take control"? With physical IO to servos, discretes and such the unhealthy one would set its outputs to inputs (high impedance) so the next processor could be free so set the state to HIGH or LOW at will. But if you are too unhealthy to be in control, how can we trust you to relinquish all your I/O?
Its so hard to model and the electronics are so forgiving that its mostly done empirically (suck it and see). Log your inside and outside temperature from telemetry to analyze after flight. If the thermal balance is so horribly bad that the insides start dying then switching to another (Arduino, battery, etc.) is not too helpful...
Anything with a heat sink is trouble....
In the later stages, would evaporative cooling be an answer, given the fact that heatsinks have trouble dissipating heat into a near vacuum? I suppose the weight price of lifting the liquid to be evaporated rules that out?
The AVR chips do have such an internal WDT and may or may not be useful for what you are looking for. I kind of like external hardware WDT, where all the processors have to continously send a sanity pulse out and if external logic circuitry detects a processor not alive, just switches to the redundant processor.
Standard microcontroller watchdog integrated circuits will read a pulse from the microcontroller and this resets the watchdog counter to zero. You can do that with a dedicated circuit or if you need some repeatability and precision I'd do it with a microcontroller
You'd want an external watchdog on it to reboot it if needed. I'd be tempted to use an ATTINY as a watchdog rather than the available dedicated watchdog integrated circuits.
I've worked with the Dallas external watchdog integrated circuit. DS1232. I can't spit on it hard enough to kill the engineer that built this piece of *t. It has no consistency across temperature, it has no consistency between parts and if you get one batch to work the next batch you buy might not.
My gut feel is that attempting to deploy redundant systems, plus implementing some kind of cross-check/voting mechanism will quite possibly make your system LESS reliable unless you are doing graduate-level research on those topics. In which case coming here for advice seems odd.
Why three identically-programmed devices?
After years of seeing discussions about fighting heat buildup in electronics, I was amused to read of people who are fighting a situation where there isn't enough heat! (I presume they are further frustrated by having heat buildup problems while the balloon is still near the ground?)
Arduino A reads -60, B reads -58, C reads -10, the result from C will be ignored.
how can I make sure that the program flow on the 3 Arduinos are the same?
if Arduino A wants to save temperature data to the SD card, while B wants to save GPS coordinates?
When Arduino A can't respond to the WDT's pull fast enough, WDT will reset this Arduino. If reset still can't make it go faster, this Arduino will be turned off by turning off the MOSFET connected to Vin pin of it, and then turn on Arduino B, etc.
Second, how to do the "turn off & turn on" switching using WDT circuit?
wdrldi r_temp1,(1<<WDIE)out WDTCR,r_temp1
Isn't ATTINY for onboard debugging?