Currently I have created a 1 control prototype. I am working on a more extensive draftboard prototype to be cut on my friends laser cutter. Final version will be cut on spray-painted transparent acrylic to allow backlighting.
So the second circuit I tried to lay out was the vibration motor circuit. I used one that is fairly typically seen online with a diode and a small capacitor in parallel with the motor. My motor turned on, but I realized pretty quickly that it was going to be difficult to make the sort of effects I want.
Instead, I will probably use a haptic motor driver, which seems to be the usual response. Otherwise, I think I'd end up running in to weird timing issues, and I want to save processor speed for serial response as much as possible.
PCB development is ongoing! After talking to the amazing Kicad forum people about how to design an amateur-friendly PCB without soldermask, I was convinced that I should just send a design to a board house. This means I want to be extra sure my circuits work, which means prototyping things on breadboard.
Parts of the circuit I'm quite comfortable with (I2C I/O expanders, switches with pull-up/pull-down resistors). BUT there are two parts that are a little less comfortable. One is the vibration motor, which I'll address next time. The other is LED control.
My design calls for some LEDs to be driven off the arduino directly for maximum fail-safe capability in the event of a hardware problem (power, error, overflow). Other LEDs are to be driven by ULN2803A darlington pair arrays. The basic premise of these latter is to allow the microcontroller to control logic while providing steady current (and avoid drawing too much current through the controller chips and burning them out.
Now, the complications are that we also want:
A PWM dimmer control wire that is common to all LEDs on the board.
A 'lamp test' circuit that turns on all LEDs through a hardware switch when pressed.
The latter is easier. We just use diodes to provide alternate current to the anode when a button is pressed, which effectively over-rides the arduino pin. You need another set of diodes connecting the arduino to the anodes, so that you don't short out the arduino pins (fun fact - my arduino didn't burn out when I did this the first time, but it did cause flickering when the lamp test was on). In the case of the ULN, you can hook up the common emitter pin to ground the switch. When the switch hooks to ground, the common emitter is grounded and all the LEDs light.
The PWM is more tricky. For the board controlled lights, you can just map an analog in to the PWM pins and, presto, you're good to go. BUT I don't have enough PWM pins to drive every LED. Instead we use some transistor trickery to turn off the ground pin on the ULN using a common PWM pin. Full disclosure: I don't fully understand how this works and, like a lot of my project, it's cribbed from Petewasere's github page.
OK so I bought an adafruit metro mini so I don't have to unplug my arduino from the panel (almost got the M4 version, but I wanted an equivalent). I soldered on the pins and plugged it in my breadboard. My soldering is decidedly just ok:
Look at those blobs! Seriously those this thing is great for breadboarding.
I'm going to spare you a lot of the troubleshooting. Here's the final circuit in fritzing (which I'm not using for PCB design, but is (somewhat) helpful for breadboard illustrations:
Code is pretty simple. The only complication is that you have to sign flip the PWM signal for one set of LEDs for another. I'm pretty sure I could get around that with a PNP transistor, but I don't have any (edit: yes this totally works!).
Good news, no major problems with the panel. It now looks like this:
This led me to start thinking in more detail about how to actually connect everything. My original plan (at least for the prototype) was to use stripboard, and I spent a lot of time today looking in to stripboard prototyping. Unfortunately, when I got home to start doing that I realized that several of my components simply won't work with veroboard because of pitch problems (in particular, the game controller joysticks used for camera controls, and the resource lights. It's possible that, If I'm going to have to use PCBs, I should just use them for everything. I have an old kicad file describing some of the circuits, and I can fab things at a makerspace nearby.
More fruitfully, I spent some time thinking about wiring. I was going to just solder wires to headers, but the article above said I shouldn't do that. A little googling and I realized I can get JST connectors to use with ribbon cable, which will be much neater.
Just finished lasercutting my first solid prototype on my friend's glowforge! For those not familiar: you start out making a vector drawing in inkscape, then upload it to a web app. Specify which colors are engrave and which cut, and press the button. I used the excellent Tabbed Box Maker to build an enclosure. I tried to cut it so that the top (with the switches) could hinge out from the rest. Here are some pictures:
There are a few issues, justifying the prototype status:
The final product ended up a bit bigger than I was visualizing it. I may be able to shrink it during development, but the extra space will likely be helpful for now.
The space/rocket switch isn't labelled.
The screw holes for the arduino aren't quite big enough.
I didn't cut holes for the tabs in the rotary switches. These are designed to keep the base rotationally fixed, and are required for them to sit flush with the panel.
The rocker switches I use aren't reacting well to being squeezed in the long direction - they are a bit stiff.
The box is a bit flimsy - it would have helped to make it deeper, and/or to build in some crossbars. This will also help with the feel of the buttons (since the panel flexes a bit atm when you press).
Still - it's looking pretty good! The action group buttons fit perfectly.
Over the next few days I'll go through the different parts in more detail as I put it together, and I'll finally talk about how I picked parts.
I'm going to skip over some things, since I've already done this.
First, I forked PeteWasEre's github repo for the kerbal controller. I took out all the autopilot code (not using it), and changing the formatting in the gui to confirm to my bizarre aesthetics (mm ambervision monospaced fonts).
My first try getting the code working, I just wanted to get a throttle working (that was hard enough). Then I set up an initial prototype box to start playing with layouts and also start figuring out how to use the multiplexer chips I would need:
I also started working on my part list, which let me plan out what components I needed to buy and (more importantly at this stage) how many digital and analog pins I would need for them. This let me figure out how many multiplexers were needed (lots).
(This is well and done at this point - just documenting process)
The first step of this project is to decide what you want to do. The first thing you want to do is answer your why question: What do you want your controller to do? Put another way, how do you want to expand your experience? A few reasons people seem to do this:
Problems with the keyboard/mouse control you want to solve.
Different kinds of output not usually available?
A more immersive gameplay environment
Playing the game in a different way (for example, splitting up jobs between different people).
For me, I was primarily interested in augmenting my controls, and somewhat interested in immersion. I wanted to turn SAS on/off by mode, and I wanted joystick control without on-the-fly configuration of plane mode/rocket mode and without losing the ability to make precise gravity turns on one axis. I also wanted lots of buttons, because they make things fun. I wanted a few indicator lights and such for immersion, but not too many - because I usually play the game with different levels of output available on screen (eg. resources on/off, kerbal engineer on/off), and I didn't want to break that.
Once you've thought about why you are thinking about this, take a look at what some other people have done. There is a thread on the ksp forums with a pretty comprehensive gallery. Scroll through and see what you like. This should help you answer some more practical questions about how to satisfy your wants:
What kind of outputs do you want - do you want 8 segment digital displays, or do you want lots of dials to spin uncontrollably before you crash?
Do you want controls, and if so which ones? Do you want to map everything, or just make a panel to supplement your keyboard input?
What kind of form factor do you want? Something to replace the keyboard, go over the keyboard, or do you want to build it around the keyboard? On the extreme end, do you want to build yourself a proper simpit?
What kind of visual style do you want? Are you trying for something aircraft/apollo like, or do you want something more cartoony and fun.
Keep in mind some of these answers lead to more complexity than others. Personally, I was down for complexity, but I didn't want to buy any expensive dials, and I didn't want to end up with something too large. I did want something that would involve as little keyboard input as possible. I like the apollo-like look.
I found two panels that I really like. The first is a panel by PeteWasEre, which I particularly love because it is comprehensive the way I want, and it is well documented by someone who knows what they were doing. The second is a panel by ajden I found later on, which is lovely, but has more outputs than I probably want.
You'll need a list of components (see next post). You also need to pick a microcontroller (I'm going to use an Arduino duemilanove I have lying around for financial reasons). FInally, you need to pick a kerbal plugin to interface with. PeteWasEre used krpc, and I want to steal the code, so I'm using that. Other options are KSPserialio and kerbalsimpit.