K-42 The Next Generation

After a long timeout I decided to stop playing the game and build stuff for it again.

As always, It's only after you've built something that you know how i SHOULD have been done.

So I decided to do a few modifications of the K-42 command console. The first modification was to scrap the whole design, except the enclosure, the I2C bus and the keyboard, and start all over again.

System architecture and communication

The original system was designed as single master, multiple slaves. There would be one master doing all the processing stuff and the slaves would only answer to polling requests. The master would also be responsible for emulating USB joystick and serial port. Every module had its own protocol format and its own fixed length message.

There was several problems with this design:

• The whole system had to fit into 25kB of free program memory and the computational constraints of a 16MHz 8-bit processing capacity of a single Arduino.
• The master needed information about every module and what is was supposed to do.
• The master had to poll every module every 20 ms, even if nothing changed, in order to get low latency joystick position information.

The new architecture is a pure multi master network with a message based communication protocol. This means that if the state of a module changes, it just send a message of the state change to all listeners. Each message is composed of two bytes, a property and a value.

The advantages with the new design is:

• There is no theoretical limit to the amount of processing nodes which eliminates the need for bigger memory and faster CPU. If there are many tasks or long computation, they can be distributed to more processors. Communication bandwidth will be the limiting factor.
• Each module only need to hold a state of the signals that are needed to accomplish its own tasks.
• Each module only sends state changes when something happens that is interesting for other modules. If nothing happens or if the state change is only internal, nothing is sent.

Computer interface

The original plan was to use mods for extra action groups to increase the number of controls. All switches would be mapped to unused key combinations and I would use arduinos keyboard library to send Alt, Shift and Ctrl key combinations for each action. These key combinations would in turn be mapped to action groups and those would be mapped to actions of different parts of the space ship.

I wish I had written this down before I started building the damned thing. In that case it would have been obvious that the amount of mapping key combinations to action groups to parts, would take most of the time used for building a new craft. Now I could happily discover that little detail after building and programming most of the modules instead.

The new plan is much simpler:

1. Build a “joystick” that implements basic KSP controls for manual flying. Connect it as a USB joystick with buttons and map those using the built in control mappings in KSP.
2. Build instrumentation that can display some basic stuff like altitude, speed, apoapsis and the like.
3. Build some kind of navigation computer that can help with burn timing, soft landings and getting into orbit in a reasonably efficient way.

The parts above will be built and tested independently from each other, limiting the amount of reworking needed if I have a bad brain day or is just plain unlucky when trying to think. There is no actual need to build the in that specific order either, but I decided to make the manual controls first, because of reasons. I don’t know yet what the next step will be.

Coming soon™

The manual controls; HID, electronic and program design. Stay tuned.