Jump to content

Kerbal Instrument Panel: In-Desk Apollo Themed Hardware Controller


richfiles

Recommended Posts

  • 1 month later...

UKoodxD.jpg

Still being crushed at work, but I thought I'd share what finally showed up today!
That "RIP JEB" makes me "AYY LMAO":D

So, I expect I'll use these keys on the CRT side panel, if I ever get around to building it. Main controller is first priority, obviously. I definitely appreciate the inclusion of Pluto. What I'll likely do, should said project ever get underway, is I'll use the planet keys to select primary SOI, and have some up/down keys to cycle through a local planetary system's moons and planet, to select what map to display on the CRT. I wanna keep things simple, if I ever do the map project, so It'll likely be a top down and an edge on view of the selected body, with the craft's orbit plotted around it. That's ever if I git gud at programming. It'll be a long while, if it happens. I want to focus on completing the main controller. First step to that is finding free time again. :/

Edited by richfiles
Link to comment
Share on other sites

On 3/3/2018 at 5:17 PM, richfiles said:

That "RIP JEB" makes me "AYY LMAO"!

Me too, but "DANGER ZONE" literally made me spit water (er, well, beer) onto my keyboard.

Thanks for the update; I'll go back to silently reveling in your insane amazing project. 

Link to comment
Share on other sites

1 hour ago, boccelounge said:

"DANGER ZONE" literally made me spit water (er, well, beer) onto my keyboard.

Yeah, The Danger Zone keycap set was an incredibly popular group buy at Massdrop, and organized/created by the user Data over at https://www.geekhack.org  and it looks like it may get a second run in by the end of the year or maybe next. The set's been requested over 4600 times since the group purchase ended back in 2015, and the original group buy was over 1500 sets!

And yeah, it's absolutely themed on the movie Top Gun. Some of the optional extra keys were called things like the "Maverick" pack! :cool: There was even a "Goose" pack, which contained a few last minute additions that "didn't make it" during initial design of the key cap set! I hope you weren't drinkin' when you read that! :D

Spoiler

DangerZoneMassdropTopGunPoster.jpg

And yes, why those are indeed four small robots pinning down a Top Gun movie poster, with a Danger Zone keyboard and a thank you letter to distract you from the miniature invasion. :rolleyes:

 

Link to comment
Share on other sites

  • 2 months later...

--< Sniped a long rant that didn't feel like it actually belonged here...Yada, yada, soul crushing work... Burning out at my job... >--

Long story short, I'm so worn out at my job. I'm burning out there, and they are absolutely taking advantage of the fact that I know it's the most secure thing I've ever had in my entire life. It's stressful, it kills ALL my time, and I know they are definitely taking advantage of me. Thing is, it's hard to argue with the incredible security of the position, or the good coworkers... At least right now, the people I work with these days are pretty awesome. Thing is...

I JUST wanna BUILD!!! :0.0:

So, ranting aside, I've thought about little details and stuff over the past year... I still can't belive it's been about a year since I did the diode ROMs. Thankfully, I leaned to use KiCAD in that time, which will greatly benefit the FDAI controller build. While not particularly exciting, I've definitely thought about driving the diode ROMs. Mostly just transistor theory there. I think I want to adjust the resistors on the LEDs. I'm not happy with the current draw, and I suspect I don't need the brightness to be that intense. Annoying as it might be, it'll be a huge pain to refit all the individual resistors, so I'll probably just tack a low value resistor, capable of handling the power requirements of all segments, to the cathode of each LED display. It does mean I might get a dimmer overall per segment brightness when more segments are lit, but since most of the resistance is per segment, it shouldn't be bad. Might not even be noticeable! I still have no idea what happened to my large toner transfer drum, but worst case scenario, there are MANY smooth round things in the world to use to laminate the filter layers together instead.

On 5/16/2018 at 10:55 AM, IncongruousGoat said:

@richfiles Have you gotten the C programming worked out? Because if not, I'd be more than happy to lend a hand.

I have not worked out the programming side of things. Honestly, I've gone nearly a year without major advances. As I ranted above... Work's been insane.  My old keyboard is actually starting to go, so I need to get my mechanical keyboard programmed as well, first even. Soon There are firmware packages that are supposed to be easily modded to conform to your custom layout, but my issue is I need an I2C port expander chip to be hot swappable, for my keyboard's unique features to work. If I ever set aside the time to do it, I could probably get my mail keyboard working, but I have no idea how to do the hot swapping number pad. I worry that would need far more custom firmware that I have no idea how to make. My biggest issue, is I need the time to sit down and play with the stuff, but by the time I'm done with work (been working full days, even though I'm only supposed to be part time, and have another job on top of that).

I am very happy to have learned KiCAD, as it means doing the Navball controller more easily. If you're really willing to help out with the programming aspects, then I would be quite grateful. I need to work out the required waveforms for driving an axis of the FDAI. I think I'd run a single Arduino or Teensy per each axis (three axes, three controllers). The only difference in their program would be which number they read from the packet, but otherwise, the three controllers would almost identical software.

I will have dedicated microcontrollers for each general sub-system. Coding should be easier, by separating tasks so each individual controller only has a somewhat singular task to perform.

The software would have to:

Read the correct number out of the data packet sent to it
Store that number, then add 120 and 240 to it. If the two results are > than 360, then subtract 360.
Then it would need to take those three numbers and find (I think) the *sine value for them. I imagine a lookup table would possibly be the most efficient route to go with that.
(rather than an actual sine value, it might be easiest to just store the DAC attenuation values in the lookup table, aka, figure out the results of the multiplication and just store that, to avoid the multiply)
A sign check would be need to be performed to determine what polarity the switch output of each of the three "sine" outputs is. The actual value sent to the DAC would be absolute (stripped of sign)
The three lookup table values and the three polarity values would be output. The polarity values are just digital out pins being high or low. The DAC values are sent over I2C to the DAC chips.

It would need to be able to do this, preferably for every frame of data sent by KSP, or the ball might end up jittery. The nice part of my FDAI hardware design, is I'll be handling the generation of the 400 Hz reference in hardware, and the DACs only attenuate it from 100% down to 0%, and the polarity signal switches the phase 180° out (flips the sign wave). It means the controllers would only need to update the DACs once every data frame, and polarity every half turn of an axis of the ball. Polarity never switches unless a DAC's attenuation point reaches 100% (the zero crossing point of the sine wave).

It'd probably make a lot more sense if I had a waveform to visualize the operation of a synchro, which is what this hardware and software would be emulating... Nine of them, to be specific. Three per axis. As I said, the program on each controller would be identical, except for what value gets read from the data packet. It's also possible that i might be necessary to "rotate" the numbers in the lookup table, depending on whether my FDAI shares the same "home" reference points as KSP or not.

The analog meters, fortunately, are pretty simple. Just readouts of different data from the packet. Same with the digital readouts, except that some numbers would need to be formatted for display on an LED readout, and I'd need for the scale to place the decimal at the correct point for the unit of measure used, and output some digital out to control which unit displays.

The Radar altimeter will need to be able to operate a motor of some kind and read, probably a quadrature input to determine position of the tape. I'm thinking a reflective mar on the back of the tape would indicate the home position, and reset the tape to the correct position on power up.

The carriage meter will be kinda fun. I need data outputted from a mod, and that means it's value(s) need to get added to the KSP mod that communicates, as well as needing to read the correct packet on the receiving end. It'll need to monitor a button or two in order to know when to reset and set the carriage assembly. The set button would set the carriage in the up position, and display the node ∆v on the carriage meter display and the estimated burn time, and store that peak value for use. The meter would move down, driven by a motor, moving to match the percent of remaining burn (reaching the bottom when node ∆V = 0). Reset would clear the meter and return it to the bottom position. There might need to be some error handling on that one. If the system returns a node ∆V value, but it's not set, I'm not sure if the motor should do nothing, or if the peak should be instantly recorded, and the meter rapidly move up to follow that burn. Likewise, if node ∆V reaches 0 or null, I would think the meter should jump to the bottom, and zero out. The displays used for the carriage meter are "smart" displays, and you can directly communicate with their integrated controller. I might want to use a custom character or two, if they support it. That would need to be initialized at power up, if the smart displays support it (I don't recall if they do).

There's clearly a lot to think about, when it comes to my panel, and I feel awkward, knowing all the hardware aspects of it, but not having the software expertise to really back my goals. Again, help is always welcome. I just wish I was at the point where I even needed the software yet.. I still have SO MUCH hardware left to build... :confused:
 

2 hours ago, KerBlitz Kerman said:

@richfiles , an Idea for that EL backlighting...

Lay out all of your swiches in a single, uniform row then tape this behind. Adafruit also sells inverters and splitters so you could probably get a few off one inverter

Pretty sold on my LEDs. They won't fade gradually like the EL can, over time, and I really have no need for EL. The LEDs will mimic it well enough, and can be driven with a simple power supply. It's a good suggestion, but I just already am invested in all the LEDs I need for the project. Thanks for at least thinking about it though! :wink:

 

Edited by richfiles
Link to comment
Share on other sites

I'm still willing to help, yes. A lot of what you've said would probably make more sense if I had a schematic in front of me, but for now it sounds fairly reasonable. It's also worth noting that, as far as microcontroller performance goes, the major bottleneck is likely to be transmission speed from the computer running KSP to whatever embedded controllers you end up using. If, say, you end up using 3 Ardunios, you're going to be limited to a baud rate of 115200 over serial. At the clock speeds used by the ATMega chip in the Adruino, that's something like 1000 instructions executed per byte received (if I'm remembering correctly). So processing power on the microcontrollers is probably not too big a concern, even if there does end up being some relatively heavy-duty floating point math going on.

As far as rotating the numbers goes, at that point it might be time for some vector mathematics, using some transform (rotate & reflect) matrices to make the coordinate systems line up (probably on the computer end).

For driving the FDAI's motors, you might want to look into some way to avoid having to have the microcontrollers output raw waveforms directly, because that incurs a good amount of overhead. There are hardware solutions for that kind of problem (for example, I2C-controlled LED driver, which can be used as an ESC controller), although these may require some rejiggering of the microcontroller setup, due to requirements of various communications protocols regarding the number of permissible master devices.

There are other things I could add as well, but I'm going to hold off for now until I have a better idea of what the hardware looks like.

Link to comment
Share on other sites

8 hours ago, IncongruousGoat said:

For driving the FDAI's motors, you might want to look into some way to avoid having to have the microcontrollers output raw waveforms directly, because that incurs a good amount of overhead.

I'm not. The raw waveform is a 400 Hz sine wave, but all the micros have to do is output three "attenuation values" and three polarity values to represent the angular position of the (virtual) synchro rotor in relation to the stator. Those values only update as fast as the data changes from KSP.

An attenuating DAC, or multiplying DAC, is a digital to analog converter that lets you feed an input into a reference in, and the value loaded digitally determines the percentage of the input that passes through... The attenuation factor. Because of this, I can feed the data in (at the rate that KSP sends new data packets), and it will update the synchro angular values, and the 400 Hz sine wave (from a hardware sine generator) will simply pass into the reference in, and be attenuated at the DAC's output. 100% hardware doing the waveform!


This is a rough block diagram of what I'm doing. Originally I had one microcontroller handling everything, but I realize now that I can "game" the PCB manufacturing industry by making each axis as it's own independent PC board. When I order, I'll oder only "one" board, but get three identical physical boards, and I'll only need to drop a teensy or Arduino onto each board, and connect the appropriate reference pins to the sine generator. Other changes include using a high power integrated audio driver chip instead of the... Not sure if they are really real LM675s that I got on ebay... Probably from questionable sources in China. The audio drivers should have no problem driving enough current to step up the transformer output to 28 volts for the synchro inputs, and 115 volts for the reference/power input.

And as a reminder, this image is old, so it's not up to date with the split axes/three controllers concept.

?action=dlattach;attach=273942;image

I did some off the cuff calculations, and even if I have a PEAK of 60 data packet frames per second (from KSP), then I need to send 60 x 9 SPI transmits each second. That's only 540 DAC transmissions per second. If KSP only transmitted half the data packets per second, that number would cut in half to a mere 270 SPI transmissions per second to the DACs. That's also ALL THREE axes! If I go with a separate controller per axis, then that reduces the requirements further to 180 SPI transmissions per second at 60 frames per second, and a measly 90 SPI transmissions per second, if KSP were only sending packets at 30 frames a second. I'll need  5  6 Chip select lines (since I'm favoring multiple identical PCBs over part count reduction), plus the SPI bus connections, and a single digital out to update all the DACs to their newly updated values. I'll also have an incoming serial bus that it will be watched for frame updates. For the individual microcontroller configuration, there's only need for 2 chip selects, and three polarity selects per controller.

While a more expensive hardware solution, splitting each axis into three identical boards means you can focus the software on just controlling the one axis, dealing with only monitoring for one piece of data from the incoming serial packet (not from KSP, from an arbitrator micro, that would receive the KSP data over USB, then send it out, probably over SPI to other controllers), outputting data for only three DACs over another SPI bus, managing the chip selects for the two DAC chips (each chip has 2 DACs... one goes unused), and managing the three polarity digital I/O. That's it. Repeat three times, and you have an FDAI Synchro emulator... My navball brains!

I hope. :wink:

Edited by richfiles
Link to comment
Share on other sites

21 hours ago, richfiles said:

I have not worked out the programming side of things. Honestly, I've gone nearly a year without major advances. As I ranted above... Work's been insane.  My old keyboard is actually starting to go, so I need to get my mechanical keyboard programmed as well, first even. Soon There are firmware packages that are supposed to be easily modded to conform to your custom layout, but my issue is I need an I2C port expander chip to be hot swappable, for my keyboard's unique features to work. If I ever set aside the time to do it, I could probably get my mail keyboard working, but I have no idea how to do the hot swapping number pad. I worry that would need far more custom firmware that I have no idea how to make. My biggest issue, is I need the time to sit down and play with the stuff, but by the time I'm done with work (been working full days, even though I'm only supposed to be part time, and have another job on top of that).

So why would It need to be hot swappable? If a switch is disconnected, isn't it the same as it not being depressed? And put the indicator lights in the main assembly right?

Link to comment
Share on other sites

2 hours ago, KerBlitz Kerman said:

So why would It need to be hot swappable? If a switch is disconnected, isn't it the same as it not being depressed? And put the indicator lights in the main assembly right?

My keyboard matrix is far too large to be accommodated by just manually wiring in all those connectors. It'd require 12 wires for the 6x6 matrix and 2 more to cover the sub/back-lighting LEDs. 14 pin magnetic connectors just don't seem to exist.

That's why I'm using a 5 pin Apple MagSafe connector and an I2C port expander, and an I2C DAC. The 5 pin connector provided Power and Ground, The two wires required for I2C communication, and a sense wire that detects if something is plugged in or not. Even if I were to go the lazy route and install three of the Magsafe connectors to just brute-force the pin count, the Teensy 2.0 doesn't have enough pins to do a matrix big enough.

The Ergodox keyboard uses either dual Teensy boards sort one teensy and an I2C port expander to connect the two keyboard halves together. The firmware I have, I think even supports split keyboards, but there's no provision in the code for what happens if the connection is broken. I think it just crashes.

What I need, is sufficient understanding of how to code, or someone willing to help me out with their coding knowledge, to create a conditional branch, where it checks the state of the sense pin, and if it indicates something is attached, to then send the appropriate data over I2C, then wait for an appropriate response, to scan the additional external matrix. It needs to be capable of abandoning a read if it times out, so it can gracefully handle disconnecting at any time, including after the sense pin check, but before the commands are sent or data received back. Basically, I need it to gracefully ignore the I2C port expander any time it's flakey or not present.

It would also be necessary to periodically send updates to the back/sub light DAC, to make sure the LEDs on the numberpad shine the same brightness as the LEDs of the main keyboard. There are no LED indicators on the numberpad.

Link to comment
Share on other sites

@richfiles

010110110100100101100100011001010110000100100000010010010110111001100011011011110110110101101001011011100110011101011101

USB C connector, with using extra 2 pins as a switch to tell if something is connected to it.

0101101101001001011001000110010101100001001000000101001101100101011011100111010001011101

Edited by KerBlitz Kerman
Link to comment
Share on other sites

Well, everything's already built. I'd have to completely redo the keyboard to try it that way. Everything is already assembled, wired, and it's definitely not coming apart! Besides, It should be more than possible in software. It's just a matter of programing. i grasp the basic flow of how it should be managed, but I don't know how to actually do it.

dRVTAPt.jpg

There are also significant clearance issues. The rear of the keyboard has an internal 11.1mm of clearance, but due to the angle of the keyboard's slope, the front of the keyboard only has 5.5mm of clearance. It's gotta share that with the MX switches, and there is simply not room for a wider connector. The 5.5mm clearance at the bottom is so slim, that I had to actually shave plastic off the MX connector's bottoms to fit them! They are nearly flush with the edge of the case... practically no clearance! Maybe a millimeter, tops! The magsafe connector sits at the thin gap near the thickest portion of the keyboard, where it can barely overlap with an MX switch, sitting underneath it, in the 5.6mm (and shrinking, the closer to the front of the keyboard you get) space available at the thickest end of the keyboard. Even after the width of the magsafe connector, there's simply no longer even room left for a wider connector.

Even with both the switch plate and the bottom cover installed, the front edge of my mechanical keyboard is only 8.5mm thick! Heck, my old Logitech DiNovo Edge is 10.1mm thick at the thinnest (not counting the integrated wrist rest's tapered slope)... And it's only a membrane keyboard! I'm pretty happy with the thinness of my mechanical keyboard, but it simply means no clearance for overly huge connectors on the sides. I actually considered what you suggested. It's why I actually have three magsafe connectors, which would have given me 15 pins... There just wasn't room in the design.

I also needed clearances for the 4mm cylindrical neodymium magnets, and the magsafe connector is it's own magnet as well, saving an additional magnet space. It's been designed for serial communication, and that's what's gonna be used. Even if I'd have had access to that connector, I'd still not have enough I/O ports on the Teensy to actually interface all 122 keys. Even with an ideal matrix, 11x11, I would still be one key short. Not to mention that an "ideal" matrix would be quite un-ideal for a non square layout... It'd be as tangled a mess as a spaghettified, krakenized Kerbal! :0.0:

yKhMcIY.jpg

Additionally, I mentioned the magsafe connector is a magnet... Well, it's a ring shaped neodymium magnet that surrounds the entirety of the pogo pins. It's far stronger than the two small magnets on that 10 pin connector, and I needed a strong magnetic bond to keep the keyboard halves together. Neither connector you showed would have been any use. The one with enough pins has no integrated magnetics, and the one with magnets have only a fraction of the magnetic hold as a magsafe connector, nor does it even have enough pins to serve the purpose of hardware level hookup anyway. This is something far more easily solved in software...

And even if a hardware solution were to be sought, a simple USB hub and USB over the 5 pins would be more than sufficient, but I want to avoid this, as my computer would see this as two separate keyboards, and I don't want that. I want this to be seen as a unified single keyboard.

On a side note... I just discovered that I have a 4 day weekend, and didn't even realize it. Tomorrow (Friday) is the last day I work until next Wednesday! How about that! if I'm lucky, maybe I can make myself work on either the keyboard, the Kerbal controller, or (gasp) both!

Edited by richfiles
Link to comment
Share on other sites

Maybe use 2 pins as ground and hot, with one of the magsafe connectors connected to ground only when the pin is connected as a detection system. Using the other two as a i2c expander would in the end, probably be best.

Or could you set it up where if a numpad key is pressed and inputted to the teensy, it exports the keypress to a mac/ win 10 device

Also:buy another magsafe, and remove the magnet, cut it into cylinders to replace the others.

Edited by KerBlitz Kerman
Link to comment
Share on other sites

11 hours ago, KerBlitz Kerman said:

use 2 pins as ground and hot, with one of the magsafe connectors connected to ground only when the pin is connected as a detection system. Using the other two as a i2c expander

Literally what I'm already doing. Here is my build thread for the keyboard, over at geekhack and Same build thread, but on Deskthority. All details can be found over there.
While the keyboard is being designed to slot into the gap in my Kerbal controller while playing, I don't consider it a part of the Kerbal controller. It is it's own uniquely separate build.

Link to comment
Share on other sites

16 hours ago, richfiles said:

Literally what I'm already doing. Here is my build thread for the keyboard, over at geekhack and Same build thread, but on Deskthority. All details can be found over there.
While the keyboard is being designed to slot into the gap in my Kerbal controller while playing, I don't consider it a part of the Kerbal controller. It is it's own uniquely separate build.

NEW IDEA:

if you can solder to the magnets, you could use those as ground and hot, whiling leaving four magsafe pins for data.

 

 

 

 

 

1 minute ago, KerBlitz Kerman said:

If you can solder to the magnets...

Like I said. If

Edited by KerBlitz Kerman
Link to comment
Share on other sites

@KerBlitz Kerman The metal is not solderable, and heat will demagnetize magnets anyway. I simply don't need any more pins either, as I only need two pins for data. You are suggesting solutions to problems that never even existed in the first place. Everything is already figured out on the hardware side. The main keyboard is already completely built. It's done. It only needs software, and the number pad only needs the port expander wired in. All that remains is software, and that's it. Again, I suggest reading the build thread on Geekhack for details of the keyboard. Everything you need to know about the keyboard is already covered over there.

Link to comment
Share on other sites

On 3/3/2018 at 4:17 PM, richfiles said:

UKoodxD.jpg

Still being crushed at work, but I thought I'd share what finally showed up today!
That "RIP JEB" makes me "AYY LMAO":D

So, I expect I'll use these keys on the CRT side panel, if I ever get around to building it. Main controller is first priority, obviously. I definitely appreciate the inclusion of Pluto. What I'll likely do, should said project ever get underway, is I'll use the planet keys to select primary SOI, and have some up/down keys to cycle through a local planetary system's moons and planet, to select what map to display on the CRT. I wanna keep things simple, if I ever do the map project, so It'll likely be a top down and an edge on view of the selected body, with the craft's orbit plotted around it. That's ever if I git gud at programming. It'll be a long while, if it happens. I want to focus on completing the main controller. First step to that is finding free time again. :/

You might need RSS just because you have those keys! :D

Edited by KerBlitz Kerman
Autocorrect
Link to comment
Share on other sites

39 minutes ago, KerBlitz Kerman said:

You might need RSS just because you have those keys! :D

I'm planning on using OPM, which has a stock-alike "Kerbalized" planet for each real solar system planet not already mimicked in the game (Saturn through Pluto), and a plethora of additional moons! I also want to add a mod that mimics some of the well known dwarf planets as well. While most people consider Eeloo as a Pluto analog, OPM re-arranges it into an Enceladus analog, and makes Plock much more similar to what we now know about Pluto.

Edited by richfiles
Link to comment
Share on other sites

Just realized what autocorrect did to my previous comment. WOW GOOGLE. Even Microsloth is better. Anyhow @richfiles, I remember you asking about the Sony Sobax render on Linus's build with Dennis. It's from Unigine Superposition. At just after 25 seconds.

 

Edited by KerBlitz Kerman
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...