stibbons

Went down to my local hardware shop last night and picked up a portable 15W fluorescent tube work light and quickly taped that to the inside of my enclosure as a panel backlight. This'll do quite nicely for making it the lettering bright and readable during the day. In the dark it shows through the paint on the panels a little too much though. If/when I remake the panels I'll add a couple more coats of paint, and try to be a little more careful with the lettering. Still, it's a pretty great effect. I've since added some masking tape on the back around the annunciator box to stop light coming through. Would like to get something in place for the slot for the throttle slider too, but that's on the back burner for now.

Woo, lots of awesome responses. I don't fly planes at all, so not sure how much of a run they'd get. But who am I to say no? Can and will. Thanks very much. Perfect! Looking forward to seeing a download. These are both fantastic. Would love the craft files. And you pretty much nailed it with the "first vessels" approach. Thanks very much for the input so far. I really appreciate the help here.

Hello ship builders. So here's the thing. I've been building a control panel for KSP. It's almost complete, certainly flight ready, and this weekend I'll be demoing it at the Sydney Mini Maker Faire. Basically that means I'll be spending two days playing Kerbal Space Program with a great big control desk with people who may or may not have seen the game before. Pretty cool right? Now, to speed things up and avoid spending long periods during the event on ship-building, I would like to have a bunch of ready-to-go vessels to fly for different objectives. I'm really not that great at designing ships, so I was hoping the fine folk here could help out with vessel suggestions. Here's the rules: Stock parts only. I'm installing all of the visual and sound enhancements I think I can get away with, but don't want to add any part packs. Mostly because I've never really used any of them and don't want to have to explain them, sorry. Easy to fly vessels. I don't think it's reasonable to try to explain to a newbie how to use custom action groups to switch between three different types of engines to get an SSTO to orbit. Especially when there's a big red stage button longing to be whacked. I'm looking for well-balanced, stable ascent vehicles. Landers that are easily managed and can cope with mild abuse. That sort of thing. Stuff that looks good. This is where all of my designs fail miserably. Here are the kinds of missions I was thinking could be easily run, and what I've dug up so far to do them with, looking on this forum and KerbalX: A Kerbin orbit space station. Something that vessels launching from Kerbin can dock with. I've pretty much settled on using this ISS replica. But open to other suggestions! An LKO vehicle. Something that can launch from KSC and dock with the orbital station at around 500km orbit. I was thinking about just using the Kerbal X modified with a docking port on the nose, but am a little bit nervous about the asparagus staging it uses. Alternatives welcome! A Mun lander and return mission. I was thinking about using the Apollo 12 vessel for a realistic Kerbin moon landing. I'd be very interested to see any other vessels for a simple moon landing and return. A moon base, probably Minmus. I'd like to assemble a base on Minmus using Rune's base-in-a-box. Just a small base that we can aim landings at. A dedicated lander. I'd be keen to get links to descent and lander subassemblies. Stuff that I can hyperedit to a moon or any of the other bodies and have folk try to land. Even upper stages that can manage a landing, then lift off and return to Kerbin would be fun. I haven't yet found any good vessels for this that are guaranteed 1.0.4 compatible. That's all I can think of. I'd love to hear about any other ideas people might have for this sort of demo, as well as links to ready to fly craft for it.

Yeah, it's pretty large. 800mm wide, and the control panel is 450mm deep. I always wanted it vaguely arranged this way, most controls along the bottom and displays above. And after that, well, I saved myself a cut using MDF that was 450mm wide. The electronics are currently mounted on the back of the lid in the top left corner. Future plans are slightly vague, but include a brightness knob and rotary switch for display presets. And a smallish screen. In the immediate term, though, there's enough space to stick a small keyboard in the top left corner (because you still need one for quite a few things, sadly). And I have a 7" tablet that'll fit in the space in the top right that I'm trialling KeRD on.

The first very very rough pass that works for my incredibly narrow use case is engnumber.h and enbnumber.cpp. It was based on a thread on the arduino forums about optimising the Print::printFloat method, but I've modified it to take a struct containing an array for the numbers, and ints for exponent and position of the decimal point. That's all there is right now, but I'll tidy it up and make an actual library next week.

Lots of hacking the last few days. I have four seven-segment displays, each with exponent indicator lights (kilo, mega, giga), and illuminated push-buttons to select what information the display will show. All of those lights had to be checked, and I had to make sure that the input multiplexer was relaying all of the button signals that I needed. That part wasn't too bad, and worked great. Then I wrote the code to handle a single selection for each display, and lighting up the appropriate indicators for that. Much more fun, but again a fairly straightforward problem to solve. Finally was the code to take floats from KSPSerialIO, and render them down to engineering notation with four significant digits, to be written to the displays. I had an outline for code that I wrote a little while ago for that, which turned out to be slow and almost but not quite completely broken. After a couple of attempts I eventually gave up and looked for somebody else's code. In the end I've adapted an unmerged pull request to the Arduino's Print library to support rendering floats in engineering notation. Pared it back to stick ints in to a fixed array instead of writing them to a serial port, and I was in business. Finally, late this evening, I had my first launch with my fully-functional controller. Everything works, but there's still a bunch of work I can do to improve the experience. Right now the displays show seconds as decimals, when I'd rather have it flick between "seconds.fractions", "minutes.seconds" and "hours.minutes". They also render low numbers < 100 or so untidily, and break down entirely with things like inclination < 0.1. I need to redo the demo mode, which will just blink random lights across the panel. And I really need to arrange backlighting. Right now the lettering can be fairly hard to read, but quick tests with a spare lamp in the enclosure show it lighting up quite nicely. I think the first version of the backlight will just be a cheap table lamp or something bolted inside.

Sorry I don't have any time to test it further at the moment. I'm taking my controller to a maker faire next week(!!!), and just needed something that works. Happy to reinstall Win10 after that if there's anything I can do to get to the bottom of it.

My Saturday was nearly a disaster. Woke up early to discover reports of issues running KSPSerialIO under Windows 10. I'd just upgraded my gaming rig to a new machine running Win10 (Microsoft's online store only seemed to sell the one version in Australia, go figure). So fired it up and, sure enough, a test sketch running on a spare Arduino just wouldn't connect. There's some interesting leads in the KSPSerialIO thread about resolving the issue, but I'm under some time pressure to get my build complete and functional so I eventually sighed and dug out the old Windows 7 retail box I had hiding in the back of a drawer. Then I sighed again and yanked the DVD-ROM drive out of my media centre machine so I could get it installed. While that was catching up with eleventy Windows updates I tidied up the hardware for my build. Routed all the cables neatly and taped them in place. Cleaned and vacuumed the inside of the enclosure and made sure everything that needed labels had labels. Finally I made button caps for my little illuminated tactile buttons by cutting circles from my translucent perspex and glueing them to the buttons. And then I had to disassemble some of them to remove the glue that was gumming up the action. At this point I'm considering the hardware 1.0 complete. There's still a couple of blown LEDs that need to be replaced and my analogue gauges are purely decorative right now, but unless there's an emergency I'm not touching any of it for a few weeks. After one final test to ensure all of the control inputs were functional, I plugged in and ran an in-game test. That was the first time some of this stuff had been used, and the first time I'd ran any of the other panels for a couple of months. Everything ran beautifully, and even without the displays functional it was great to be able to prove to everybody else in the maker space that this huge lump of wiring I'd been poking at for ages actually does something. And then I brought it all home again. Right now the controller is occupying... pretty much all of the coffee table in my living room while I write the display code. Turns out it's way too big to fit on the desk in the study, so it's here until I arrange a new one.

I got as far as confirming that Marzubus' cross-platform serial plugin wasn't working for me on Windows 10 either, and have now given up. Hooray for wasting a day installing Windows 7!

It targets 2.0? Huh. I'd assumed it would be 3.5 as well. At any rate, I've installed .NET 3.5 (which also pulls in 2.0 and 3.0). It's available in the Windows Features install guy. Doesn't seem to have helped me, but I'm checking to make sure I've got the right versions of everything.

I'm having trouble running it on a new install under Windows 10 too. :/ No problems at all running the game, but the serial connection is not established. Have tried Windows 8 compatibility mode with no luck. Am hoping it's something simple and rebuilding the plugin on a Windows 10 machine will be enough to get it running.

It's a licensing thing. I'll happily buy arduino-compatible boards from anybody, as long as they respect the Arduino licence. I won't buy from counterfeit manufacturers making fake "official" Arduino kit. - - - Updated - - - This evening I ripped out and replaced all of the slightly dodgy wiring connecting my LEDs and replaced it all with slightly less dodgy wiring. Careful checking during that found three dead LEDs. Chalking that up to carelessness. The rest were reconnected and seem good so far. Unfortunately I'm out of spares, so it might be a little while before I can replace seem. Such is life.

Yeah, I'm a big fan of proper arduino-compatibles, but stay away from outright imitations. That usually rules out the ultra-cheap ebay boards. Went with the pro mini because I wanted a Leonardo based board. Normally I'd use something like a Leostick for that, which adds both ICSP and a much sturdier USB connector, but here we are. Luckily the replacement arrived this afternoon, so I can go and start hacking on it some more after work. The original board still works fine, so once I've got the code down pat I may hold the connector on and flash it, keep this one for another project.

Welcome back! Your project's coming along great. Drawing a navball on a small screen with a uC isn't impossible - is a pretty neat demo doing it with a PIC. I'm idly considering it for 1.1 of my build, but would want to dedicate a separate controller to it. I'm not sure I'd want to put much effort in to it until the KSPSerialIO VData includes useful vectors.Orbital minimap sounds like an awesome compromise though!

I did a fresh install of Windows 10 and have had no trouble running KSP. Read the bug reporting guide for details of how to include the log information people need to help figure out what might be going wrong.

One step forward, several steps back. First, I picked up some transparency film to redo the annunciator display. That stuff is relatively expensive, I paid about a dollar an A4 sheet. But it seems to be a pretty good compromise - just thin enough to let plenty of light through without being able to see inside. Looks darker when it's turned off, and much brighter when it's running. Now you can see where I dropped the annunciator box and broke a corner off. And then I started writing test code to actually control the LEDs. Started by lighting each one in turn, just cycling through all 31(!!) one after the other. That revealed what looked like communication issues because I was powering the LEDs separately to the arduino, and didn't have a common ground. So this evening I arranged a common ground plane and tested again. That looked better running one at a time, so I started updating my actual controller code to start lighting up appropriate LEDs. Having a few of them switch on and off depending on how switches on the display were set was working fine, so I figured it was time to start testing in-game. This led to problem number 2. I just could not get the arduino talking properly to KSP on my mac laptop. Granted, it's an underpowered Mac Air that struggles to run the game at all, but I couldn't do anything to reduce the number of dropped packets. There were enough packets getting back and forth that I could say it... probably works OK. But I won't be able to move my gaming PC up to the maker space I've been keeping the controller at the last couple of weeks until Saturday. It makes testing things pretty annoying. So I put that aside for a while and started working on the one other feature I'd like out of this panel - a demo mode that doesn't render data from the game, just strobes random colours and some canned messages across the displays. I want it to look vaguely interesting while not playing a game. So I started testing code that would write random colours to all of the LEDs in my string. And that's how I discovered the third problem. Lighting up a handful of LEDs is OK, but writing values out to all of them reasonably rapidly leads to major issues, eventually the whole string seemed to just stop updating. I couldn't figure out where this was coming from, and my troubleshooting only made things worse. The whole experience was remarkably similar to installing OpenBSD. At various points I was accidentally shorting out the signal cable, feeding the LED signal in to the throttle motor, and trying to push data in to the out pin of a few lights. I've completely rewired how the LEDs are getting power and checked all of them to make sure there's no brownouts. Right now I have a vague suspicion one or two of them have had their controller cooked by my shenanigans, so will start trying to bypass them to confirm tomorrow. EDIT: Oh man, I forgot the best bit. For the display controller I'm using a SparkFun Pro Micro board. That thing has a tiny little micro-USB connector soldered on to the end, and a couple days ago I discovered that it's fairly fragile. An accidental hard yank of the cable pulled the connector right off the board. I was able to solder it back on after a couple of tries, but one of the solder pads carrying power had been ripped off so I had to power the board externally. And that attempt didn't last too long either, it came off again and I'm not sure I can fix it. There's another one coming to me express post, but if that doesn't arrive tomorrow it's really going to make my plans for getting the seven segment displays running.

Only suggestion I have for the rendering glitches is to wind down the texture quality until they go away. That means my mac air runs with 1/8th res textures, but it does work.

Curious to know if anybody else is using this code on actual hardware. I finally got to test it fully on my reassembled and expanded system this evening (after doing basic func tests running the example sketch on a bare arduino) and had all manner of problems. Still trying to track down precisely where the error is coming from, but it would be nice to be able to confirm the plugin is working for others.

Glad you like it. Current status is that all of the control inputs are working. I've got some of the status lights up, but the annunciator and the seven segment displays don't really have any code at all. And this evening was a fairly frustrating one struggling with the power supply and trying to get it running on my OSX laptop. I really want to shoot a video, but to be honest I'm not happy doing it right now. Will definitely work on getting some footage explaining how it works once it's finished. - - - Updated - - - I missed your remark about the perspex before, sorry. The instrument panels are cut from 3mm opal perspex that I've painted on one side. I bought a square metre of the stuff for this project and still have maybe a quarter of it left untouched. It could work, but I don't think I'd want to use something that thick as a diffuser for the annunciator because of light bleeding across compartments. I might drop by Reverse Garbage this weekend and have a rifle through their perspex stock to see if they have anything that might suit.

Settings menu -> Input -> Game, and set the "Focus Next Vessel" and "Focus Previous Vessel" keys to whatever you need.

The files are not useless. Read the directory and file names, they are the documentation.

Music for munar descents.

I did a little bit of poking around, eventually found something at Eckersleys that should fit the bill. It's still something like a dollar per A4 page, but I'd be willing to pick up half a dozen at that price to play with. If Victoria has any of those shops you should check them out. Oh, this is translucent "tracing paper" film I'm talking about, not plain transparency film. Kind of surprised officeworks doesn't have reams of that stuff lying around.

Hey Mulbin, care to add my project to your post? I've been updating http://forum.kerbalspaceprogram.com/threads/102513-My-KSP-control-panel with build progress, and it currently looks like this: http://i.imgur.com/3INZrTm.jpg