FastMINI42

bump for an update

Today I completely, utterly, and hopelessly botched a rescue mission to the MUN. I have a crew orbiting the MUN but out of fuel to get home. Seems simple enough. First mistake (besides running out of fuel in the first place) was wasting too much trying to get closer (initial intercept was several kilometers apart). Then, when the rescue craft ran out of mono-propellant I switched to the lander to discover the symmetry was wrong on the nozzles on the lander... that was the second mistake. With only two nozzles, I could only translate up and down. I was able to hack it and kind of get things close enough by rotating 90 degrees to go left/right, then another 90 to go up/down ... That kinda worked until I got within a few meters and there wasn't enough time to rotate 90 to make the corrections. So I gave up and sent the rescue craft home and will be adding more mono-propellant and trying again. *face-palm*

Didn't do much today. Just set a crew on Minmus on their way home to Kerbin, and launched a rescue ship for another crew stranded in orbit around the MUN. The rescue ship:

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.

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

Today I went for a drive to Minmus' north pole. As is the case with the scenery in this game, I couldn't help but look at Kerbin and the Mun so tiny and far off in the distance, hanging against the backdrop of stars and galaxies, and think to myself "wow ... I can't believe I forgot about the stranded crew orbiting the Mun. Maybe we should get a rescue mission together ..."

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.

Didn't do too much today, just a Mun landing for experience unfortunately ran out of fuel, so I'll have to organize a rescue mission for next time. Leaving the East Farside crater, home is so close and yet so far away:

Took a few tourists to Minmus. They didn't want to EVA with everyone else and just wanted to stay inside and take pictures though:

I discovered Navy Fish's docking port mod (here) worked with something called "RPM" ... a little googling later, I found the mod (here) and it's amazing. Makes IVA what it should be, and provides a lot of information. I put a couple ships up in orbit, docked, and landed, all IVA with the glass cockpit in the MK1-2 pod: take-off: Docking: Landing:

Today, I picked up a random Kerbal while taking a couple tourists out for a spin. I also switched the wheels on the Wanderer after having to recall the crew due to broken wheels and an inexperienced Engineer. The TR-2Ls work much better than the Rovemate Model M1. The Rovemates feel like driving on ice on the Mun, while the TR-2Ls feel a lot more solid. I even took the rover, all 33 tons of it, up a 45 degree incline at 8m/s with no help from engines. At $400k it's expensive, but I do have a resupply craft ready at half the price, I just need a crew. New Crew, hopefully they go easy on the wheels: Hill Climber: Sending the junior scientist out to collect data... don't look down and remember, safety third! Driving through another crater:

Today I landed the Wanderer Mun Mission in the East Crater: Unfortunately that was right at about sunset, and I've been waiting for sunrise. In the meantime, I brought a lander back from Minmus for Science! I think my next game I'm going to decrease the amount of science coming in...

I finished designing the Wanderer, a Rover full of nomad and vagabond Kerbals. Next I need to plan a Mun mission in my career save, I think there's science in that big crater. (The first four are from yesterday's work designing the lift portion of things)

I tried and tried and tried and tried to launch my science vehicle in a fairing, but the vehicle kept wobbling out of place and breaking loose ensuing in all kinds of explody bits going everywhere. After adding strut after strut after strut with no success, I rage deleted the launch vehicle. Took a break, and decided to throw the common sense design guidelines out the window, strap some orange tanks & mainsails to it and see what happened. After a few tweaks I wound up with this crazyness: It flies!! Add enough struts, girders, airbrakes, and reaction wheels and it's surprisingly stable: Drag, shmag: Up in orbit, on the way to the Mun. Tomorrow we'll see if it can actually land:

ah, so it's not just me. Thank-you for the answer!