Revision as of 00:11, 17 August 2013

Notes for the KSP Kontroller project

Inspiration and Physical Design

In-game screenshot album of the cockpit

Strategy

One-off DIY (meaning super expensive awesome looking components are allowed)? DIY kit-able (all components cheap and easy to get and work with)? Full product for sale (difficult components allowed but must be cheap)?

Frank is going to pick components for suitable a DIY kit. One LCD, zero to two analog dial meters, 6 illuminated square buttons for custom actions, 2 illuminated switches for SAS and RCS, 1 protected toggle switch for staging. Three small thumbsticks, one slide throttle.

Data Options

Before decided upon, a comprehensive list of potential components will be categorized as necessary, optional, or unnecessary. Following this list, each necessary or optional component will be revisited in its entirety, including its options for purchase, characteristics in design, fabrication, construction, implementation, and/or software-related characteristics.

• SAS, RCS, Lights, Gear, and Brakes Toggle

• SAS, RCS, Lights, Gear, and Brakes Indicator

• Stage Push Button

• Stage Enabler Toggle

• Stage Enabler Indicator

• Abort Push Button

• Abort Enabler Toggle

• Abort Enabler Indicator

• Time Warp Slow Down and Speed Up

• Orbital, External, and IVA View Selector Push Buttons

• Staging and Docking Mode Pushbuttons

• Zoom In, Zoom Out Push Buttons

• View Rotation Stick

• Custom Action Group 1-10 Push Buttons

• Custom Action Group 1-10 Indicators

• Autosave

• Load

• Hands-On Navigational Joystick

• Throttle

• Throttle Enabler Toggle

• Throttle Enabler Indicator

• Translational Docking Stick

• Navigation Ball

• Heading Indicator (numeric)

• Velocity Display

• Velocity Specifier (Surface, Orbit, Target)

• Delta-V Display (numeric and visual)

• Time to Delta-V (numeric)

• Estimated Burn Time (numeric)

• Vertical Speed (numeric and/or visual)

• Barometric Altimeter (numeric)

• Radar Altimeter (visual and maybe numeric)

• G-Force (visual)

• Extreme G-Force Indicator

• Overheat Display (visual)

• Lowest Stage Fuel Level (visual and maybe numeric)

• Total Fuel Level (visual and maybe numeric)

• Total Liquid Fuel, Oxidizer, Solid Fuel, and Electricity Level (visual and maybe numeric)

• Low Food, Oxygen, and/or Water Indicator (life support will be implemented soon, I think)

• Food, Oxygen, Water levels (visual and maybe numeric)

Part Choices

Imposed Limitations

Frank has decided to put a few limits on capabilities:

• 8 analog inputs with 12 bit accuracy. (joysticks, throttle, potentiometer)

• 32 digital inputs (buttons, switches), 16 is ideal

• 32 digital outputs (ordinary LEDs), 16 is ideal

• 16 PWM outputs (LEDs that dim, analog panel dials), 8 is ideal

• 8 servos

• 1 colour display

• 1 monochrome display

Microcontroller/Microprocessor

STM32F4, actually probably overkill, but STM32F4 Discovery is a good place to get started, or Netduino 2 or Netduino Plus 2. I have both of these, plus my own custom boards. F2 or F1 would probably also work. L1 will also work but we don't need super low power features. LPC family from NXP is an option, start with the mbed.

8 bit AVR (must have native USB) might be too slow to keep up a good frame rate on the LCD for the nav ball. If it's fast enough, then great, if not, then upgrade. I'd say we try it out, since it makes it easy for people not as skilled with ARM.

Raspberry Pi or any "single board computer" (BeagleBone, BeagleBoard, PandaBoard, GumStix, etc) is not recommended. Expensive, code gets complicated, communication gets complicated, latency adds up, plus a lot more problems.

Most likely, Frank's first hardware prototype will use a STM32F405RG

Panel

Silver coloured laser cut acrylic. Easy to get from Ponoko. Will probably start off with clear acrylic and spray paint it silver, so the LCD and meters are still protected.

Carbon fiber, diamond steel sheets, plain aluminum sheets, all possible but harder and more expensive. Getting something water jet cut would be cool but expensive. I don't have many metal working tools at home.

Buttons

Digi-Key product results for green or red/green illuminated square buttons, through hole or panel mounted, sorted by price, text can be printed onto transparent stickers

If you are super rich http://www.screenkeys.com/ or http://www.nkkswitches.com/SmartSwitch-ProgrammableSwitches/ or http://www.rjselectronics.com/?LCD_Switches:Q5 , RJS's Q5 keys are "Unit cost for 6 pieces is $34 each + $45 shipping", NKK's keys are somewhere over $60 each from Mouser. These keys will add a significant bit of complexity to the electronics and code but if it's an unlimited budget project, definitely worth the effort.

Analog Dials

http://www.amazon.com/Analog-Voltage-Panel-Meter-Voltmeter/dp/B00A4S9ZHW/ http://www.amazon.com/gp/product/B0051E8ONA/ , these are 0-5V, using a 3.3V microcontroller might require extra components, not a huge issue. 0-1V meters also exist

Current panel meters also exist, and a simple resistor value would be enough to make the voltage range issue go away. 0 to 10mA, or something around that would work. http://www.adafruit.com/products/252

Would probably replace the white voltage scale with a black scale. These can only be used for data that can be represented by a percentage (fuel, electric charge, atmosphere) because we can't dynamically change text on it.

Or a micro servo can be used. The panel meter's needle looks pretty thin, making them heavier might be risky.

I'm still trying to hunt some real instrument dials.

Sub-micro servos are tiny, HobbyKing example, might need a gear for a wider rotation, McMaster Carr has gears.

Black and white graphic LCDs might be a substitute for real analog dials. buy-display.com has some 160x64 displays that might be suitable. LCDs offer a lot more flexibility, obviously.

Toggle Switches

https://www.sparkfun.com/products/11310 might be good for "lift off" and "next stage"

RCS and SAS are on the push button panel inside the game, but illuminated toggle switches may be a better choice.

Illuminated (red or green or red/green) rocker switches on digikey.ca

Illuminated (red or green or red/green) toggle switches on digikey.ca

Joysticks

http://www.adafruit.com/products/512 are easy to mount into a panel

http://www.reallycooltoys.com/other-joystick-TX.html are expensive, but they have triple axis industrial joysticks

Sliding potentiometers are easy to find and will probably be mounted onto a perfboard, and perfboard mounted to the panel. Just make sure it has a nice knob. Motorized is optional but requires a H-bridge to be built.

Video gaming flight controllers or joysticks are acceptable but they are expensive and bulky. The player should connect them directly into the computer so they are irrelevant.

Nav Ball

2.8 inch TFT LCD with resistive touchscreen, holes make it easy to mount, fairly fast interface

Crazy

Got several grand to throw around?

http://www.aircraftspruce.com/categories/avionics_instruments/av/menus/in/index.html

http://gamesharkstore.ca/viewItem.asp?idProduct=4503&idCategory=450&scid=saiteksite

Software and Firmware

Strategy

The microcontroller can create two interfaces, one will be a generic HID joystick profile, and the second one will be custom HID or something else custom. The goal is to avoid COM port selection and avoid driver installation if possible.

A KSP plugin is required. Another way of doing it is probably making a "trainer" type thing but that's a lot more difficult. Stick with the official method of making plugins using C# and the Unity Engine API.

The plugin should be agnostic about the MCU's hardware, update all relevant data at a maximum rate of 15 or 20 times per second per variable.

Whatever MCU is chosen, LCD interface is the most important due to frame rate being critical. Joystick and throttle input is second priority. Everything else can use I2C connected chips (GPIO expanders, PWM/DAC outputs, ADC inputs) if we run out of pins.

Drawing the nav ball will be very hard. Having the computer draw it will take bandwidth, but having the MCU render it will be very processing intensive if a 3D look is required.

Use LUFA as the USB library for 8 bit AVR, and STM32 has their own USB library. mbed also has their own. If an additional USB host port is required, then use a MAX3421E or look for a MCU with 2 USB OTG ports (but this is much more difficult and eliminates AVR as a possibility).