:ram.2/conclusions.txt

Conclusions

So, another retrochallenge draws to a close, what conclusions can be drawn?

I'm going to discuss the following areas:

  • Improvements to Lunar Lander.
  • The RC Experience this time around.
  • Drop out rate, attracting more participants.
  • The Z88 as a retrochallenge blogging tool.
  • Portability of BBC Basic.

Improvements to Lunar Lander

Although I'm happy with lunar lander as it stands, there are a number of improvements that I think would make it a better experience. It isn't meant to be a simulation of the actual LEM landing, as the vast majority of that process was controlled by the Apollo Guidance Computer. There is an excellent book that has just be published by Springer which I'd recommend to anyone with an interest in both the computer and the lunar missions - 'The Apollo Guidance Computer - Architecture and Operation' by Frank O'Brien. The book goes into the details of the software architecture of the computer, the parts of the lunar mission it was designed to address and the way in which it interfaced with the rest of the systems on the spacecraft.

Improvements:

Accuracy
Most of the figures used in the lunar lander game are either guesses, half-remembered facts or have been fudged to make the game more enjoyable. As an academic exercise I'd like to calibrate the figures to match an actual landing. It will be interesting to see how well the code can simulate the timescales and parameters of the actual descent. The biggest anomoly is my hopelessy inaccurate guess of the lunar gravity which is actually 1.622 metres/second not 3.33 metres/second.

The descent itself (for Apollo 11) started from a 60 nautical mile orbit. The Powered Descent Initiation started 240 miles uprange from the landing site and at 15 kilometres altitude.

During the braking phase the objective was to reduce the 1,670 metres/second orbital speed to around 210 metres/second at 24 kilometres altitude. At ignition the engine was run at 10% to check instruments (1,500 lbs thrust) and to allow the computer to gimbal the descent engine to align thrust with the centre of gravity of the LEM. The engine was brought up to full thrust after 26 seconds (9,870 lbs). Full thrust is 94% of the rated thrust (10,500 lbs) - this was limited because of excessive combustion chamber and nozzle erosion when operating the engine at 100%.

In contrast, the game starts 30 kilometres down range at an altitude of 10 kilometres with the LEM travelling at 500 metres/second. I have made no effort to calibrate the output of the engine, so thrust is arbitrary. My landing radar kicks in at 1000 metres - the real radar started working 3 mins into the descent at 40,000 feet.

In real life the end of the braking phase signalled the start of the approach phase where the LM pitched to 30 degrees from vertical to give the crew their first glimpse of the landing site. All this was handled by the guidance computer, which at this point was throttling the engine at 57% of rated thrust (5,900 lbs).

The commander took over at around 100 metres to steer the LM in the horizontal plane to a suitable landing site using a stick controller in their right hand and using a toggle switch with their left hand to control descent rate in 0.3 metres/second increments.

The CONTACT light in the game illuminates when the LEM is at 3 metres altitude - in reality the probes on the bottom of the LEM are 5 foot long, so CONTACT would not have illuminated until within 1 metres of the surface.

The tape instruments were my attempt to portray the kind of instruments available on the LEM, but mine only cover a small range of the vertical altitude and descent rate, compared with those installed on the actual LEM:

Also, there were similar gauges for the engine instrumentation and fuel status, whereas in the simulation there is only numbers available:

The third dimension. The simulation only handles two dimensions, but obviously in reality a site had to be picked from a two-dimensional horizontal plane on the surface of the moon. I'd like to add the third dimension - initially the instrumentation I'd created on the simulation included an indicator for horizontal position in two-dimensions, but I removed it as I didn't have time to add the simulation parameters and control mechanism.

Descent Profile. It would be nice to have the descent profile recorded for viewing after a simulation run. I didn't manage to get the extension to Z88 basic to support graphics installed (and I think I would have hit memory limitations anyway) but even a simple character-based plot would be an interesting improvement, or the ability to record the simulation parameters over the course of a run for later processing using gnuplot.

Ascent and docking. This would have been an interesting addition, but for it to give a feel for the actual experience I'd have gotten involved in orbital mechanics, and even saying those words breaks me out into a cold sweat. The theory would be that in a lower orbit the LEM would be describing a shorter circle than that of the command module so would be able to catch it up. Maybe another retrochallenge...

Engine mechanics. I'm not sure how much this would add to the simulation experience, but there are differences between the actual and commanded power, there are no-go thrust settings due to propellant erosion of the engine combustion chamber and nozzle. Also, no account is taken of the changing centre of gravity of the LEM due to use of fuel - all this was taken into account by the AGC but would make an interesting simulation exercise.

"Call-outs". If you listen to the audio footage of a lunar descent you can hear frequent "call-outs" by the LEM crew of altitude, descent rate and horizontal speed. It would be useful to simulate these as text messages at the bottom of the screen, updated every 15 seconds or so.

High-score table. This seemed a bit pointless for the Z88 based version, but the retro-net.org BBS version definitely needs a way for people's success to be recorded. I'd also add a 'worst-losers' section where we document the size of people's craters!

AGC. Having the ability to flick a switch and have a built in guidance computer perform the rest of the landing would be an interesting academic exercise for me. Not sure it would add much to the game, however, except for the exceptionally lazy pilots out there. Maybe a half-way house where the computer gets you out of a messy situation.

Modula-3 Version. I could fairly easily port the game over to Modula-3 and make use of Object Oriented Programming to greatly enhance the simulation. Given my situation (being on holiday) this was never going to be a realistic option.

Other Thoughts

BBC BASIC: I'm kind of glad that I've ended up writing code in BBC BASIC this time around. The problem with a lot of languages these days is that quite a lot of infrastructure is required to implement a console based game (screen-oriented output, single key input with timeout, time-based control, etc). It would appear that the designers of BBC BASIC were mindful of my kind of application, as there was just enough support to get by in what is quite a limited run-time library. This was great in getting something up and running quickly, and allowed me to maximise my time coding the simulation rather than getting to grips with complex support libraries. Certainly given the console-based remit the language and support libraries were not a hindrance.

Thoughts about the competition in general:

DROPOUT RATE: We seemed to have a high drop out rate this time which is always a shame to see - there were potentially some very interesting projects. It's nice to see we attracted more participants and I think we should be proactive in this department in the future.

OTHER ENTRANTS: reality clearly had a major impact on a number of projects, which is also a shame, but clearly a fact of life. The old-stalwarts for the most part provided continued entertainment, even if the measure of success required adjusting somewhat. We all set high expections - maybe that is no bad thing.

Z88: clearly I'm now a big fan of the Z88. With its daylight-readable screen, quiet efficient keyboard, excellent word processing capabilities, good battery life, programmability and sufficient connectivity it was a lucky find just before my holiday. The vast majority of my blog was written on it, and the lander program was designed to fit within the limited six-line addressable display. I was going to sell it at the end of retrochallenge, but I'm now undecided, I do think that it has earnt its place as a valuable tool. I can't imagine achieving what I have using a standard laptop - I'd have permanently squinting eyes by now trying to read a laptop screen outdoors! Connectivity is the main issue, however, requiring a support machine to get the text/code off the Z88 and onto the internet. It's possible with an external GSM modem that I could have managed without a support machine, but without trying that configuration I can't say one way or another.

CODE PORTABILITY: I think both myself and luddite were very pleasantly surprised at the portability of BBC BASIC. All the problems that we've found between us can be narrowed down to assumptions made about boundary conditions (such as what happens when you PRINT TAB(-1,0) for example (which on the face of it is a pretty silly thing to do). It hasn't taken much work to iron out the differences, so that the code runs in at least three places: the Z88, luddites retro-net.org BBS and the Linux BBC Basic emulator brandy.

COMMUNICATION: The support commentary provided by wgoodf via twitter significantly enhances the spirit of the competition, but I think it would be enhanced by having a multi-way communication medium where participants can comment on other projects in a central location and with the ease that twitter provides. In the past where there were less entrants the medium through which this happened was the retrochallenge BBS, but this time around (and to be fair for some time before the competition) the BBS has been fairly quiet. This is a shame because this is a community event, and I have felt that, with the exception of the usual suspects, there maybe hasn't been the level of support between participants that there has been in previous events. It would be interesting to know how other participants feel about this issue.

Conclusion

Hopefully my blog has provided to be entertaining and at least a little educational. I've very much enjoyed this retrochallenge, as always I've been able to focus my mind for a couple of weeks with a clear purpose and feel like I've achieved something (which given the level of distraction I normally suffer from is no mean feat).

Thanks to the other participants for providing entertaining reads, and see you all next time.

Mark.

Descent Profile: descent profile


The Guidance Computer The Guidance Computer


Tape Instruments: Tape Instruments

Engine Gauges: Engine Gauges