IIRC Apollo used a fairly standard military aircraft type radar altimeter, together with a ground doppler radar sensor virtually the same as that used on helicopters for auto-hover.
Using core memory gave them the ability to recover from a reset, because it's inherently non-volatile. To do the same with a Picaxe would probably mean sending every critical bit of data out to EEPROM to be stored each time around any loop, which would fairly quickly hit the EEPROM write limit I think.
My first contact with mini-computers was with Elliot 920B "suitcase" computers, recovered from the ill-fated TSR2 project and re-purposed for another military task. IIRC these were broadly similar in capability to the Apollo machine, around 8k of core memory and logic gates made up with discrete transistors and diodes. The core memory always amazed me, as each bit of storage was a delicate little hand-wound toroid, with hundreds of these toroids assembled on large boards.
Certainly the Picaxe would be more than capable of doing everything the Apollo computer did, and unlike the Apollo system (which was heavily restricted by the size and weight of the components) it could easily incorporate a lot more redundancy and error checking to get the required reliability. Using a three parallel system approach, with different code (doing the same thing) running on each, together with frequent error polling, should get a system that would meet the fairly tough reliability requirement. The weak points would be the common code in the interpreter and the common silicon, but given the fairly simple (by modern aircraft control standards) requirement it should be possible to do 100% testing, something that's now virtually impossible for an aircraft FMS, due to the high code line count.
