Forum | Thoughts on control

Here are some preliminary thoughts on how overall control of the CM may work.

At the very base of this system is a discrete set of commands.  Much like command line programs, commands can (but may not) accept arguments.  Each command should do precisely one thing and do it well.

Commands may originate from several sources:

• They may be entered manually by the astronaut using an interface (keyboard, switches, joysticks, whatever)
• They may be sent from ground control via radio (telecommand)
• They may be generated automatically by various subsystems (e.g. the guidance system may occasionally automatically generate RCS commands etc.)

Each of these sources can either submit a command for immediate execution or schedule a command for execution at either a future time or when a set of conditions is met.  Automatically generated and scheduled commands should trigger some kind of on-screen and audio warning 60 seconds (or as near to this as possible) in advance of command execution, giving the astronaut the chance to cancel / delay them.

Commands from all three sources first pass through a command server.  The command server runs some sanity checks on the commands to stop anybody from doing anything supid.  E.g. if the command to initiate the OSM's retro rocket deorbit burn is passed to the command server but the CM is, say, not in the correct orientation for reentry, or is half way to the moon, the command server asks "Really?" instead of just blindly doing it.  Obviously it should be possible with enough deliberate effort to overide any and all such checks, but there should be no question of this happening accidentally.  If a command passes its sanity checks then the command server either passes the command on to the relevant subsystem or adds it to the scheduled queue.

Now, the primitive commands will be fairly fine-grained things.  We should also have a pre-defined set of macros (and possibly the ability to define macros mid-flight – either from a keyboard or uploaded from the ground).  A macro executes a set of primitive commands in a fixed order.  For example, there may be an "enter low power mode" macro, for use in the event of some kind of power generation failure (this macro could be generated automatically by the computers if the telemetry data indicates a voltage drop, or could be triggered by a "panic switch" on the atronaut's control panel), which runs all the separate commands to, e.g. terminate the transmission of cabin video, reduce the frequency with which telemetry packets are sent to the minimum safe rate, turn cabin lighting down to low, etc.  Macros enable the astronaut to respond to predictable emergency situations quickly, rather than having to quickly flip two dozen switches in correct order under pressure.

If people agree that this is a sensible overall framework, then I see no reason we can't start planning commands and macros now in a wiki page.  Software is infinitely flexible so starting to plan early isn't really dangerous at all.  Things like a half complete list of commands will look cool and motivating on the Wiki and are an easy thing for everyone to chip in on.  Later on, when we have a clearer idea of what we need and how the command server will be implemented in software, we can start slowly locking the command set down and having properly documented, versioned APIs.

I'm not quite sure what you mean with regards to syntax?  I'm not proposing a fully-fledged programming lanuage, just a list of commands with arguments and a description of what they do, e.g.

Command: SET_TELEM_RATE

Args: rate (integer)

Desc: Set telemetry packet send rate to once per "rate" seconds.

These commands would of course eventually actually be implemented as programs in C or Python or something, and so to would the programs that automatically generate commands in response to certain conditions, but we're a long way away from doing any of that yet, and it's possible to plan their overall structure/purpose without writing any code at all.

Macros would be defined at this stage as nothing more than an ordered list of command calls, e.g.

Macro: SET_LOW_POWER

Code:

1. SET_VIDEO_TRANS(0)
2. SET_TELEM_RATE(300)
3. SET_CABIN_LIGHT(1)

Actually, I hadn't thought about "getters" at all.  I'm not sure how I feel about that.  It would certainly clutter up our command list a *lot* (although we could perhaps improve this by having a single GET_VALUE command that took a single argument, a numerical code corresponding to the variable of interest).

From the point of view of the ground crew, they need for many individual getter commands to learn about the spacecraft state seems superfluous when they have a telemetry downlink.  Perhaps we could have a few defined levels of telemetry packet detail, ranging from the bare basics requried to be useful, to a complete dump of everything single variable setting.  Then any data can be retreived with two commands, temporarily bumping the telem detail up to max and then restoring it to where it was.

From the point of view of the various onboard systems, which might want to find out variable values to help inform their automatic decisions, etc., I'm not sure going through the actual command system would be best for this, we could just have some kind of simple read-only variable server for them to consult.

I suppose I feel like the actual command system should be limited to commands for actually doing something, i.e. which are for controlling the ship.

brmj said:

I think I was insufficiently clear. I was thinking more about internal to the ship's computing "ecosystem", rather than as part of the overall command scheme. I was really asking more how, for example, the navigation computer might inquire as to how much fuel the RCS system had left.

Understood, I wasn't sure if this was what you meant.

I think that for this a simple server might be the best overall solution.  There will already have to be a centralised (but obviously redundant) file server somewhere on the network for the other nodes to store their vital data, so if we run the variable value getting service on that machine then it adds no extra centralisation.  Lag I should hope would be minimal – though we should do our best to set things up so that precision timing is important only when it absolutely has to be.