Freshmeat

For me it is definitely the fun of building it, the extra functionality and the potential money savings are just an excuse. And it had the convenient benefit of teaching me a lot of practical electronics.

From original idea, a couple of months. Actual time spent construction and coding is estimated some 30 hours, starting from "What is an Arduino?". As I said, zitronens thread is extremely helpful, and I made a foot pedal board for DayZ from an old keyboard and some game switches last year, so I had some know-how. The price tag ended rather hefty, because I had no electronics parts to start with but my soldering iron. I had to get wire, resistors, leds, everything. I did not know about cheap alternatives to the original Arduino brand (Mulbin uses a Fundino with good results). Further, I changed design a couple of times, so I have some stuff left over. That, and bying locally, ended up at a €150 price tag. If you go EBay and have a bit of equipment to start with, I reckon it would be half that. I plan to do an upper bar for controlling action groups and a couple of displays, and I think I can do that for €50, even including a clone of the Mega board. @smalldiaphragms: There is absolutely no space left under the hood. I mounted everything on the backside of the panel for easy acces and hardware debugging, so the area in the middel is the Arduino, below the blue buttons is resistors for the swithes, above them resistors for leds, the entire right hand side is the gamepad and my joysticks. For some reason yellow notes have problems sticking to the surface. I found out during debugging, when I tried to use it to label my switches. Snacks, however are always within reach, and the design includes enough space for a cup of coffee or glass of wine beside the setup.

@Moeggz: If you do a setup like mine, I can send you the code I use, if it is OK with zitronen. And a couple of small debugging pieces of code to figure out what you need to change. I go on holiday in a couple of weeks, but afterwards we can probably figure it out. @MR4Y: I originally wanted to do a throttle, but this setup gives me finer control. If you want a throttle, you just use a rotary potmeter with a stick instead of sliders. It could be done as standalone in a couple of hours and the time it takes for paint to dry. The code would work out of the box.

So, I made progress: http://forum.kerbalspaceprogram.com/threads/84672-My-homebuild-controller-for-KSP-%28Picture-heavy%29?p=1242766#post1242766 Thanks for all the help, I'll come running back when I have money to spend on a display unit.

Soon after starting the wonderful adventure of Kerbal Space Program, I plugged in an old Logitech Dual Shock controller, as the keyboard was quite inadequate for fine control. A gamepad, however, does not come with a throttle, and the only separate throttle I could find was a Saitek priced at €100 However, it turned out that forum member zitronen had made a plugin for interfacing with an Arduino board: http://forum.kerbalspaceprogram.com/threads/66393-Hardware-Plugin-Arduino-based-physical-display-serial-port-io-tutorial-%2804-May%29. As the school where I am teaching bought some Arduino boards half a year ago, this could be a chance to finally learn to program the little buggers. If it turned out ok, I could invest in hardware myself, otherwise no harm would be done. Initial tests quickly decided that a throttle could be build in about 10 minutes, using already supplied code from zitronen. But his program hinted at several other interseting functions, so I started planning, buying, wiring, coding and learning a lot about the Arduino, eventually ending up with this: This controller is made of an Arduino and the aforementioned Dual Shock that gave its life for the advance of all Kerbalkind. It has following functionality: Yaw/Pitch/Roll control. The Roll is the stick above left joystick. More on that later. Throttle slider with additional fine tuning slider far left, and killswitch. Translate all directions. Right joystick plus stick right hand side. RCS, SAS, Precision control, Light, Gear and Brakes controlled by switches. A led above the switch light up when function is activated. Pushbottons for Stage, Abort, Time Warp, Map mode and Camera control. Analog meters for Monopropellant, Battery (Either remaining charge or current drawn), Fuel (liquid or Xenon) and Radar Altitude (3km or 30 km max) Warning lights up upon a fast change in acceleration. This is handy as it always happens when a stage burns out. A pushbutton resets the warning. Warning lights up if either ascent or decent is going to fast or slow Ascent is measured against atmosphere terminal velocity, selectable by planet on a slider. Descent is to fast is you need more than .9 of your max acceleration to get to 0 m/s before you hit ground, or more than 7 m/s at less than 100m. Same slider as before also is used to indicate your acceleration (=(TWR-1)*g_current_body). Three additional warning lights and two pushbuttons are yet to have functions assigned. The layout of the wiring for the arduino is as below: This is the solder points on the gamepad: Turns out that 3 and 5 are same, as well as 8 and 9. Also, a few buttons is missing in above table, but the principle is far more important than the actual numbers. Had I needed more buttons, I would have torn apart a keyboard from a junkyard, locally they go for around €4. Anyway, it is fairly straightforward to solder wire to the points, and then to the relevant pushbuttons. Two microswitches sit on either side of the small wooden stick that controls RCS forward/back for a digital joystick. My workbench: Mounting is done after painting, so the board is lifted on blocks covered in cloth. I have no acces to PCB, so the resistors are soldered to nails in a chipboard. Surprisingly, it works. I am very happy I invested in ten different colors of wire, though. Note the wires soldered to the gamepad as described above. The onedimensional roll stick was made of a 10k potmeter, springs from a couple of ballpens and some wood: Assembly like this: It is a bit hard to control, I think that a better rounding of the bottom would have been good. Perfectly adequate for roll, though. Above label is printed on some label sheets I had lying around and cut to size, The transparent labels are made with a DYMO. The box itself is wood, the top is paneling of some kind bought cheap in a DIY shop (a miscut, got 50 cm x 150 cm for €4), spraypainted with grey primer. For code, I took zitronens code and modified it to my own use. As they are, they are hardly useful for anybody, but a few things to note: The switches are set in groups in parallel, each with a unique resistor. That makes it possible to read a value on an analogue pin and assign the relevant controls for the activated switches. In order to activate diodes, a given control is activated when the circuit to the analogue pin is broken. I bought my meters as very cheap (€3) analog meters 0-1 mA. The turned out to react nonlinear to a PWM pin, so I made a few readings of PWM vs meter and made a 5th order polynomial fit. Works fine. Additionally, the radar altitude is on a logarithmic scale in the code to cover precision at low altitude with higher range. The change in acceleration is checked by storing current acceleration every 100 ms. The program checks against the previous value, and if the difference is above 0.1 G, the warning led is turned on. I tried to make and exception if the throttle had been moved, but for some reason it does not work. Investigations pending. Change in battery level is done against last packet, and divided by gametime since last packet. The ascent warning is done in a piece of code like this: if (WarnSelect == true && 6*planet[planetSelect][1] > VData.Alt){ //-----------Only for low altitudes if (VData.Vsurf > 1.1*sqrt(912400/planet[planetSelect][0]/pow(2.718,(-VData.Alt/planet[planetSelect][1])))) { digitalWrite(VHLED,HIGH); //------too fast digitalWrite(VLLED,LOW); } else if (VData.Vsurf < 0.9*sqrt(912400/planet[planetSelect][0]/pow(2.718,(-VData.Alt/planet[planetSelect][1])))) { digitalWrite(VHLED,LOW); //-----too slow digitalWrite(VLLED,HIGH); } else { digitalWrite(VHLED,LOW); //-----just right digitalWrite(VLLED,LOW); } } int planet[5][2] = { {66,3000}, {293,7000}, {1874,10000}, {100,5000}, {99,4000}}; the planet[][] array is acceleration of gravity divided by ground level pressure, and scale height ot atmosphere, by planets with atmosphere. The wiki has more information on the subject:http://wiki.kerbalspaceprogram.com/wiki/Atmosphere The descent code looks like this, and continues above if statement: else if (WarnSelect == false && 6*planet[planetSelect][1] > VData.Alt) { //----------Low altitudes only if (abs(VData.VVI) > 0.6*sqrt(2*maxAcc*VData.RAlt)){ // Too fast digitalWrite(VHLED,HIGH); digitalWrite(VLLED,LOW); } else if (abs(VData.VVI) < 0.4*sqrt(2*maxAcc*VData.RAlt) && VData.RAlt > 100){ // Too slow digitalWrite(VHLED,LOW); digitalWrite(VLLED,HIGH); } else if (abs(VData.VVI) > 7 && VData.RAlt <= 100) { //------- Very low altitude digitalWrite(VHLED,HIGH); digitalWrite(VLLED,LOW); } else { digitalWrite(VHLED,LOW); // Just right digitalWrite(VLLED,LOW); } } //-----------Descent warning--------------Note: VVI is negative downwards, hence abs()------- The relevant check is Galileis law of falling bodies, with some factors in front for safety. I might change the 0.6 and 0.4 to get more fuel efficient landings when I get more comfortable with the system. It goes without saying that I could not have done this without zitronens plugin, nor his fast response to my questions. Another great source of help was reading Mulbins posts in the same thread, as he asked the questions I needed to before I even thought about them, as well as his own kick-ass controller: http://forum.kerbalspaceprogram.com/threads/66742-Custom-hardware-control-switch-panel-simpit-WIP Further inspiration was found in Mulbins thread on custom controllers: http://forum.kerbalspaceprogram.com/threads/66763-Custom-hardware-simpit-repository-For-people-who-take-KSP-a-little-too-far?p=920499#post920499 For people thinking this was an achievement, I would say it is a lot of individual components, but each component is pretty simple. The circuits should be understood by any high schooler, and the programming is dumbed down C, with plenty of examples to learn from on the Arduino homepage. So if you want to, just do it.

It is not the 1k resistor, it is having a bunch of them in parallel. I had 3 circuits going as low as 330 ohm each in parallel -> 100 ohm effective resistance I ought to have seen that one from a mile away. I changed the resistors this morning, going from 100-670 ohm to 3300-15000 ohm, and added a 330 ohm more between the leds drawn directly from +5V. Now the resistance behaves properly, and I can continue debugging my software.

I will not go into space today........ My build was going along fairly nicely, and most of the coding was done when I discovered a fatal hardware weakness: To increase my amount of switches, I ran groups of four through different resistors in parallel, reading the results on the analog pins. However, when I throw a switch, the increase in drawn current is enough to disturb the reading on the other pins. As it stands, most of the basic functions will work without fail, but the advanced ones disturb one another. While this is pretty kerbal, I would like my stuff to work every time. I guess it is time to look into pin extender chips. Thought: Will it help to scale the resistors up? The ones I am using is in the 100-1k range, and could be changed by one or two orders of magnitude once I get new ones.

Thanks for the reply. I just need to know if any engine is out of fuel, but others might appreciate the number. After some testing, I have designed the circuits and the actual physical design is taking form. I have no access to print boards, so nails, wire and chipboard it is. Will show pictures when I have something to show.

Problem: I would like to use the fuel per stage to stay in map view during ascent. However, it does not work on rockets with asperagus staging, as the game reports fuel available to any active engine. When your outer rockets burn out you will not see this in the fuel gauge. Workaround: I plan to check for change in acceleration occuring without change in thrust. This will give some problems with RCS, but better than nothing. Request: Is it possible to check for active engines not producing thrust?

Guilty as well! I'd like to add my own: After crashing a Mun lander (see "Altitude", above), I sent out a remote controlled rescue capsule. I got it into transfer orbit and warp. When it gets to the Mun, there is no power left, which rather surprised me as I used the exact same rocket mark the succesfully had carried the original lander. Took a while to realise that remotes use electric charge constantly....

You spend five times the amount you spend on the game on components for a control panel, and finally learn to use an Arduino board.

Thanks for the fast answer. I referred to the controls defined in your MainControls byte. The original plan was to control these by keystrokes on a keyboard. However, while writing I realize that if I use a pin for a LED, I could just as well use it for a switch and activate a LED with the switch as well.

I am starting to dabble a bit myself, as I was able to scrounge up a few parts. My plan is to use an Arduino mainly for controlling LEDs and a thruster. An old keyboard chip will control buttons, which I have experience with already. Looking through the vessel parameters, it seems to me that you are unable to read the current status of the main controls, only set them. Is that so?