Search the Community

Winter is coming.... ...and I need something to occupy my time while hanging out indoors. Anyone up for working together on a control panel? I'm not a software mod'er, so I need help with actually integrating with KSP, but I am pretty good with electronic design, Raspberry Pi/Aduino, etc... Essentially, I'm thinking of building a small instrument cluster and a cluster of tactile controls (buttons, switches, joystick?) that would sit in an angled enclosure that would sit on your desk. Anyone up for teaming up?

KSP sometimes causes my mac to suffer an error related force shutdown when I attempt to defocus KSP. This has happen once or more per day. I think it is a memory related issue. My specialty is making missiles, not fixing hardware. (But I am great at breaking hardware) Don't quote me on this I come here instead of apple because my warranty ran out and I might have to pay money to get it checked. Plus, they would find where my secret base is. Specs: MacBook Air (11-inch, Early 2015) Processor: 1.6 GHz Intel Core i5 Memory: 8 GB 1600 MHz DDR3 Graphics: Intel HD Graphics 6000 1536 MB

This is my attempt to build a KSP simpit, using Arduino microcontrollers and the KSPSerialIO plugin. It started off small and is currently a lot less small. Current status 20160815: I've been slowly refining my current build. The altitude and vertical speed analogue gauges are now hooked up and working (it only took two years). I have a digital navball that shows current vessel attitude, and have been banging my head against the KSP API trying to work out how to extract the other orbital vectors in a format I can easily render on the ball. I've also started work on machining a new enclosure, this will be more compact and more streamlined and made out of MDF and aluminium composite. It looks awesome in my head, but progress is hampered by my inability to drive a CNC well. Build log entries 20141210 20141230 20150103 20150107 20150107 (2) 20150110 20150116 20150124 20150626 20150629 20150701 20150708 20150711 20150715 20150718 20150721 20150725 20150731 20150801 20150802 20150803 20150806 20150807 20150808 20150812 20150813 20150905 20151101 20151105 20151107 20151115 20151122 20151130 20151207 20151231 20151231 (2) 20160111 20160208 20160710 20160714 20160815 Source code and hardware designs My git repository contains almost all of the details for this build. Design and implementation documentation. Part lists. Source code for the two four arduino microcontrollers. Schematics and board layouts for the printed circuit boards. 2D design files for the laser-cut panels. All under a couple of different open source licences, check LICENSE.md in the source tree. My documentation assumes some basic knowledge of Arduino and digital electronics fundamentals. I didn't bother drawing up schematics for the protoboards containing three switches with pulldown resistors, for example. Hopefully anybody who's completed a few Arduino tutorials or sample projects will get by. First build log This is still very much a work in progress, and there's some obvious controls missing just because I haven't yet figured out the best way to lay them out. These ones got done first because they were the simplest and easiest to lay out, and were a good chance to refine my method for producing the faceplates. After preparing hardware for a few of the sections, I threw together a quick mounting from 10mm perspex and a few M6 bolts. This let me lay down the basic firmware, and the panel's now in active use even though I'm still tweaking it. Because honestly, it's hard to go back to shift and control after that throttle. The panels are made from 3mm perspex, that I've painted and then etched/cut with a laser cutter. There's a longer writeup of how I'm doing those on my blog. I'm using an Arduino Mega 2560 to drive it, with a Mux Shield II to multiplex the inputs, because I was too lazy to string together my own multiplexer. On the software side, I'm using zitronen's KSPSerialIO mod to get telemetry from the game and send commands. My Arduino just communicates with the game over a USB connection. I'm trying to group the controls and readouts in to logical panels. Right now I'm designing attitude control panels, with a couple of small joysticks for translational control as well as toggles for SAS and RCS and strength adjustment. The other section in progress right now uses a couple of analogue gauges for vertical velocity and radar altitude, intended as a landing aid. Further down the line I've got plans in the works to add displays, and then I can start thinking about the size and shape of the final enclosure. Probably. EDIT: This is the panel for managing descents, with the gauges I'm planning on using. It still has the paper backing on the other side, making the lettering a little harder to read in this pic. The scales will both be logarithmic, with the vert speed covering -100 to 100 m/s, and the radar alt going from 0-10000. The switch will toggle between the radar alt showing metres or kilometres. Drawing the scales has been a big challenge, and trying to write efficient code for dealing with logarithms on an Arduino without an FPU even more of a challenge.

Hey everyone. I wasn't entirely sure where to post this, but here it is. I am - like many others - making a physical KSP controller. In my case, with my uncle on the "physical" part (soldering, connecting, wires, etc.). I'm doing all the "digital" parts. I'm using kRPC with python, connected to an Arduino mega, all using lawnmowerlatte's python to Arduino framwork, using a serial connection. Our first prototype is working wonderfully, and we're planning out the full thing (it's going to be big). The aim is to be able to fly a mission with one person being mission control - having the map view. And the other being the pilot - only having an IVA view of a window. Our current prototype: Prototype (how do you embed pictures?) This post serves not only to show you people what we've been working on (as we think it's very cool), but also as a few questions: 1. We'd love to upgrade with another Arduino at one point, running a little screen with a rendering of a navball, similar to this. How should we go about this? Are there any resources available? 2. We're worried that our endless Python loop will be running so many button checks and kRPC calls, that the delay on things like single button presses and 7-segment screen updates will be too much. Will this be a problem and/or how would one work around it? Thank you for reading -FP

I tried the Alt-F9 video recording feature that comes with my new Geforce card software, and found it really easy to use. I was hoping to have a dogfight thread where each participant record some of the videos, but was wondering how common is video recording capability in our community. Most people probably don't have dedicated recording software, and I don't either, so I was wondering how many people have Geforce Experience, and if you tried recording video with it? cuz I think Nvidia cards are pretty common these days.

So after seeing @richfiles, and @stibbons controllers, I've started thinking about maybe (key word maybe) making one of these things. Bear in mind that I have no experience with arduino, or anything other than wiring motors and lights to batterys. Here are my basic ideas. Please tell me if some really aren't possible. Kindle fire for streaming navball from Telemachus 7 segment displays for velocity, altitude, apo/periapsis Joysticks for rotation/translation Toggle switches for SAS, RCS, and etc keypad for action groups, maybe a gutted computer numpad Stage button, one of those buttons with the clear cover for abort action group Master caution, like when my ship reaches critical temperature I don't know if this is possibe, but a terrain alarm, with a button that would light up and yell "terrain!" at you, if the ship is under a certain altitude, going above a certain speed throttle lever ??? I might add more to this list, remember that this is all in my head, and I don't know all that much about electronics, so keep that in mind. The main problem about this is money, as I'm not an adult, and I don't have a job. I would love to make this dream a reality, but we'll see...

I have been working for the past couple of years on a project to create analog gauges that could display some of the game information. Finally, I also developed a program to display the ground tracks and flight profile. Both rely on the mod telemachus and its http server to get the necessary data. Here is the final result. I didn't spend much time on the board itself, as I wanted it to work properly first. The gauges display most ressources of the game (liquid fuel, oxidizer, monopropellant, etc...) and three other parameters: Gs, vertical speed and atmospheric density. I also used two 8 digits 7-segments display for altitude and speed since both these values can vary a lot in the game, it didn't seem appropiate to use the analogue gauges. I recuperated the screen from an old laptop to diplay ground tracks or flight profile. 1) Gauges The core of the gauges is a micro stepper motor X27-168. They are sold as automotive spare parts, mostly for US brands, and quite easy to find. There are quite a lot information about them, especially on Guy Carpenter blog http://guy.carpenter.id.au/gaugette/ The plastic support is 3D printed In order to control the motor, I am using an arduino Uno and the motor driver vid6606. Through my various trials these came to be the best solution. It gives smooth needle movement and is a very flexible solution to add/remove gauges. Each one of those can control 4 motors. The arduino itself is connected by USB to a raspberry pi that sends the http request and calculate the required position for each motor. I had initially tried to control all motors directly via the raspberry pi, but the result wasn't as good: when all values were updated simultaneously, some lag and stutter could appear on the gauges. 2) Ground tracks and flight profile I thought it could be cool to have be able to visualize the ground tracks of a vessel in orbit. Again this is using data pulled from telemachus. Some settings available: However, this is only good in orbit, so I was also inspired by the mod Houston and made a mode to display the flight profile when not in orbit: I initially wanted this to be also diplayed by the rapberry pi, but it wasn't as smooth as when using my laptop, so I finally gave up on that. It was the first time for me to code and I'm sure it could be made much lighter to work well with the rapberry pi though. I had a great time creating all this (more maybe than using it...), I hope you like it too. Let me know what you think!

Joystick I've made for flight sims. Works in KSP also. -Rotary encoder on thumb, for prop pitch, reset by pushing Switch for brakes -Trim sliders for pitch/yaw -Trim potentiometer for roll -Rotary encoder for radiator (outputs an axis reading, resets by pushing) -Rotary encoder for time acceleration Controller is Arduino pro micro. Hot glue is used to fix the part to the throttle. Saviour-tape to dim the Arduino lights. Nothing too special, but looks kinda kerbal.

"Kermander1000" ... another KSP kermand console cockpit thingy ! - Some time ago i wanted to build a control console for a farming simulator to drive tractors and combines, but kermanding a rocket is much more fun. While looking through possible solutions on how to extract data from KSP, i found the ready to use solution : KSPSerialIO (thx @zitronen ) This base frame has carried a flightsim cockpit for many years, hope its capable for space action: I have printed some panels with my 3D-printer, soldered some stuff and written some code into a MEGA. I will build some single modules which will be assembled into a console. Some useful and some senseless displays will be available, some switches do work and some will not. Imagine confused and even tough successful Kerbonauts The 'AnalogGauges2', 'StatusIndicator' and 'MasterIndicatorButton' (AG2, SI, MIND) are fully operational and already succeeded in many missions. The 'ActionGroupControl' (AGC) still needs soldering and coding work to be done. See the following pictures for an impression of my dirty workbench and the modules i'm working on : Could be that all those flashing lights could cause unwanted visual restrictions, i will add a 'No Light'-Switch somewhere

So I'm working on a project to create a custom home made controller for KSP using an arduino mega but I am very new to using an arduino and with talking to the game so I was wondering if anyone could help me with getting a single switch when flipped to progress to the next stage of a rocket (in my eyes this is on the easier end of controls to figure out but I'm a moron and even from my research I have been getting confused. I think I need to use zitronen's KSPSerialIO mod but I'm not sure this is what I need again I'm just looking for help with one switch to change one thing on the game (the switch is a off - momentary on type of switch so a "push button") Please and thank you.

I was wondering which SI prefixes KSP uses in game, and are there any that are skipped? I ask because I know it skips km on your altimeter... (I'm so wrong! i guess I must typically timewarp from LKO to any other body and never noticed Km before! LOL ). It just goes from counting hundreds of thousands of meters and then rolls over into, if I recall correctly, Megameters. After that, I know I've seen Gigameter measurements before in the map views. Does KSP skip any other units than km, or is it just that one unit that gets skipped? I think I recall seeing km used in map view for distance to target, and in standard view to show distance to other objects. I just don't know if km is used for any orbital data... Altitude, Apoapsis, Periapsis, etc. I'm currently in the process of building a digital orbital data readout to fit into a larger scale custom controller for the game. I'd like to keep the units displayed on the controller matching the units displayed on screen. It'd be disorienting to have my readout show 100 km, and the altimeter on screen say 100000 m. I know they are the same, but it's not consistent. I'm occupying myself with continuing my controller build, since my motherboard unfortunately died. It's hard to run KSP to check for units of measure when your computer ain't even functioning. Who knows... Maybe I can get some progress in before the motherboard is repaired/replaced. Adittionally, I also wonder how high do the SI prefixes go? I want my readouts to go as high as they need to go to cover whatever KSP can throw at it... m, km, Mm, Gm, Tm, Pm, Em, Zm, Ym... What's the largest SI prefix KSP actually supports? Are there any other prefixes that KSP tosses out due to the number of digits the altimeter displays? Does the map view use km for any orbital characteristics? I got some nice 14 segment alphanumeric displays that are smaller than my main numeric displays. They are at the end of each relevant numerical display, and will show the correct SI units. I can make the displays support all units (as well as "m.S" and "ΔV"), but it will require more work to add the extra characters. Don't ask me why, but I'm doing a diode matrix ROM for them. It'll be kinda retro, but extra work to have extra characters supported. So... yeah... Just curious if I should plan on supporting them? Thanks in advance. *UPDATE* So, apparently, I am just blind. I never noticed the use of Km as an altimeter measurement, likely cause it occurs in a range that I rarely orbit at (or stay at for long). I can salvage this post though, as now I need to catalog the transition points. Where does KSP switch from m to Km, Km to Mm, Mm to Gm and so on. When I get my motherboard back from being serviced, I'll fire up KSP and check it out, recording the transition points here (unless someone beats me to it).

i am resuming an old project i had but did not document. it was to make a custom ksp cockpit In Real Life and use it to play the game. there was also a mission control. it wasn't that good. my new version will feature a 2 person cockpit, electronic flight instrument system, switches, and buttons etc. there will be an external mission control as well. i will document all my code and mods that i use so that if any one would like to try and build it them self they can. 1. design phase main switch board images SAS mode light board: Control section Engine control section i'm going to add a fuel pump section that will not let my engines start till the fuel pumps are switched on

KONRAD is Yet Another Telemachus Frontend. It's a curses program, so each console is a character-cell display in an 80x24 terminal. (It's aimed at Linux, but ought to work on other OSes - no guarantees though.) It can be found here, on GitHub. It's designed to be useful for co-operative "mission control" streams like Real Space Program or Go For Launch. Here are screenshots of the current consoles, taken during an Atlas-Agena launch (in Realism Overhaul): Obviously you will need Telemachus in order to use this. You will also need Python and curses, and a terminal emulator. An adjunct to KONRAD is the JSON Booster file format, used for describing a space vehicle in sufficient detail for the Booster Dynamics console to give up-to-date delta-V readings. It's fairly simple (some examples are included in the repository), but does currently have to be created by hand. It's not too hard to do: just take your vehicle apart into stages, count up the propellants in each, empty them out, and read the dry weight and engine (vacuum) Isp. For parallel-staged designs a little more cleverness is required; the included MercuryAtlas example shows how to do it. Basically, you have to guess (or measure in simulations!) how much of your fuel will be left when you stage your boosters away, and that's how much you record as being in the core stage. If you try and use asparagus staging it'll just completely fail to work; it can currently only reliably cope with at most one 'horizontal' staging event per 'vertical' staging event. (I have some ideas for dealing with this, but won't bother unless it turns out people actually want to do that kind of thing.)

Here we go again. I built a hardware controller for KSP a year ago using KSPserialIO by zitronen, and was pretty proud of it. However, it had several construction flaws, based on my complete lack of practical knowledge of electronics, and during autumn I started shopping for parts for a replacement. I learned about shift registers and display drivers, and started to build a 7seg readout, but eventually abandoned the idea. I used shift registers to replace the internals of my first controller, but around Christmas it started to give out. I think I burned some pins through excessive drain, and connection became a matter of luck around the advent of 1.0. But then end of semester came pressing, and the project went on back burner until May. Now, however, all exams are past, and I have used my spare time to plan, test concepts, and do the initial woodwork for a second generation flight control panel. Following features are planned. Included features from the go: Separate unit housing dual joystick and two single direction joysticks, throttle and stage button. Included is a rotary knob to adjust strength of RCS as well as attitude. Stage comes with a lock and red/green status LEDs 144 x 80 7" monitor. Holds a max of 10 lines of text, possibility of simple graphics. This is going to replace the HUD1 unit from KER, a long standing ambition. Keypad to specify exactly what will be displayed on the monitor. Toggle control for action groups, SAS, RCR, light, gear, brakes. All toggles have a red/green single LED to indicate status at a glance. Lockable big abort button. Pushbuttons for map, camera, cycle active ship, time warp. These are done by wiring up a USB keyboard controller, as they cannot be controlled by KSPserialIO. Select rocket or atmospheric craft control scheme: This will switch roll and yaw controls, depending on whether I need to fly an airplane (roll on prim joystick), or a rocket (yaw on prim joystick). I might include a separate mode for rovers as well, but they handle pretty well in the rocket config already. Analog gauges for Charge/Current, Fuel, Monoprop and Radar Altitude (3/30 km, log scale) Warning LEDs for speed (slow/fast on descent and ascent), ressources, temp, connectivity. These will be done in red/green single LEDs. Additionally, I have following ideas: Recalibrate joystick on the fly by keypad. (Hard as it does not scale linearly, but doable) Advanced input to the monitor: While I initially just aim for ten default display schemes, I want to customize the output on the fly, using some input scheme. This takes inspiration from the various DSKY projects out there. Rotary knob for selecting SAS control scheme. This hinges on zitronen including it in KSPserialIO Limited autopilot functions, most importantly an optimal descent assistant for vacuum environments. Ascent velocity assist for atmospheric takeoff is desirable, but until I get my hands on a proper drag coefficient calculator for my craft, it remains a wish. A way of calculating the correct orbit to hit a waypoint for a contract, taking into account the rotation of a given body. All of these should provide plenty of time to waste on the project. Shouts should go out to zitronen for making this possible, MrOnak, Mulbin, AmeliaEatYaheart, stibbons, T.A.P.O.R., Sputnix and everyone else who posted a question or an answer in the KSPserialIO thread, as well as the highly inspirational controllers you have shown to the rest of us. Current status: The flight control unit is done. It communicates with the main unit by an old SCART cable, with a few pins to spare. The big red button is staging, and just above it the lock in active position. After this picture was taken, I added a rotary potmeter to scale the input of the joysticks. A view into the unit. You can see the primary and secondary joysticks, as well as the small board routing the input. Originally I wanted to use a VGA connector, but it turned out that I ran out of pins, and had to replace it. The joysticks are artifacts from an ancient age. A gameport joystick for attitude, and a C64 digital joystick for RCS. The monitor. The main panel is build as a frame with bolted modules for easy service and replacement. The individual modules are painted black, and the frame the same grey as the controller. While a lot of modules around here are made of fine looking materials like printed dibond, 3d prints or aluminum, my budget says plywood. Labels will be paper prints in negative, with a bit of touch up around the corners once fitted. The monitor itself has kept me occupied for the last couple of days. The TVout library is very processor intensive and interupts the timer of the Arduino, so I dont think it is going to play particularly nice with KSPserialIO. The solution I use is to use a spare Arduino Uno (clones come at less than €10) and transfer bytes over 8 pins from my Mega to the Uno. I cannot use SPI or I2C as a sane individual because TVout hogs the SPI pins and interrupts I2C, but after some fiddling and a full day of not being able to communicate with my family I got the results I wanted at some 20 FPS, enough for practical use. Last unknown part is the keypad, but glancing at the documentation it does not seems so difficult. Then, it is just a matter of connecting the parts and writing the actual coding af the Arduinos, but that will not require anything but stuff I already have tried before by now.

KSP runs reasonably well for me right now. However, sometimes when I'm in a high part-count scene the frame rate I'm able to draw drops down to about 20fps. This isn't horrible, but it is noticeable. I'm considering upgrading some components. However, I'm not certain if the bottleneck is in the CPU or GPU. Is there a way to easily find out which is the constraining resource? - Garrett

I would love to see support for a multiplayer mission control style interface, where people online or on a local network could view your map and telemetry information, and would be able to plan maneuver nodes and send them to the pilot. This would allow for easier KSP Mission Control parties and I think would be a huge hit. I know some mods provide similar functionality, but they've been very difficult to get working, and seem hacky at best.

Hey there! I'm Cannon, the developer of KSP: Houston, and I've been working on a fork of Telemachus that supports 1.1+ and adds various endpoints that I need to grow Houston. Unfortunately, the canonical version of Telemachus appears to be abandoned. Issues and pull requests aren't being responded to, and the original developer isn't responding to inquiries. I'd like to coordinate and consolidate new development on Telemachus into a new repository with active maintainers. This would make the mod better for everyone: right now the current canonical version of Telemachus is broken for 1.1+ and new features can't be added. On top of that, I'm having to package Houston 1.0 with my forked version of Telemachus, which will inevitably lead to confusion later down the line. The forked version is here: https://github.com/tcannonfodder/Telemachus If someone could give me some guidance on the proper way to go about changing maintainers that would be awesome. Off the top of my head, I know the following things need to be changed: CKAN listing Curse listing The forum post for the mod Also: If you, or someone you know, has been working on Telemachus or is interested in helping it grow, let me know! I'm looking for active maintainers to help it grow! Thanks!

Well this thread is inspired by this cute video thumbnail, generic theme and lyrics: Mister Trouble never hangs around When he hears this Mighty sound. "Here I come to save the day" That means that Mighty Mouse is on his way. Yes sir, when there is a wrong to right Mighty Mouse will join the fight. On the sea or on the land, He gets the situation well in hand. rule: pretty simple share stuff about your mouse and eventually comments about yours or others contributors mouse keep things fun and cool. (non mouse users are welcome to because well evolution is like that ; ) 1 - : Mine really start looking like this and this are it's best friends because well getting old is hard even for a computer mouse but who said lifting rocket in ksp is an easy task ? ; )

Hi there! Some mates and I participated in this year's SpaceApps contest by NASA on the Jet Set Mars challenge. We focused on developing a complete solution for a Mars-suitable jetpack which included an exoskeleton and a custom HUD. It seems NASA liked it, because we are currently Top-5 on Best use of Hardware category. Aaaaaand, of course, we used KSP to simulate it! Here is the video: https://www.youtube.com/watch?v=fwtIp6Wt2hk The official NASA project page: https://2016.spaceappschallenge.org/challenges/tech/jet-set-mars/projects/mars-upv Our website: http://www.marsupv.com/ In our prototype, the helmet included a IMU to sense the orientation of the wearer's head. This information was then sent to KSP via a custom HID USB device the game interpreted as a joystick input. Besides the helmet movement, our prototype had two joysticks which enabled full use of KSP's EVA functionallity (and the prop-pack reacted moving the nozzles and illuminating) Hope you like it! Germán PS: if you want to see more, our github repo is on NASA's website. We are part of http://www.makersupv.com/, a student community on the Universitat Politècnica de València, Spain.

Current Progress Shot List of posted updates and developments - Mid-May (2015) update - Annunciator Panel mount, Shift-register board, and dual-coloured LED panel mounting - Mid-June (2015) update - Completed 3D printing upper panels with black spool - Late June / Early July (2015) update - completed testing of LCD + 7 Segment displays, finished wiring, began writing the code / testing [lots of internals stuff, SPI issues] - Mid July (2015) update - Labeling the panel + Annunciator - Mid July (2015) update #2 - Master Alarm system Arduino Code / sketch samples Here you will find some sample code that will hopefully help others out with problems they're having, or implementing certain features without getting to the point of wanting to put your head through a wall Previous Development Photos Credit I have to give much credit to zitronen- For the work he's put into creating the plugin that many of us are using to create these controllers, and the support given not just to the plugin, but also with general arduino problems / queries! Thank you! T.A.P.O.R, who personally helped me to get my head around the 7-segment LED screens, along with some additional insights shared. Thanks heaps! Freshmeat, & stibbons, who often (and regularly) have something incredibly useful to add - or assist when the going gets tough, and nothing on google makes sense -- Thank you! Also, credit to AmeliaEatyaHeart for creating the LedControlFunctions 'function', and for various insights shared in a variety of threads; thank you. Mulbin & Marzubus - whose own hardware projects inspired me to start my own. Outside of these two, every other hardware project has provided guidance / inspiration / ideas of some kind. So thank you to everyone in this community sharing their own ideas, interpretations, and struggles. We all benefit from them! Specific Feature Credit Whilst reading different forum threads, various members have commented or made suggestions of elements / features that they want to include in their own projects; some of these I quite like, and wish to incorporate too. I shall provide credit here - with a link to the post - in acknowledgement. Mulbin - dual-coloured LEDs to display more information about the state of the craft. AmeliaEatyaHeart - Flickering panel lights when low power ************************************************************* Background & Long-term project I would love to eventually create a fully immersive simulator, which would have two components: A mission Control, with projector and a few consoles, and a 'shuttle' / cockpit. The two would be separated by a wall, of some kind - and then there would be communication with headsets, which would increase delay to simulate real-life distance delay. No idea if I'll ever get there, but a guy can dream So in the mean time, I will work on a smaller-scale personal physical console for use whilst playing KSP. I'm still debating creating joysticks - as my Logitech proves to be ridiculously useful for that stuff; so why re-invent the wheel? Build, Parts, Plans & Ideas eBay Parts list

Hey guys, I'm looking at getting myself a Das Keyboard to replace yet another keyboard that I've abused to death. I'm pretty sure that it will suit me (coder and gamer) but I wanted to get some feedback from someone who actually has one and uses it in anger (or at least under duress). In particular I can't decide if I should go for the Cherry MX brown switches (softer) or the more "clacky" Cherry MX blue. They say that the blue is good for increased typing speeds, but I'm just not sure if I want that much clack! Other Q's I've got. - How easy is it to clean? do they keys come off easily or do you feel like you're forcing a flimsy plastic clip each to you take them off? - Is it as tough as it looks in the pics. Could I defend my office with it?! - something I look for in IO hardware - Any Linux users know if the media keys work out of the box, or if that requires some key-mapping. Thanks!

Using an ESP8266 and Telemachus to create a WiFi Kerbal controller. I'm mostly focusing on buttons here, since tablets work great for display. Currently just a proof of concept, it connects over WiFi so you're no longer tethered to one computer. Source and a compiled binary available on Github

I'm looking for a mod that uses Telemachus to display an orbital map like this on the web browser Something very similar to the orbital display you get with Raster Prop Monitor, but with the ability of displaying it on another device via web browser. I know that Primary Flight Display has an orbital map of sorts, but it's pretty small and on the corner. And KeRD's orbial map just plain doesn't work for me at all.