Difference between revisions of "ProjectNotes:KSPKontroller"
(→Nav Ball) |
(→Strategy) |
||
| Line 60: | Line 60: | ||
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. | 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). | ||
Revision as of 09:56, 14 August 2013
Notes for the KSP Kontroller project
Contents |
Inspiration
In-game screenshot album of the cockpit
Component Options
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.
Panel
Silver coloured laser cut acrylic. Easy to get from Ponoko.
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.
Panel 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/
Analog Dials
http://www.amazon.com/Analog-Voltage-Panel-Meter-Voltmeter/dp/B00A4S9ZHW/ http://www.amazon.com/gp/product/B0051E8ONA/ , 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.
Toggle Switches
https://www.sparkfun.com/products/11310 might be good for "lift off" and "next stage"
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.
2.8 inch TFT LCD with resistive touchscreen, holes make it easy to mount, fairly fast interface
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).
