[WIP] H.O.T.M.A.S. Project

[FastMINI42]

For the last couple weeks I've been working on the final design and ordering parts. The final pieces coming Monday, and should be able to start assembling everything next week. In the meantime, I've been bread-boarding and working on figuring out the shift registers that will drive keyboard matrix. I don't have a breadboard big enough for both, but it should be fairly simple to tie it all together.

Shift register for the columns uses two 8 bit serial to parallel registers. For now the column outputs are just connected to LEDs:

Shift register for the rows uses two 8 bit parallel to serial registers. I was able to squeeze in enough buttons for a small WASD keyboard. I was able to control a ship with this tonight:

I've been interested in a HOTAS setup for a while. After looking at a few, I started noticing that they are geared more for flight sims and don't seem suited to all the different KSP modes (mostly not enough buttons): KSP uses the mouse a lot, especially in map mode and I feel like I would be letting go of the stick to operate the mouse or letting go of the throttle to use the keys I couldn't get mapped to the Joystick/Throttle a lot. To be honest though, I think I'm just looking for any excuse to over complicate something and start a project.

Anyway ... I now have a joystick and the last couple weeks I've been thinking about and sketching out ideas for the throttle part of things. It will have 3 main functions:

1.) Throttle control via an Arduino Pro Micro

2.) Mouse inputs via the same Arduino Pro Micro (the "M" in H.O.T.M.A.S.)

2.) Button / keyboard inputs via an Arduino Teensy for general function and secondary controls for docking (translation only), docking (linear & rotation), EVA activity, and rover driving. The controller will have different modes to remap some of the controller for the different secondary controls.

The Pro Micro and the Teensy will be connected to a Leonardo via I2C. The Leonardo will then pass all the throttle/mouse/key-press inputs over USB to the computer.

Below is a (preliminary and crude) sketch ... I'm still working on some final layout. The biggest issue right now is I can't find a small panel mount trackball that isn't horribly expensive, so I'll likely be using a thumb joystick instead (same thing with 4 way + center button castle switches, I may need to just use 5 push buttons for that). I'm also looking at using actual keyboard switches and key-caps instead of round push-buttons.

This is what I've got going so far:

1.) The main body will be an 8 x 6 inch project box.

2.) Different control groups will be on other project boxes tacked on top to make it easier to find things without looking (and to make it look more like something found on the side of the road). Throttle controls will be on the far left, the mode selection will be on the small one on the top right, docking & movement controls on the one on the side, and the mouse/general controls (map mode, time warp, quicksave, etc.) on the main body. Action group switches will be a row of big toggle switches on the front.

3.) The navigation switch on the right will be a thumb switch or something similar, and will be used mainly for docking, EVA maneuvers, and rover driving. Their will be additional controls on the back of this box for up/down directions, SAS/TCS, etc. (imagine your hand curling around it like a throttle control on a regular HOTAS)... this part is the least roughed out.

4.) There will be a big red panic button for the abort group action group, the bigger the better. I don't have them on this sketch, but there will also be a couple toggle switches with red covers to enable & disable the throttle and staging button.

5.) I've found a source for key-caps that has different color options, so all the keys will be color coded (dark blue for function keys, dark gray for flight inputs, white for SAS, bright green for RCS, dark green for general operational/mode keys, something like that). The LED indicators for the 4 modes mentioned in #3 will also be color coded, and color coded labels will be used for the multi-use controls.

6.) Since it will be all custom built, there will be a few special features. A fourth mouse button that will be the same as Alt+RMB, a button that will toggle between RCS & SAS, and a selector to scale the throttle (0-30% or 50% instead of 0-100%, I think that will make for a more precise throttle for easier landing), to name a few.

So that's what I have so far, comments/suggestions/advice all welcome & appreciated . I did some work on writing code for a keyboard matrix scanner last night on the Pro Micro, so my next step will be to get the parts and build the keyboard scanner. I haven't done any programming in a long while, so the project will be slow going. It should be fun though, this is my first time working with Arduinos.

Edited October 17, 2015 by FastMINI42
10/17 Update

[Glaran K'erman]

Any project that brings more switches, toggles, meters, readouts, and overall awesomeness to KSP gets my approval.

[Rosco P. Coltrane]

I'm curious, why three boards?

Edit: oops, premature "submit"...

Of the three, the Teensy 3+ would be the best for thise, because of the RAM. As I understand, it can emulate keyboard/mouse/joystick like a Leonardo. The resolution of it's axis is also a lot better, 12 bits vs 8 I believe. That means that while your Leonardo is able to show 0-255 "thicks" on your throttle to the PC, the Teensy can show 4096.

Edited October 4, 2015 by Rosco P. Coltrane

[FastMINI42]

I'm curious, why three boards?

Edit: oops, premature "submit"...

Of the three, the Teensy 3+ would be the best for thise, because of the RAM. As I understand, it can emulate keyboard/mouse/joystick like a Leonardo. The resolution of it's axis is also a lot better, 12 bits vs 8 I believe. That means that while your Leonardo is able to show 0-255 "thicks" on your throttle to the PC, the Teensy can show 4096.

I was thinking three boards, but now after looking at the teensy more, I think I might go with just two teensy boards. Two boards mostly because I don't think one will have enough pins: The keyboard matrix will need 16 or 17 digital pins, there will be 9 on/off toggles and 8 LEDs, in addition to 3 analog for throttle / joystick (maybe 6, if i incorporate trim adjustment). I do like the idea of better resolution (the arduino is 10bit, with 0-1024 ticks, and it looks like the teensy is capable of 13 bits). With two boards, I like the idea of using the one looking at the keyboard matrix & toggles as an I2C slave while the master unit looks at the analog inputs. The slave would then send an interrupt only when a button is pressed. Time-wise button presses don't happen that often, while the analog inputs need to be monitored real time when they're moving. I did just order one Teensy board, so I'll be looking at that this week

[Rosco P. Coltrane]

Right. Well, the input pin problem normally would be solved with shift register chips, like the 74HC165... Now, I take it you're a newbie so, if two boards make it easy for you, then go ahead... But shift registers are easy ... and cheap.

Speaking about interrupts... Are you planning on having some data coming in from the PC? If not, I don't see why you'd need interrupts to work with inputs in this case.

Normally, what you'd do is have your main loop checking on buttons and rotaries as it cycles. It might not be that great from a technical point of view, but it's easier.

[FastMINI42]

I hadn't thought of shift registers, that would solve the pin availability issue. But then, with all the inputs to scan and not knowing how fast the Teensy is, I would worry about the ability to loop through that in enough fast enough that the throttle input doesn't start appearing laggy. Certainly some of it could sampled at a lower rate instead of every time it loops, maybe every 10ms (I don't know for sure how wide a key-press pulse would be, I could look at that at on an o-scope at work when the switches come in), and the non-momentary switches likely could be sampled as slow as every 500ms.

The interrupt wouldn't be for the PC or the USB bus, it would be for the I2C bus. My thought was that the secondary Teensy could be taking it's time to sweep through all the dozens of button inputs while the primary Teensy would be sweeping much just faster looking at just the three analog inputs. If the secondary saw a button change state, it would trigger the interrupt pin on the primary. The primary would then automatically run an interrupt routine to send the Key.Press() or Key.Release() to the PC, depending on how the key changed state.

[Rosco P. Coltrane]

Yeah, I get what you say.

Keys, you want to de-bounce them, otherwise you will be registering false presses or releases. So you will be adding artificial time frames in which you don't care what the state of the key is, so lag in this regard will be irrelevant. BTW, a typical PC keyboard polls the keys at 125 Hz (not kilo, not mega, just hertz) and you don't notice any lag.

The biggest source of lag you will have here are the digitalRead() and analogRead() calls you'll make to read the swtiches and axis, because the way they are implemented on the Arduino (you can bypass it but good luck!). Shift registers I believe will help you here with the digitals, because there's one call to write and one to read for each chip (you will have to use more than one chip daisy-chained to read all those buttons). Combining shift registers with de-bouncing can be sort of a pain, I'll give you that.

My experience with the biggest thing I have built, a keyboard-panel-thingie with 48 keys, with a Leonardo at 16 MHz (vs 72 on the Teensy), is that you won't notice any lag even if you use a matrix and good old polling with no shift registers involved and make the Arduino interpet your own badly implemented and optimized interpreted language to decide what each key does. As I said, the delays you add to de-bounce are orders of magnitude bigger than any lag the micro can produce.

Also, you don't have to poll all switches in order, you could poll half of them, and then the rotaries and then the rest of the switches.

Just throwing ideas here. Take it as a newbie talking to another newbie.

BTW 1:

(I don't know for sure how wide a key-press pulse would be, I could look at that at on an o-scope at work when the switches come in)]

Delays of 10 to 50 milliseconds between press and release seem to work for me.

BTW 2:

The interrupt wouldn't be for the PC or the USB bus, it would be for the I2C bus.

FYI, I2C transmission is limited to the clock speed, too.

PS: thanks for the rep!

[FastMINI42]

bump for an update

[Rosco P. Coltrane]