Dr.Vulpinus

With only 4 days left and $600 to raise on the Kickstarter for this project to really happen, I have another exciting project update: The full controls list. I had compiled a list of controls very early in the project, but I wanted to make sure that I did't miss anything, and I wanted to work out how each control would function before releasing it. The whole project wouldn't really work if the controls in the capsule failed to provide all of the necessary functionality to play KSP, the whole point was to eliminate the need for a keyboard and mouse... The exact layout has yet to be determined, the physical locations of the switches and buttons will be modeled on the real Gemini capsule, but the functions of controls that do not directly translate from the real Gemini are going to be located to make them as logical and ergonomic as possible. As for seeing the game, the central panel of the Gemini capsule is mainly dedicated to life support and communications controls, neither of which are nearly as complex in KSP (without the use of extensive mods, though I am planning on an updated version with a smaller screen that has more room for life support mods), so I decided this would be the ideal place to put the screen so that both pilots could see it. The red outline in the picture below shows the approximate location and size of the screen. The main sequence controls will still be located on the left side of the central panel, along with a few others in other places. I want to leave those exact decisions until I get the chance to really see how the whole thing feels sitting in it. And now... for the main show... The controls list. Each control is named, given a location in the cockpit, has an interface type, and any notes to I added to explain its functionality. (Note: I was going to put the table of controls directly in the post here, but it has 105 rows, and the table functionality in the forum just broke everything, so I gave a link to a post on my website, which allow me easily embed spreadsheets.) Full Controls List If you have any suggestions on other controls I should add, please do let me know. Once again I want to thank all of the supporters of the project so far, we are getting very close to making this project a reality! If you want to help support this project, the Kickstarter campaign ends this Thursday, the 17th.

That is a really great idea. I have been working on a Navball design for my open source Gemini sim-pit project (KSP Forum link), and I had planned on just simply aligning it manually once, then always making sure that it was turned off in the "home" position and then never touch the ball again. Not really an ideal solution I realize. Magnets and hall effect sensors are far more elegant. I have opted to completely 3D print mine because oh lawd trying to engrave a sphere with a CNC gives me stomach cramps just thinking about it, plus since 3D printing is one of my areas of expertise it vastly simplifies everything for me (the markings can be printed right into the surface of the ball) and majorly reduces cost. One other issue I ran into was with the needles. Trying to use simple rotary needles ended up being really complicated and finicky to get right to avoid any possible situation where the needles collide. I was wondering how you planned to deal with that? I spent more time than I'd like to admit testing the alignment and shape of the needles in CAD to no avail. In the end I decided that I wanted full length needles to make visualizing the nodes much easier, and ended up just making the needles slide in slots on the side of the frame so that I could avoid the problem entirely (see the pictures below). Also because I realized that the rotary needles couldn't be driven directly from the servos anyways due to the small range of motion, so instead I used the servos arms to push the needles one way, and springs to push it back, thereby eliminating any hysteresis error. Here are a couple pictures of my design so far: Basically all of the mechanics are complete, I just need to finish the frame design and panel mounting. Also, on somewhat of a tangent, @wile1411 if you want to learn CAD I would highly recommend learning with Autodesk Fusion360. As someone that has tried just about every CAD package out there, it is probably the easiest and most versatile CAD program available today, and plus it is available for free for students and makers. (and just to be clear, no I don't work for Autodesk, just my honest opinion here). In my experience, trying to learn Sketchup is a great way to scare people away from CAD by making it excessively awkward and obtuse. If you really want to use a totally free CAD program, then I would recommend FreeCAD.

I finally have the panel meters ready for posting! There are two main designs, vertical linear meters and rotary meters. As with the navballs, they are designed to be fully 3D printed. First off is the vertical panel meter. This one shows a percentage readout with two indicator needles (good for say, oxidizer and liquid fuel). The labeling can be changed to suit whatever is being indicated easily, and is 3D printed directly into the face of the gauge. These will be used for fuel levels, monoprop level, electrical charge, and power consumption rate, and power generation rate. As with the navball needles, the servos will drive the needles against a spring to eliminate any backlash. The servos do not drive the needles directly because that enables the use of the full range of the servo for higher resolution. The second panel meter is specifically the docking range/rate indicator. It shows the rate of approach and the range to a target vessel. This was used frequently during the many docking and rendezvous tests done during the Gemini program. The gauge is located on the bottom right of the command pilot (left side) panel. It is set up so that the relative position of the needles allows for instant recognition of docking speed. If the speed needle indicates a higher value than the range needle, the speed is too great, and vice versa. The labeling of this gauge is logarithmic to allow for the best range of values while still giving decent resolution at lower values. This gauge will be featured in nearly identical form in the sim-pit, as shown by the CAD model below. I am going to begin the process of installing these gauges and the navballs into the cockpit model very soon. Then I'll be able to shown the full layout of the sim-pit with the actual gauges that will be in it!

It's been a while since I posted an update on this project, as I am still working out some of the details of the panel meters. In the mean time I decided to post about plans for making/editing maneuver nodes. As it turns out, the original Gemini capsule has a system for making maneuver nodes built right in! This consists of the incremental velocity indicator and event timer clock (see pictures below). This is the incremental velocity indicator. This is used on the Gemini capsule for planning maneuvers by allowing the command pilot to enter in delta-v values for forward/aft, up/down, and left/right. The computer then monitors the acceleration of the vehicle when the thrusters are fired, thereby allowing the pilot to program in maneuvers, and subsequently monitor the progress of their execution. This in and of itself is incredibly useful, but when combined with the event timer clock, it allows for KSP-esque maneuver node programming. The event timer clock is essentially a built in stopwatch that allows for timing of various events (such as maneuvers) up to 59 min and 59 sec in the future. So, how will these be used in the sim-pit? The event timer clock will have two main functions, the first mode will be for planning maneuver nodes, and the second will be for controlling time warp in the game. In the maneuver node programming configuration the event timer clock will work in conjunction with the incremental velocity indicator to place and program a maneuver node. The controls will be adapted slightly, instead of forward/aft, etc. they will be prograde/retrograde values, with the total remaining delta-v displayed in an additional display. The digits will all be shown on 14 segment displays as opposed to mechanical counters (because cost), and the input knobs will be lighted rotary dials that will glow red or green to indicated a positive or negative value. When a maneuver node is active a light will also illuminate by the SAS control knob to shown that aiming in the direction of a maneuver node is possible (much like the icon becomes active in the normal KSP interface). There will be a switch for activating the map view as well as readouts for the current or planned apoapsis and periapsis so that it will be easy to see and plan maneuvers. So yeah, Gemini actually had the idea of maneuver nodes already included in the design, all I have to do is just interface that idea with KSP. I hope to post about the panel meters either later tonight or first thing tomorrow, it depends on how quickly I can get the docking readout modeled, another example of a NASA engineering solution that transfers brilliantly into the world of KSP. Also, I want to thank everyone who has supported the Kickstarter, every little bit helps, and as a result, we have gotten almost 20% funding so far.

Alright, so, project update: I have most of the navball design complete. The image below shows all of the mechanics in place. The red and yellow needles are the 2 sets of FD needles (I went with two sets because then docking will be much easier being able to display both prograde and target vectors). The green needles are the fixed heading vector needles. The needles themselves will be made from either steel or copper wire, about 1.5 mm diameter. I also decided to go with linear needles as opposed to ones on long rotating arms. The reason for this is that I found that the needles could wind up colliding if I didn't perfectly calibrate their positioning, shape, and size. Especially with 4 full length needles (on the original navballs, they had shorter needles, thoughts on whether I should make the needles on mine shorter? I kinda feel like the long needles make the view a bit cluttered). The servos are positioned the way they are to maximize the servo throw on the needles, thereby increasing the resolution. The servos will push on the needles against a return spring to remove any hysteresis from the needle's motion. As for motors, I went with NEMA 8 Stepper motors because then I could avoid needing to have a gear train inside of the ball. I may wind up using a NEMA 17 size motor for increased torque on the roll axis, but that will be very easy to change because it is just kinda stuck on the outside anyways. I need to do some calculations on the torques before I finalize the motor choice, but with the gearing I think it will be OK (those gears are 3D printed as well). For the purposes of seeing the insides, the picture below has the navball rendered with clear plastic so that the insides are visible. The final version will be completely opaque and 3D printed. I also rotated the navball 90 degrees (from the customary configuration), this way the stationary center ring forms the horizon line, therefore each half of the ball can be 3D printed in a single color. The text and lines on the navball will be painted in grooves CADed into the design. Obviously, I still need some of the main structural frame elements but I am very pleased with how it is turning out so far and I think I am now far enough along to be confident that the design will work. As always, any support on the Kickstarter is greatly appreciated (see Open Source Gemini Simulator on Kickstarter). I'll also be making a far more in depth post about the navball design on my blog, venturesinmaking.com, Next up: Panel Meters... Thanks! I had actually thought about letting people name the switches, but that idea quickly fell apart because the reality is that all of the switches are going to be fully functional and need actual labels relevant to their functionality.

I wasn’t exactly sure where to post this, but since this is technically an addon I am developing, it made the most sense to put it here. Anyhow… Yes, you read that right, a full size Gemini capsule retrofitted to be a “sim-pit” for KSP. The idea has been floating around in my head, basically since I started playing KSP years ago, but it just never really seemed like KSP, or I, was ready for it. Until now… The point of the project is to produce a Gemini sim-pit that anyone can build with supplies from a Home Depot (or similar) and access to general woodworking tools. The goal is not to create a perfect museum-quality replica of Gemini, but rather something which enables the Gemini experience for KSP without breaking the bank. I decided the best way to make the project happen was to crowdfund it with Kickstarter and in return all of the CAD, documentation, schematics, and software will be made open source for anyone to make their own capsule (or any subcomponent thereof). If the Kickstarter succeeds, I hope to bring the completed capsule to various events (MakerFaire, Gaming Cons, etc…) for people to take it for a spin. The design includes over 50 toggle switches, 10 buttons, mechanical panel meters, alphanumeric 14 segment displays, and 3D printed mechanical navballs (see NeoMorph’s work on his own navball here: http://forum.kerbalspaceprogram.com/index.php?/topic/162666-wip-the-real-nav-ball-project-thread-2017-edition/ his work inspired me enough to create my own navballs very similar to his design for this project). All of these will be connected to functions in KSP using kRPC. Knowing the awesome KSP community I thought this would give everyone a chance to get involved in what (at least I think) is a really awesome project, and I’ve also created some super cool rewards for te Kickstarter. I’ve included some graphics and pictures below of the project work so far. If you want to support the project here is the Kickstarter link (Thanks!): https://www.kickstarter.com/projects/1770837468/open-source-gemini-simulator I’ll be posting here with updates on the project, but I’ll also be detailing the work on my blog: Ventures in Making Now, here are the pics: ***Disclaimer: I read through the forum rules (specifically about monetization), and I don’t think this violates anything forbidden, but if it does, I will gladly remove the post to comply with rules.***

That is the greatest thing ever. The most Kerbal sounding name for the most Kerbal of implements. "Hey guys, what if one pilot can't work any more and the other pilot needs to do both jobs." - Jeb: "Give 'im a stick" "Well then what do we call it?" -Jeb (sarcastically): "I dunno... swizzle stick?" "Alright, problem solved"

I recently came across the following NASA image of the instrument panels for the Gemini spacecraft. I would like to draw your attention to part "A" in the upper left, to a specific component labeled "swizzle stick" Repeated internet searches yield nothing helpful on the matter. Anyone have any ideas what that is for?

I absolutely agree with that statement. Despite being new to the forums, I have been a long time player of KSP (Back in my day, we didn't have no stinkin' Mun!) and I have never gotten bored with sandbox mode. I especially like planning out big orbital construction projects and assembling large interplanetary ships in orbit. Also, as an avid programmer I find that I can spend countless hours with kRPC programming various missions and operations to be automatically executed.

Looking at the pile of stuff you have there is pretty crazy. And all of the different power supplies... I know your pain my friend... Just a suggestion (maybe for version 8?) Have you looking into using something from a 3D printer? You can get RAMPS boards dirt cheap from eBay, and they will give you up to 5 axes of stepper control, and have nice cheap, replaceable Pololu style stepper drivers. http://www.ebay.com/itm/RAMPS-1-4-3D-PRINTER-CONTROLLER-Mega-2560-R3-CH340G-5x-A4988-2A-Drivers-More-/321974766842?hash=item4af7310cfa:g:ggUAAOSwL7VWlds2 These things would work a charm for what you are doing, and then all you would need is one 12v power supply for everything. Plus, the documentation for RAMPS is great. http://reprap.org/wiki/RAMPS_1.4

Wow NeoMorph! That is quite the setup you have! I have been trying to figure out how those navballs worked for quite some time, but I have never been able to figure it out. I would suggest kRPC is the way to go, I am familiar with C# and I used it to send data using USB serial before. Also, I saw in your previous posts about trying to machine the navball on a CNC and the massive hassle that will be. Why not 3D print? You could even print the lines into the ball and then just paint in them to highlight them. Keep up the great work!