My KSP control panel

[Sputnix]

Congrats on having your Kerbal Kontrol panel played by an interwebs celeb!

Some people get all the luck!

Nice one, Stibbons!

It was really awesome to see it in action; I love the switches for the 7-segment displays. Really neat idea!

Do you get much lag with data being sent to the secondary arduino for the displays, or is it negligible?

[stibbons]

The multi function readouts were something I'd planned to do right from the start, and didn't come together until the very end. I'm going to rearrange all of the options soon, but apart from that I'm super happy with how they came out.

I have the packet rate from the plugin down to 80ms, and use the default 38400bps baud rate. In general I don't notice any extra lag. The one exception is lights that react to controls on the board. Right now, I flip the brake switch on, that only sends a command back to the game, and some time later the game sends back a new packet with the updated brake state, and only then does the display module find out that it needs to turn the brake light on. That can occasionally lead to visible delays. It's almost definitely fixable by just broadcasting a new data packet on I2C when an input is changed. Just haven't bothered yet.

My setup survived the maker faire very well. I need to glue the key lock switch in place thanks to kids yanking it around wondering what it does, and the clip I'd quickly attached for my notepad was pulled off. But apart from that it's fine. I didn't get to properly fly it until this week, and am quickly discovering that learning to rely on the readouts is almost as hard as building them.

[Sputnix]

My setup survived the maker faire very well. I need to glue the key lock switch in place thanks to kids yanking it around wondering what it does, and the clip I'd quickly attached for my notepad was pulled off. But apart from that it's fine.

Gosh, you were game letting them play with it!

I had mine on display at a recent education conference, and there were some primary school kids there talking about stuff they were doing in the classroom; and while they were waiting, and I let them have some fun launching rockets into space; but I kept an eye on them. My controller isn't built like something out of Soviet Russia like yours

I didn't get to properly fly it until this week, and am quickly discovering that learning to rely on the readouts is almost as hard as building them.

I was a little surprised as to how much more use having such a console is to the gameplay too

Makes it all the more worthwhile!

[stibbons]

Oh woah, you had your setup on display? Please tell me there's video, or at least some photos of it in action. I'd love to see it.

[Sputnix]

Oh woah, you had your setup on display? Please tell me there's video, or at least some photos of it in action. I'd love to see it.

There was some brief footage shot; for some promo or something. I haven't seen it surface.

I was a part of a display / informational booth on 3D printing, and was using my controller as an example of 'real-world' applications.

I'm wanting to do an over-view video of it and post it here to show how it works (unfortunately, I'm not cool enough to have famous e-celebrities come around ).

However, the latest version of KSP_Serial_IO has communication issues. Amelia and I have informed Zitronen about it; but he hasn't been able to replicate. Which is annoying cos there's a couple of additional elements of the latest I'd like to implement.

We'll get there eventually

I may just revert back to the previous version for my video...

[stibbons]

I know the plugin is having issues on Windows 10, and that'll need some deep plumbing in the serial classes to fix. Are you still having the same issue as in http://forum.kerbalspaceprogram.com/threads/66393-Hardware-Plugin-Arduino-based-physical-display-serial-port-io-tutorial-%2806-Jun%29?p=2105692&viewfull=1#post2105692 where your code won't receive anything but the sample sketch does?

My slightly-educated guess is that that's because of the small serial buffer in the Arduino library. The Serial class uses a 64 byte buffer. Anything larger than that requires multiple reads, faster than data is coming in, otherwise the buffer is overwritten and you get a corrupt packet. The old release had a 189 byte data packet, a little under 3x the buffer size. The new release is up to 190-somethingorother, a bit more than 3x the buffer size so requiring a minimum of four reads to drain it properly.

The example code that is doing very little apart from running the serial connection can keep up with that. But once you start adding more and more in, it becomes harder and harder to perform all of the reading that's required fast enough.

This is just a theory, I haven't really run any of the numbers and have gone to some trouble to put in other safeguards to keep it from happening to me (separate arduino for writing to displays, lots of preemptive optimisation in the input handling). But I'd be curious to see if increasing your serial buffer size (by hacking the HardwareSerial library in the IDE using a guide like http://forum.arduino.cc/index.php?topic=334116.0 ) helps.

Keep a close eye on how much memory your sketch is allocating while playing with the buffer sizes, and keep in mind that the Serial class allocates itself internal buffers as well. You'll probably only be able to afford 255 byte RX and TX buffer sizes on a Mega board.

Edited August 31, 2015 by stibbons

[richfiles]

Interesting... I get most of that, though that all comes from my understanding of things from a hardware side... Bummer that something like that seems to be limiting growth of the packet content... I have a feeling that it's possibly a good thing that I bought a metric assload of cheap Arduino clones from Micro Center the last two times I went up to Minneapolis (Minnesota), for a robotics meet up... I have four Mega 2560 boards, four Pro Mini 5v boards, and a Teensy 3.1 board that I plan to use to make my Apple //c keyboard into a USB/HID keyboard.

I'm actually wondering if I should pre-calculate the 9 multipliers for my synchro emulator, and transmit the 9 multipliers raw (then the sine wave generating Arduino only has to read the sine value from the lookup table, perform 9 multiplies, and then send the 10 sine values (original value, plus the 9 multiplied values) over I2C to the 10 DACs. The multipliers are calculated by bay of some trig calculations, and i'm concerned it might cause a hiccup in my 400 Hz sine waves, if it has to pause too long to both read the serial AND perform the trig calculations.

I can either send 3 raw attitude values in degrees, and perform the trig formulas on them locally, or do that externally, but transmit 9 values... Decisions...

I am certainly not opposed to splitting tasks across multiple pieces of hardware.

On a side note... Has there ever been consideration for interleaving packets. Send smaller packets, but alternate between two or more data sets?

[stibbons]

You're asking the wrong person. I vaguely recall talk of possibly adding another packet type on the off chance the current one fills, but that doesn't seem too likely in the medium term. And it's completely orthogonal to my still untested theory.

[stibbons]

And in actually-working-on-my-controller-again news, after a couple weeks off I finally got around to ordering new LEDs to replace the busted ones. Also picked up a little graphic LCD, I'll be playing with rendering attitude info on to it.

Started trying to have a crack at adding prograde, radial, normal vectors to the KSPSerialIO data packet. Currently lost in a maze of twisty little quaternions, all different.

[richfiles]

What I meant was possibly splitting the existing packet into two smaller packets, giving the buffer a chance to load and read one, before moving on to the other half. I know that'd be entirely dependent on the software being changed to make such a thing possible, but if you find that the issue IS caused by a buffer overflow type situation, then maybe that could be suggested to the creator of the software as an option for future development. I dunno. I've only been playing with the software side of things for 2 months... I've always been a hardware guy before that.

[stibbons]

Today I set out to fix the bodgy power supply situation for my controller.

The majority of the system runs at 5V, but the motor in the throttle slide needs a little more juice. I'd been running the system from a 9V wall wart for a long time, and when the display stuff was finished I'd planned on using a 5V boost/buck regulator to step that down for everything else. But the module I'd ordered from eBay was DOA. Time was short and I didn't have much option but to run up a quick and dirty power system using my original 9V power supply and a second 5V supply for the maker faire. It worked, but I wasn't happy about it, and kind of glossed over the power supply whenever anybody thought to ask.

I have a couple of ATX PSUs spare though. They have 12V, 5V and 3.3V rails, and without knowing for sure the rating for my volume control motor, I figured she'll be right.

So today I voided the warranty on a power supply.

I needed one molex connector, so saved it, the rest of the wires were ruthlessly snipped off at the board level. The only one I needed was the green wire from the motherboard connector. That's the PS_ON pin of the motherboard connector. It needs to be pulled low to ensure the power supply actually switches on, so I just removed the circuit board from the base and soldered the green wire to the bank of ground connections. Put the case back together again (looking very bare with only a single connector coming out of it ), and was quite happy to find the fan spinning up when it was powered it.

I'm too lazy to expose the back of the PSU through the enclosure, so I bought a panel-mount IEC socket. I grabbed one of the thousands of power cables I've accumulated, cut a short length from the IEC plug end, and wired it to my socket making a short panel IEC breakout. Mains cables have a standard colour code, and the back of the socket is clearly labelled with which connection needs to go where. But I still checked my wiring at least half a dozen times, and then asked somebody else at the maker space to double check my work before I applied power to it. 240V is not to be mucked around with.

The final part was quickly drawing up and cutting a new back panel from 3mm MDF. Assembled everything, after carefully heatshrinking and taping up the mains terminals, and it was all good to go for installation. The other holes are for the display mode switch, and a hole for a panel-mount USB socket that's currently on its way from a Chinese factory.

I had to use a keyhole saw to enlarge the hole in the back of the enclosure slightly, because I'm using up a lot more room on the back panel. But after that the replacement panel screwed in quite nicely. The switch on the back sets the display mode. On and off should be obvious. I wrote a separate demo mode just for the maker faire, with the expectation that I'd actually have a chance to leave it alone for a while. That mode just flashes random coloured lights across the annunciator panel while printing messages on the seven segment displays. Seemed like a fun hack to keep the display looking interesting while not actively playing the game.

And then inside the PSU is just fixed in place with some double-sided tape. I used a spare molex line socket to break the 12V and 5V from the PSU out to my terminal block, and from there feed power to my two arduinos and the LED bus.

I was still pretty nervous about powering everything on, my other project right now is getting a 3D printer up and running and last week I managed to short out its power, killing an Arduino Mega, controller board and Raspberry Pi in one fell swoop. But after some careful testing I hooked everything up and was very relieved when it all came back online first go.

The PSU fan running in such a large hollow box sounds a lot louder than I was expecting. I may end up replacing it with a quieter one, or disabling it altogether and adding some other ventilation to the enclosure to move air through it.

[Stoney3K]

Nice and clean looking panels, do you have your own laser cutting machine or do you get that done at a Fablab?

Regarding the trig calculations: Those synchros work on a phase difference, right? Doing trig calculations *in* the AVR is slooooooow, so you really don't want to do that. If you can find a way to precalculate the phase shift for each indicator synchro you want (AFAIK, they're linear with pitch/roll/yaw), you can just pull them out of a look-up table if the table has sufficient resolution.

Small tip: Use multiples of 120 degrees to calculate the look-up values to begin with, so you only need to look up a total of three values, and find the rest of the accompanying synchros by simply skipping 120 degrees in the table. So for example, have a table that has 7200 entries, and for a synchro reading zero, the first coil would get a DAC value at entry 0, the second at entry 2400, and the third at 4800.

That saves you memory and calculations because you only need one table which is the same for every synchro (including the reference one).

I can cook up some AVR/Arduino code that does this for three values easily, it's only a few dozen lines of code.

Edited September 5, 2015 by Stoney3K

[Sputnix]

I know the plugin is having issues on Windows 10, and that'll need some deep plumbing in the serial classes to fix. Are you still having the same issue as in http://forum.kerbalspaceprogram.com/threads/66393-Hardware-Plugin-Arduino-based-physical-display-serial-port-io-tutorial-%2806-Jun%29?p=2105692&viewfull=1#post2105692 where your code won't receive anything but the sample sketch does?

My slightly-educated guess is that that's because of the small serial buffer in the Arduino library. The Serial class uses a 64 byte buffer. Anything larger than that requires multiple reads, faster than data is coming in, otherwise the buffer is overwritten and you get a corrupt packet. The old release had a 189 byte data packet, a little under 3x the buffer size. The new release is up to 190-somethingorother, a bit more than 3x the buffer size so requiring a minimum of four reads to drain it properly.

The example code that is doing very little apart from running the serial connection can keep up with that. But once you start adding more and more in, it becomes harder and harder to perform all of the reading that's required fast enough.

This is just a theory, I haven't really run any of the numbers and have gone to some trouble to put in other safeguards to keep it from happening to me (separate arduino for writing to displays, lots of preemptive optimisation in the input handling). But I'd be curious to see if increasing your serial buffer size (by hacking the HardwareSerial library in the IDE using a guide like http://forum.arduino.cc/index.php?topic=334116.0 ) helps.

Keep a close eye on how much memory your sketch is allocating while playing with the buffer sizes, and keep in mind that the Serial class allocates itself internal buffers as well. You'll probably only be able to afford 255 byte RX and TX buffer sizes on a Mega board.

Hmmz. That's some very interesting insight.

I'm learning a lot through using the Arduino. I'm used to high-level language land where there are no limitations

[there are, but they seem negligible in most environments I've dealt with]

I'll definitely have to look at that. From memory, I was only using like 12% of the available memory.

Thanks for the link RE: Serial buffer size. I'll have a go at that during the week and report my findings here.

So today I voided the warranty on a power supply.

http://i.imgur.com/U6P4xks.jpg

Crikey! You unsoldered the entire bundle of wires!!! o.O

That's super determination right there! Looks fantastic -- but gosh, how long did THAT take you?!

Edited September 5, 2015 by Sputnix

[stibbons]

Nice and clean looking panels, do you have your own laser cutting machine or do you get that done at a Fablab?

Thanks. It's sadly not on my laser, I made them at my local maker space (obligatory Robots and Dinosaurs plug. if you're in or around Sydney check them out).

- - - Updated - - -

I'm learning a lot through using the Arduino. I'm used to high-level language land where there are no limitations

My day job is a system administrator, most of the code I write drives cloud-based infrastructure with a couple thousand instances. Coming home and counting bytes in order to program a real physical device is a very nice change of pace.

Crikey! You unsoldered the entire bundle of wires!!! o.O

Nope! It took me about three minutes to remove them all with a pair of side cutters. That said, all of the different voltages those wires carry are grouped together on the PSU PCB. You can see the black regions for each bus screen-printed on the right-most corner of the board in that picture. And at least on my board all of the wires in the same bus were under a single huge glob of solder. Probably could have desoldered the whole lot in much shorter time than you'd expect.

[stibbons]

First serious attempt at an IVA-only mission to the Mun. Pretty straightforward focussing just on the navball and an occasional look out the window. An instrument Mun landing was nerve-wracking stuff.

[Freshmeat]

Grats on the landing. I have been toying with the idea of using a spare PSU, but it seems like a bit of overkill. How much power does it consume when running your board?

[stibbons]

They're a pretty cheap solution if you need more than 2-3 amps. I'm planning on scrounging up another one for a string of neopixels that pulls 16A at full brightness. But for small projects it's definitely overkill. I only bothered because I needed a higher voltage for the motor. Otherwise a simple 5V power brick is plenty.

Haven't tried to measure how much power it pulls. My back of the envelope calculation for the lights and displays came to peak of around 8 Watts. Average usage is much lower.

[richfiles]

Regarding the trig calculations: Those synchros work on a phase difference, right? Doing trig calculations *in* the AVR is slooooooow, so you really don't want to do that. If you can find a way to precalculate the phase shift for each indicator synchro you want (AFAIK, they're linear with pitch/roll/yaw), you can just pull them out of a look-up table if the table has sufficient resolution.

Small tip: Use multiples of 120 degrees to calculate the look-up values to begin with, so you only need to look up a total of three values, and find the rest of the accompanying synchros by simply skipping 120 degrees in the table. So for example, have a table that has 7200 entries, and for a synchro reading zero, the first coil would get a DAC value at entry 0, the second at entry 2400, and the third at 4800.

That saves you memory and calculations because you only need one table which is the same for every synchro (including the reference one).

I can cook up some AVR/Arduino code that does this for three values easily, it's only a few dozen lines of code.

I'll be VERY honest... I am VERY new to programming C. Mostly, I look at example code online, copy and paste it, figure out how it works, look up some details here and there, and modify it until the compile button throws no errors and the code actually does what I want it to do!

You are more than welcome to help me out in any way you see fit. I won't turn down help from someone more skilled at this stuff than I am at this, although maybe take it to the repository thread (http://forum.kerbalspaceprogram.com/threads/66763-Custom-hardware-simpit-repository-For-people-who-take-KSP-a-little-too-far/page24), where everyone's stuff is, rather than take up stibbon's thread. I've only had a few comments on my own setup here, mostly either asking and comparing what he vs I plan for attitude display, and the use of multiple arduinos to split up tasks. I might start a thread of my own at some point though, but I have nothing actually really put together yet. maybe once things actually start coming together. I'd rather not hijack his personal project thread.

My plan was to do the trig calculations in a spreadsheet, and do a lookup table, like you said. The hard part is getting that from an idea into working code!

Man... it's like 4 AM for me... I'll get back to this... To tired.

Edited September 7, 2015 by richfiles

[Sputnix]

I know the plugin is having issues on Windows 10, and that'll need some deep plumbing in the serial classes to fix. Are you still having the same issue as in http://forum.kerbalspaceprogram.com/threads/66393-Hardware-Plugin-Arduino-based-physical-display-serial-port-io-tutorial-%2806-Jun%29?p=2105692&viewfull=1#post2105692 where your code won't receive anything but the sample sketch does?

My slightly-educated guess is that that's because of the small serial buffer in the Arduino library. The Serial class uses a 64 byte buffer. Anything larger than that requires multiple reads, faster than data is coming in, otherwise the buffer is overwritten and you get a corrupt packet. The old release had a 189 byte data packet, a little under 3x the buffer size. The new release is up to 190-somethingorother, a bit more than 3x the buffer size so requiring a minimum of four reads to drain it properly.

The example code that is doing very little apart from running the serial connection can keep up with that. But once you start adding more and more in, it becomes harder and harder to perform all of the reading that's required fast enough.

This is just a theory, I haven't really run any of the numbers and have gone to some trouble to put in other safeguards to keep it from happening to me (separate arduino for writing to displays, lots of preemptive optimisation in the input handling). But I'd be curious to see if increasing your serial buffer size (by hacking the HardwareSerial library in the IDE using a guide like http://forum.arduino.cc/index.php?topic=334116.0 ) helps.

Keep a close eye on how much memory your sketch is allocating while playing with the buffer sizes, and keep in mind that the Serial class allocates itself internal buffers as well. You'll probably only be able to afford 255 byte RX and TX buffer sizes on a Mega board.

Huzzah! We have life!

Thanks Stibbons! You rock!

[stibbons]

Huzzah! We have life!

So glad you're back up and running. I wish it were easier to set Serial buffer sizes than hacking system library source code though.

This week the graphic LCD I ordered to experiment with arrived. It's a little on the smallish side, but not too bad. But Adafruit's library for it is a lot slimmer than their other display libraries. I spent a little bit of time trying to port catmacey's external navball code but got a little bit discouraged when I realised the library currently doesn't have anything for drawing triangles. So updating the library to work with Adafruit-GFX-Library just got added to my todo list.

[Sputnix]

So glad you're back up and running. I wish it were easier to set Serial buffer sizes than hacking system library source code though.

This week the graphic LCD I ordered to experiment with arrived. It's a little on the smallish side, but not too bad. But Adafruit's library for it is a lot slimmer than their other display libraries. I spent a little bit of time trying to port catmacey's external navball code but got a little bit discouraged when I realised the library currently doesn't have anything for drawing triangles. So updating the library to work with Adafruit-GFX-Library just got added to my todo list.

Thanks! It's nice to be back (into the land of coding + playing!).

Gosh. That's way too hardcore man :/ puts the rest of us to shame.

What made you choose that LCD display?

[stibbons]

Heh, I chose that display because a) it has an RGB backlight and I'm a huge sucker for blinkenlights and littlebird had it in stock for overnight shipping.

They're also pretty cheap, somewhere around twenty bucks a pop. I may just buy a display using another controller and put this one in the parts bin for a less demanding project.

[stibbons]

Very minor update. It looks like u8glib has all of the graphical primitives I need without extensive library hacking. I've started playing around with it for another project and am pretty keen to see how well it runs for complex graphics.

That said, I've since found another use for the display I bought. So right now the display stuff is on hold. Do want to see what I can do about getting my controller running properly on Windows 10 and on Linux, but it'll be another week or two before I have time for it.

[BigDCowboys22]

Do want to see what I can do about getting my controller running properly on Windows 10 and on Linux, but it'll be another week or two before I have time for it.

First off I want to say thanks for posting all that you have. You inspired me to start making my own controller, heavily leveraging your designs and code. So thanks for everything. Even though I've really just been the creepy guy lurking in the corner.

I was making good, albeit slow progress and had my controller working for the most part before I built a new computer. Of course me being an idiot I went straight for windows 10 without doing all my research, and I'm now stuck without being able to use my controller.

This is a long winded way of saying thanks for posting all your info, and I'm extremely interested in figuring out how to get everything working in windows 10. I don't have much programming knowledge, but if there's anything I can do to help along the way please let me know.

[stibbons]

You inspired me to start making my own controller, heavily leveraging your designs and code. So thanks for everything. Even though I've really just been the creepy guy lurking in the corner.

All good. I'm looking forward to seeing you post your own progress!

As far as the Windows 10 thing goes, real life and other projects have been taking priority over this for the last few weeks, so I haven't really had much to do with it. Do check out the last few pages of discussion on the KSPSerialIO thread though. It looks like a lot of progress has been made, just needs more people to test and confirm it's all working.