My KSP control panel

[stibbons]

I managed to get a new fork of the KSPSerialIO plugin up and running on my hardware. http://spacedock.info/mod/850/KSP Serial IO (cross platform)

[stibbons]

My KSPSerialIO fork has had a handful of updates, fixing things that worked on one platform but not another. It's now run for extended periods on my Linux gaming rig, but I haven't given it very thorough testing on OS X. Would love to hear from anybody who's using it in anger there.

I took the whole setup to the Sydney Mini Maker Faire again this last weekend, and had it running at the stall my maker space had set up. Very popular with kids who loved mashing the big red stage button, and people of all sizes interested in learning how it works.

As part of the prep for that I spent a frantic few days finally wiring up the analogue gauges that show radar altitude and vertical speed. Those things have been sitting in the panel unconnected for more than two years, shame on me.

Work on the new enclosure is going much slower. I'm still having trouble getting acceptable results from the CNC mill. I'm on the verge of giving up and taking my designs to be cut in a professional mill shop. We'll see.

Also having vague thoughts about how to make the plugin side of things easier to work with. I'm tempted to try something new based on telemachus or krpc. And writing my own plugin implementing a protocol similar to the Objects in Space serial protocol is starting to sound like an attractive option.

[Freshmeat]

Gratulations on another great showcase of your skills.

[stibbons]

Thanks @Freshmeat.

Last week I started to re-do some of the perspex panels. Some of them have always looked kinda gross, and others have slowly accumulated battle scars from being carried all over the place. So I picked up a couple of small sheets of new perspex, on Saturday I painted them and got the cutting templates ready (rearranged some parts, recreated the missing text), and last night I quickly cut replacements.

My technique for making these has evolved a fair bit over the last couple of years, and the equipment is currently in much better shape (the laser cutter got a new laser tube recently), so the difference in quality really is remarkable.

The stage panel, especially, looks SO MUCH BETTER NOW. Much happier with the new text placement, and moving the button up a little bit makes it look a lot better to my eye. 

The other ones show similar improvements:

Was going to call it a day here, but after seeing the replacements in action I'm convinced I'm going to have to re-do the rest of the panels as well. Will almost certainly rearrange the display controls while I'm at it, there's a few changes I'd like to make that have been accumulating over the last little while.

[richfiles]

Lookin' good, but I see you've lost "Ludicrous Speed". I don't know how you could possibly get by without that! 
 

[stibbons]

I had a pretty cheap embossing label maker, which broke a while ago. So I had to drive all over Sydney trying to get a new one on the weekend. Finally succeeded! And don't worry, LUDICROUS SPEED will soon be returning.

[richfiles]

HUZZAH! 
What a relief! Jeb likely won't blow up over this... Though he may still blow up because of this! 

Edited August 23, 2016 by richfiles

[Freshmeat]

I never got around to using it before, but I just included your EngNumber library in my code. And it works like a charm once you learn how to use it, so thank you for making it public.

However, I would like to make a suggestion: The digits[] array is int. Is there a reason you did not make it char? Then it could include a decimal point at the proper position instead of having to deal with inserting it afterwards. Right now I call a function whose sole existence is to return a char array with digits[] and a decimal point in its place.

Edit: And what I think is a bug report: a number of format ab.0cde seems to break floatToEng, returning ab.c0 instead of ab.0c. Code to cause the bug, in two functions and a variable definition (lcd2 is my secondary LCD):

const char prefixB[] = { ' ', 'k','M','G','T' }; // decimal prefixes for EngNumber
const char prefixS[] = { ' ','m', 228,'n','p' };


void debugEngNumber() {

    int pre;
	char pstr[80];

	pstr[0] = 'A';
	pstr[1] = 'l';
	pstr[2] = 't';
	pstr[3] = ':';
	pstr[4] = ' ';
	
	engNumF(VData.Alt, 5, pstr);

	for (int i = 11; i < 80; i++) {
		pstr[i] = 65 + i % 24;
	}
	pstr[80] = '\0';

	lcd2.print(pstr);

}

void engNumF(float val, byte pos, char *out) {

	uint8_t pre;
	EngNumber buf;
	floatToEng(val, &buf);
	for (int i = 0; i <= buf.dp; i++) {
		out[pos + i] = buf.digits[i] + 48;
	}
	out[pos + 1 + buf.dp] = '.';
	for (int i = 0; i < ENGNUM_DIGITS - buf.dp; i++) {
		out[pos + 2 + buf.dp + i] = buf.digits[i + buf.dp + 1] + 48;
	}

	if (buf.exponent < 0) {
		pre = (-buf.exponent / 3);
		out[pos+5] = prefixS[pre];
	}
	else {
		pre = (buf.exponent / 3);
		out[pos+5] = prefixB[pre];
	}

}

 

Edited September 11, 2016 by Freshmeat
Bug report

[stibbons]

Glad you like it! 

On 9/11/2016 at 11:03 PM, Freshmeat said:

However, I would like to make a suggestion: The digits[] array is int. Is there a reason you did not make it char? Then it could include a decimal point at the proper position instead of having to deal with inserting it afterwards. Right now I call a function whose sole existence is to return a char array with digits[] and a decimal point in its place.

I wrote it to optimise for using the LedControl library to write numbers to a seven segment display. That library requires a function call for each digit, and when you write a digit you need to specify whether the decimal point after the digit should be turned on. So my code to initialise a LedControl object, create an EngNum object and write it to the display literally looks like this:

LedControl displays = LedControl(14, 16, 10, 1); // 1x MAX7219 drivers using pins 14, 16 and 10.

EngNumber periapsis;
floatToEng(VData.PE, &periapsis);

// Draw the number starting at the first position of the driver at address 0
for (int i=0; i<4; i++) {
  displays.setChar(0, i, periapsis.digits[i], periapsis.dp == i);
}

Keeping the index of the decimal point separate from the digits made it a lot simpler for me to iterate through the digits, as well as checking if the current digit is the one that needs a decimal point after it.

That said, you're doing some double handling that wouldn't be necessary if the library knew how to format a string in the first place. I'm pretty sure I can add a new object with a formatted output string. Will spend a little time on that this week.

On 9/11/2016 at 11:03 PM, Freshmeat said:

And what I think is a bug report: a number of format ab.0cde seems to break floatToEng, returning ab.c0 instead of ab.0c.

I'd noticed my displays doing the same thing.

Pretty sure it's because I was trying to be tricky and round small numbers down to 0, and the broken code to do that ended up in the library when I carved it out of the rest of my sketch. I've been putting up with it, but you've given me incentive to do something about it. Will poke it this week as well.

Edited September 13, 2016 by stibbons

[Freshmeat]

It makes sense using it for 7segs instead of LCD's, and I guess it is easier to convert numbers to chars than the other way around it still does its job remarkably well. As for the .x0 to .0x, no worries. I can live with it fine.

[stibbons]

On 9/11/2016 at 11:03 PM, Freshmeat said:

Edit: And what I think is a bug report: a number of format ab.0cde seems to break floatToEng, returning ab.c0 instead of ab.0c.

For what it's worth, I'm at least able to reproduce this in my unit tests now. And it's broken for any number of zeroes after the decimal point; 1.002 is returned as 1.200 for example. 

[Jonfliesgoats]

This is amazing!  

[stibbons]

Just realised it's been a month and a half since I did any hardware hacking for this project.  Lousy real life getting in the way.

I've cut and prepared replacements for all of the remaining panels. They've been sitting on my work bench for a little while now waiting for me to get the motivation to do all of the rewiring work that will be required to get them in use.

And last week my Teensy 3.6 boards arrived. Those things are nuts, a 32 bit microcontroller, with an FPU, ticking over at 180MHz. I've earmarked one to replace the Teensy 3.2 that's currently rendering the navball, hoping the faster speed and FPU will let me use a slightly more complicated model.

[Sputnix]

34 minutes ago, stibbons said:

And last week my Teensy 3.6 boards arrived. Those things are nuts, a 32 bit microcontroller, with an FPU, ticking over at 180MHz. I've earmarked one to replace the Teensy 3.2 that's currently rendering the navball, hoping the faster speed and FPU will let me use a slightly more complicated model.

Crikey! and I thought my move to a Due was overkill!  

[richfiles]

Well, the thing is generating video, animating a 3D ball, calculating vectors, reticulating splines, the good old fashioned brute force way! No graphics chip to handle it. 

I bought a Raspberry Pi knockoff to basically do the functional equivalent of play a few animated kerbal GIFs on a tiny CRT!
It's SO beyond overkill, but at $15... I am cool with overkill! 

Edited October 12, 2016 by richfiles

[stibbons]

Mostly I'm doing that for the FPU. Was on the verge of rewriting that 3D rendering code to use fixed-point maths, but won't bother now.

[stibbons]

Dribs and drabs of work done on my build recently, but it's all behind the scenes stuff with no pretty pictures or even firm results right now.

My Teensy 3.6 boards turned up, and are waiting for me to get around to rebuilding the display controller.

Haven't yet replaced the rest of the face panels. My current plan is to leave them aside until I'm ready to rebuild the entire controller.

I've almost finished my designs for a new enclosure. This one will be MDF, with an aluminium composite top. I gave up struggling to get the CNC at my maker space working with my materials, but am expecting to get them either cut by a friend or just sent to a professional fab in the next month or so.

I've finally bitten the bullet and started writing a new KSP plugin to drive my controller. My intention is to build a light-weight and modular serial interface, that can support everything I use now and be extended to handle newer bits of KSP that I'd like to include at some point. Super early days for that, but I do have a functioning serial connection and a reasonable idea of what the protocol should look like. All I need to do now is implement enough of it to see if it's actually viable.

[stibbons]

Another wishlist item ticked off. The Arduino Mega at the heart of this project has been using a multiplexer and prototyping shield, with a huge mass of wiring holding everything together. It turned out the multiplexer isn't really required, and was just slowing things down. And quite frankly I'm surprised the rest of the jury-rigged arrangement has surprised this long without any problems. So last week I started work on a replacement shield.

All of the components required for the controls are attached on small circuit boards located close to the controls, so literally all a new shield needs to be is ribbon cable connectors broken out to the Arduino's pins. But it took me a little while to sort out the pin numbering properly - I really wanted to group the inputs and outputs together on to adjacent ports, so I could speed up reads and writes considerably by just doing direct port manipulation instead of reading each pin individually with a digitalRead() call.

Add to that some frustration trying to get a decent template for an Arduino Mega shield, and my slightly arbitrary decision to try out KiCad for this board instead of eagle that I usually use, and what should have been a simple board took me nearly a week of futzing. But it's finally done and I'm about to pull the trigger on a batch of these from OSHPark.

[richfiles]

That board looks very useful! I kinda wish i had one to plop on top of my mega! Love the idea of grouping the ports. I'm not experienced with C yet, but I have read up on what you mentioned about the ports, so that makes plenty of sense. I'm sure it makes plenty of common sense too, as i can say (from experience) that when I wired up my custom mechanical keyboard to it's Teensy 2.0, that it was a nightmare keeping track of rows, columns, pin numbers, and port numbers! Ugh! 

Hows that navball display going? You mentioned rewriting it for the Teensy 3.6, and it's beast of a CPU.

[stibbons]

On 30/11/2016 at 6:27 AM, richfiles said:

Hows that navball display going? You mentioned rewriting it for the Teensy 3.6, and it's beast of a CPU.

It's... sitting by idle. All of my time on this project lately has been spent on working on plugin code, although over the weekend I put a fair amount of time in to working on a new enclosure with pretty terrible results.

But I'm envisioning the 3.6 will be a very simple drop-in replacement for the 3.2 that's running it now. It's all already 3.3V logic (although I think I need to add a level shifter for the I2C bus). The code is all done in Arduino, and should be a trivial rebuild and upload. Once that's done and I've got an idea of performance I'll look at redesigning the navball model and adding more vertices.

[stibbons]

These boards took a little longer to arrive than usual, but they look fantastic. Really love OSHPark PCBs. Totally gratuitous shot of the unassembled board, because they look so pretty.

Populating the board quickly hit a snag - I'd laid out the PCB without measuring the enclosed IDC headers I wanted to use, just kind of guessed on their size. Turned out I severely underestimated how big the enclosure is. Almost all of the labels are obscured, and where connectors are next to each other I had to actually cut off the side walls with a craft knife to make them fit. The cable connectors sit snug next to each other as well, but it works. Here's the new board, alongside the old prototype it'll be replacing. The old board still works, but I'm surprised it was as reliable as it's been over the last couple of years (good grief have I really been working on this for that long?!)

This evening I finally installed the new board in my controller. I wrote a test sketch that sets up the inputs, and just continuously polls them and dumps their current state in a human-readable string to the serial connection. That let me test that all of the connections are sound, without fully powering the board. That's a very big deal because the throttle connector handles 12V for the motorised slider, and can easily fry the arduino if I hook it up wrong.

I had to flip one of the 16 pin connectors (OK, I really cut a new slot out of one side, and dodgily glued the removed material in to the original slot). But apart from that, everything looks like it's working really, really well. Over the course of this week I'll finish up the I2C connection to the other boards, and then work on updating the real controller code to work with this new arrangement.

Finally, getting back to why I put so much effort in to aligning all of the digital inputs in the same logical ports, here's the loop function from my test sketch. I've got 30 digital inputs, and this piece of code shows how I poll all of them using port manipulation

void loop() {
  uint8_t c = PINC;
  uint8_t b = PINB;
  uint8_t l = PINL;
  uint8_t a = PINA;
  snprintf(buffer, 64, "Pin registers: PINC %d | PINB %d | PINL %d | PINA %d",
           c, b, l, a);
  Serial.println(buffer);
}

This is literally an order of magnitude faster than the approach I have to take right now, individually extracting each pin reading from a multiplexer.

[stibbons]

All of the time I've put in to KSP hacking lately has been on plugins.

I made sure that KSPSerialIO is usable on macOS and Linux - check out the spacedock entry for it, or the KSPSerialIO thread:

I've also been working on my own serial plugin. Works on all of the platforms I've tried it on, supports multiple devices, hopefully easy to use. Still early days so it doesn't send too much information yet, but it's coming along nicely.

 

[eberkain]

very inspiring work. 

[cratercracker]

why can't i give more than 1 like!?!? Life is so painful..

[stibbons]

Only vaguely related to this controller project, but for another build I've been playing with electromechanical seven-segment displays. These things have an electromagnet behind each segment - pass current through in one direction to set the segment on, in the other direction to set it off. It's the same technique as flip-disc displays. They're a lot of fun, and very energy efficient as they don't need power to hold state. But the magnets require a lot of power, and driving them has been an interesting challenge.

Last weekend I finally had some success with the driver board I've been working on, and now I'm starting to wonder how to integrate some of these digits in to this build.