stibbons

Roverdude's USI Kolonization System has already been brought up. I'm using that in conjunction with Extraplanetary Launchpads for offworld construction. SCANSat extends the stock resource scanning experience. You may prefer Karbonite to extend the stock resource system. And I'm using TAC life support for kerbal resource requirements, but I hear USI life support and the Snacks mod are also pretty good for that.

I love those embossed labels. Thought about using them on my controller as well. Ended up etching labels instead, but almost everything I own now has an embossed tag. They work really well for your hardware too.

The motorised throttle was originally intended just to zero the throttle on vessel change - adding the toggle switch for presets was almost an afterthought. I had a hand in writing the current throttle code for KSPSerialIO, updating it so that the controller throttle and keyboard controls will (kind of) play along. In general the controller's idea of throttle control is king, unless something like RemoteTech or kOS (I've never tried Mechjeb) overrides throttle control entirely. At any rate, KSPSerialIO does not yet send the final throttle level back to the controller, so any more fine-grained control isn't really an option at the moment. No cool pictures of current progress, but I've sorted out one of the programming challenges I was very nervous about. The displays will be driven by a second arduino microcontroller, and shunting VesselData between them using I2C was a significant problem. Arduino provides the Wire library for I2C, but it's really not cut out for my use case. First, it's synchronous, so calls to send data using it block until the data has all been sent. This strikes me as an incredible waste of the nice interrupt-driven hardware TWI module on Atmel chips. Second, it uses a maximum 32 byte buffer, and allocates quite a few of them internally. Increasing that to cope with the 190 byte VesselData packet KSPSerialIO uses would chew up almost all of the RAM on a Uno or Leonardo processor. I'd have to juggle looping through and manually blatting 32 byte chunks on to the I2C bus, along with sending and receiving through the UART and a fair amount of button handling. It was looking grim. I tried a few different approaches. There's some alternative I2C drivers around for Arduino, but the all work on the assumption that they'll only be running on master devices, fetching data from peripheral slaves. Nobody seems to have done much work on optimising Arduino I2C slave drivers. My solution eventually came from reading Atmel's TWI application notes, AVR311 and AVR315, and adapting their sample master and slave drivers to run in the arduino environment. Took a couple of evenings work, but I've updated the Arduino Mega in my controller to also broadcast VesselData packages on to an I2C bus as soon as they're received. That happens asynchronously - I just make a function call and pass it a pointer to my data, and the driver uses an interrupt handler to marshall data in to the TWI module while my code carries on doing other stuff. Looks like that's happening without slowing anything else down so far. I also wrote a quick test sketch on a slave arduino that receives VesselData packets from I2C and writes data from it to the serial console. Enough of a proof of concept that I'll be able to start writing code for my displays immediately when they're up and running. Pretty happy with how that panned out.

Basic functionality should be fine with the joystick mode they say is in beta right now. But I'd be very curious to see the SDK, and I suspect rolling your own control code (integrating with KSPSerialIO, say) would be required to get any use out of the display modules. Those modules look really nice. You'd be able to buy components for cheaper, but the finish and the modularity would be much harder to replicate.

Debian on all of my personal machines, most of my work environment is Ubuntu.

Thanks, coming from somebody building that amazing chair it means a lot. Going to be a fairly slow week, with lots of parts still in the mail and real life not leaving enough time for the little bits that I wanted to do. Full steam ahead painting and mounting components over the weekend though.

A very long and productive Saturday. Taped my templates on to the board, drilled guide holes for the mounting screws, then got to work with a jigsaw cutting holes for the panel components. Checked the finished panels for fit, and everything's looking *awesome*. The board is all prepped, and I've laser cut the last of the instrument panels. Next up is painting the enclosure and finishing construction and mounting the panels.

I wouldn't mind a vessel viewer or VAB app. If you want more than that, just install SimpleRockets.

I can only think of one or two possible explanations. Obviously, if you don't set the pinMode to INTERNAL_PULLUP, then it won't work. Alternatively, if you're using a cheaper arduino clone board, it's possible it has a different processor or a counterfeit Atmel chip with wonky or nonexistent internal pullups.

If you're using pull-up resistors as described in the video, multiple buttons should be wired like this: Using pull-down resistors is the same, just swapping VCC and GND. But I'm not sure what you mean by wiring your resistors in series. There's two options I can think of. If you do it like this: then you're shorting all of your input pins together - pushing one button will result in all of the inputs being low. On the other hand, doing it like this: means that all of your input pins are still floating, and all bets are off. It's entirely possible that a setup like this will result in one group of identical switches not working, and another group of identical switches working. Depending on air temperature and humidity, phase of the moon and the last time you saw a brindle goat. And finally, because I know somebody else will point it out if I don't, the Atmel microcontrollers in Arduino Uno and Mega boards have built-in pull-up resistors. That means you can save yourself some wiring and use a layout like this: But if you choose to do this, then you need to tell the Arduino that you want to enable the internal pullup, by setting the pin mode to INPUT_PULLUP. pinMode(Switch1_Pin, INPUT_PULLUP); There. I hope that makes things... um... slightly less confusing?

(I can highly suggest not looking at my code though. It's a mess. )

Almost everybody who's building projects using this plugin are publishing build logs and source code. You should also have a look through the custom hardware repository thread, and look for [Hardware] tagged threads in the Fan Works forum for examples.

Yeah, I read the attitude code from mechjeb this morning and cried a little bit. I had no idea reference frames were so complicated though, goes to show how much of a plugin n00b I am.

(I'm also crazy enough to be completely happy maintaining my own fork with bits nobody else wants ) You're already using Orbit.GetVel for orbital velocity. Pitch and heading are just the x and y components of that vector, aren't they? I suspect only sending prograde would cut down on packet size, retrograde can be calculated by flipping the heading. The extra space would be better used sending orbit normal and radial vectors.

Very nice work. I like how you're using the indicator LED on the stage button, think I might have to borrow that idea for my controller. What's the enclosure built from? I'm also curious about how you got the Saitek mounted, just disassemble the original box and screw it in to the panel?

Definitely check out the AntennaRange and RemoteTech mods. There's also a RemoteTech contract pack that offers contracts for establishing satellite networks around different bodies.

This week I ordered what should be the last of the bits and pieces I need for assembly. Components I didn't yet have for the electronics, assorted enclosure hardware, cabling, a 5V buck converter to step down the 12V I'm feeding in to the system. The biggest surprise was the bag of 50 3mm LEDs for a dollar including shipping. Oh, and I'm up to pretty much the hardest part so far - deciding what colour to paint the enclosure.

I think kerd will be providing the navball and orbital map for my KSP controller. This looks really nice, fantastic work Lokaltog!

No mechjeb, but I use KER for data display, RemoteTech's flight computer for sequencing maneuvers, and am starting to get in to writing my own autopilots with kOS.

Thanks. I had a play with a couple of ideas for retrieving the next relevant patch, and came up with something that should work well in most scenarios. It adds FarSOI, FarAp and FarPe to the VesselData packet, and shows details of an intercept with the next moon or planet, or your solar orbit if you're on an escape trajectory. It's late here so I've only properly tested it on Mun intercepts, escape orbits and a Duna intercept. Will play around with it some more the next few days before I stick it in a PR.

And 1m/s is close enough to 6000 furlongs per fortnight.

MESA is the OpenGL implementation most Linux distributions use. Yes, you need it. But it should already be installed, the majority of modern desktops use some sort of 3D compositing by default.

Hey zitronen, any chance you could update the github repository? Looks like the last version there is 0.17.1.

Almost all of my launches, especially the smaller missions, use exclusively SRBs for the first stage. A satellite booster will have a single LFO stack with 2 or 4 radial SRBs, and they'll use SRB power to get up to around 10km altitude. I'll even stagger them - a Mun satellite might have a launch vehicle with two radial SRBs throttled back to 50% and two throttled back to 25%, staged to detach each pair when they're out of fuel. That can easily get you to 20km with some practice, and needs not much fuel to get to orbit after that.

I hadn't thought as far ahead as updating the plugin yet. But yeah, looking at the Orbit class, it seems like walking the list of patches is an easy enough problem to solve. Would it be enough to just get the next patch, or is there value in looking further ahead? Watching how patches transition would let you make educated guesses as to what's happening, and pull off stunts like showing Duna AP while still burning in Kerbin's orbit on a transfer.