My KSP control panel

[stibbons]

Another really tiny inconsequential update. My gaming rig now dual boots Windows 10 and Linux. I've finally got the KSPSerialIO plugin to the point where it seems fairly stable on Linux, and my controller is actually usable again for the first time in a few weeks. The display I was planning on using for my controller has been repurposed for another project. But I've got my eye on a 5" full colour job, which would be really fun to integrate.

[Freshmeat]

But I've got my eye on a 5" full colour job, which would be really fun to integrate.

Wow. I'm looking forward to be impressed. Via LCD or TVOut libraries?

[stibbons]

Wow. I'm looking forward to be impressed. Via LCD or TVOut libraries?

Neither. The controller would be this Adafruit board, which has an SPI interface that would plug in to an Arduino.

I'm planning on running the code catmacey wrote for a 3D rendered navball here:

[richfiles]

That virtual navball looks amazing! I'm still stuck at just simply not having the software experience to do mine yet, and still not really having viable hardware yet.

[BigDCowboys22]

Another really tiny inconsequential update. My gaming rig now dual boots Windows 10 and Linux. I've finally got the KSPSerialIO plugin to the point where it seems fairly stable on Linux, and my controller is actually usable again for the first time in a few weeks. The display I was planning on using for my controller has been repurposed for another project. But I've got my eye on a 5" full colour job, which would be really fun to integrate.

What Linux did you go with? I've been thinking about dual boot as well, but it seems a little overwhelming at the moment. Knowing what someone else has successfully done might make it more approachable.

[stibbons]

Not sure I'll be very helpful for your situation, I'm a professional Linux sysadmin and have been running Linux on my desktop for nearly twenty years.

All of my home machines run Debian. If you use Steam, go with what they recommend (Ubuntu, I think). Otherwise I'd suggest Ubuntu or one of its derivatives.

[stibbons]

Finally had some success drawing on an LCD. It's a rough first pass, and still pretty choppy because the code is full of floats and is running on a Uno. Planning on converting it all to fixed point math, and grabbing a teensy or similar to drive it.

[stibbons]

Lots of little bits of hacking on the navball code:

• The RA8875 display controller I'm using has hardware support for separate drawing layers. It has to drop back to 8-bit colours to use two layers on the 800x480 display I'm using, but that's a worthwhile tradeoff. I spent some time figuring out how to use the layers to implement double-buffering. All of the slow drawing happens on the layer that isn't visible, and then the controller can switch layers with a single function call. That eliminated all of the flickering in the solid faces, and makes it look a lot smoother.
  
• I toyed with a couple of ideas for drawing icons for vectors on to the ball. The most obvious is just drawing bitmaps. The original navball code I'm working with did that for the level indicator. But I found sending bitmap data through the SPI connection is hugely inefficient, and the Uno can barely cope with it. The next was creating them as 3d models. I'm still thinking seriously about doing that anyway. But the solution I'm working with now is creating them as symbols in a custom font. I draw them up in 8x16 grids in a pixel editor and convert them to arrays of ints. They get uploaded to the controller once at startup, and drawing them is as simple as positioning the cursor and drawing text. Fastest option, but I'm not sure if it's worth the maintenance. The level indicator is 16 characters, which will have to be redrawn if (when) I rescale the ball.
  
• I started playing with colour schemes. It's a little bit annoying because all of the supplied constants in the library seem to assume a 16 bit colour display, and the way colours work is non-obvious. What I've got now is definitely a first draft.
  

And then, today the Teensy 3.2 I ordered for this project arrived. The Uno has an 8 bit ATmega328P running at 16MHz. The Teensy has a 32 bit Cortex-M4 running at 96MHz. So while my demo code could manage 10fps and a little bit more on the Uno, the exact same code was rendering smoothly at 30fps on the Teensy. I'll be locking it to 15fps for the final product, because data is coming from the game at 12.5Hz and I'm too lazy to bother with any sort of interpolation. But I'm confident that the hardware I have now will handle much more complicated drawing with ease.

This video was when I had the Teensy rendering 20fps. Still not sure where the vertical lines are coming from, I suspect bugs in the vertex rotation are occasionally pushing vertices way off screen, leading to wacky triangle drawing.

[richfiles]

Man, this is gonna look SO GOOD once it's done and installed!

Mine is still doing zip!

[stibbons]

Surprisingly long day drawing little 32x32 pixel icons for the various vectors I want to show on the navball. But they're all there, and most of the supporting code to take a relative offset and turn that in to a 2D position to draw the icon.

Next step, I guess, is polishing off my additions to KSPSerialIO to handle the other vectors and get that published.

[richfiles]

I haven't been following KSPserialIO for a bit, cause I've been focusing on the hardware... Last I looked, we didn't have the vectors yet, only the attitude. I take it you are calculating these somehow, or is it a version of KSPserialIO with those values incorporated?

I, sadly, can't display the classic icons, but I do have crosshairs on my FDAI, so I figure I can have a selector to select the vector axis, and another to select the pro-pos/retro-anti aspect. Doing that would let my crosshairs display the selected vector. I might also use the pushbuttons on my DSKY keypad for that, but I REEEEEALY want some rotary switches somewhere!

One can not argue that glass cockpits are versatile, but physical navballs though... Are just plain cool!

[stibbons]

Yeah, there's nothing in the plugin to communicate those vectors yet. I spent some time last week figuring out a method that I think is working, and there's a branch in my KSPSerialIO repo that is logging numbers for them that look about right. Some time this week I'll get around to actually implementing all of the needed bits to add it in, and then plug all of my hardware together and write the glue code to actually display them. Hopefully this week.

[richfiles]

I forget, are you working off of zitronen's original version, or marzibus's Mac/Linux compatible variant?

Dang... Your work could make navballs in simpits and consoles downright simple! With how cheap these Arduino and OLED or whatever parts are... Anyone can have one!

I better hurry up and make my hardware version while it's still a cool thing to do!

Truth is, I am TERRIBLE with coding. I haven't done this kind of thing in a decade and a half, and prior to that, I only knew TI-BASIC and BASIC.

Everything is new to me again, and I've been either so busy, or so busy screwing with hardware that I've genuinely not had any time to develop my coding skills since I initially got those 8 displays all lit up. Ugh... Just terrible! Hardware... I know hardware...

[stibbons]

Long story short, both. I work in a branch based on zitronen's repo, and periodically merge that with a branch based on marzubus' fork (because that's what I run on my system). When it's done I raise a PR with zitronen, and once that's merged I merge the zitronen master branch in a new marzubus branch and raise another PR against that one.

My local KSPSerialIO repository currently has four remote repositories defined, and I'm starting to have trouble keeping track of everything. Relying heavily on branch descriptions and git notes.

[stibbons]

So here's how I planned on using multiple microcontrollers in my panel:

• A master manages the connection to the PC, and acts as a master on an I2C bus.
  
• One or more slave microcontrollers register on the I2C bus as slave devices.
  
• Whenever the master receives a VesselData packet from the PC, it sends that packet on the I2C bus, using the general call address.
  
• I don't currently have any plans for slaves to be able to send data back, but if the need arises the master can poll them.
  

I'd implemented this system using an Arduino Mega 2560 as the master, and a Pro Micro as the first slave running the seven segment displays on my current board, and everything works great.

This afternoon I started trying to integrate the Teensy running my navball display, as a second slave on the I2C, but ran in to issues with it fairly quickly. Turns out the i2c_t3 library for Teensys does not support general call packets. Probably something I should have checked before trying it instead of blindly assuming it'd work, but still.

I think hacking the library to support general call shouldn't be much more than flipping the appropriate register during initialisation, but it's still a fairly intimidating proposition for me. So I may end up just updating my master to send packets to slaves individually. That seems gross and inefficient, but I should have enough spare CPU cycles on the master to get it done without any lag.

[Sputnix]

[quote name='stibbons']So here's how I planned on using multiple microcontrollers in my panel:

[LIST]
[*]A master manages the connection to the PC, and acts as a master on an I2C bus.
[*]One or more slave microcontrollers register on the I2C bus as slave devices.
[*]Whenever the master receives a VesselData packet from the PC, it sends that packet on the I2C bus, using the [URL="http://www.i2c-bus.org/addressing/general-call-address/"]general call address[/URL].
[*]I don't currently have any plans for slaves to be able to send data back, but if the need arises the master can poll them.
[/LIST]

I'd implemented this system using an Arduino Mega 2560 as the master, and a Pro Micro as the first slave running the seven segment displays on my current board, and everything works great.

This afternoon I started trying to integrate the Teensy running my navball display, as a second slave on the I2C, but ran in to issues with it fairly quickly. Turns out the [URL="https://github.com/nox771/i2c_t3"]i2c_t3[/URL] library for Teensys does not support general call packets. Probably something I should have checked before trying it instead of blindly assuming it'd work, but still.

I think hacking the library to support general call shouldn't be much more than flipping the appropriate register during initialisation, but it's still a fairly intimidating proposition for me. So I may end up just updating my master to send packets to slaves individually. That seems gross and inefficient, but I should have enough spare CPU cycles on the master to get it done without any lag.[/QUOTE]

This is awesome! I've been interested in going to a similar level; but my understanding of communication via serial is still very basic. I'll be watching your progress *very closely* (or 'with great interest' as Palpatine would say :P )...

I love that virtual navball. The graphic reminds me of that old F-15 Falcon game (you know, the one they had for the 286? Or maybe I'm talking to the wrong crowd :rolleyes:
Keep up the amazing workd! :D

[stibbons]

Thanks.
 

Quote

This is awesome! I've been interested in going to a similar level; but my understanding of communication via serial is still very basic. I'll be watching your progress *very closely* (or 'with great interest' as Palpatine would say )...

I'm still feeling my way a lot with the I2C stuff as well. The system I have now has been working fairly well with an Arduino Mega and Leonardo talking for a while, but I'm confounded trying to add the third microcontroller. Current plan is to strip it right back and start from the basics. If I can get most basic hello world messages based between my teensy and another arduino first, then I can start scaling up the packet size and getting more complicated again. Slightly frustrating, but it's the best way to make sure I'm getting it right.
 

Quote

I love that virtual navball. The graphic reminds me of that old F-15 Falcon game (you know, the one they had for the 286? Or maybe I'm talking to the wrong crowd
Keep up the amazing workd!

I take no credit for the navball. The model and all of the initial work was done by others. Although, yeah, I agree that it's a great effect. I put a lot of effort last week in to making a higher-detail navball model, with a lot more faces in the bottom half. Looks a lot more realistic but it's a) slower and just didn't have the same charm. So I'm sticking with this one. Incidentally, if you'd told me two years ago when I started this project that I'd be learning Blender to finish it, I would have laughed at you.

I think I played F-15 Strike Eagle on my C64 at one point. Which didn't have an attitude indicator.

Edited November 30, 2015 by stibbons
fixing quotes

[stibbons]

The test rig I'd built for working with the navball controller wasn't really cutting it, and I didn't have a spare (functioning) Arduino Mega, so last night I ripped the brains out of my controller so I could test with the live microcontroller hardware. I'll also take the chance to redo some of the hasty wiring I carried off leading up to the maker faire. All of the wires soldered directly to boards will be replaced by decent Dupont connectors. Apart from those, I'm very happy with how easy it is to disassemble this stuff for maintenance.



From there I hooked up the I2C buses on the Arduino Mega and the Teensy and wrote a bunch of test scripts to ensure I2C worked properly. First running the stock Arduino Wire library on both ends, then switching to my custom Atmel TWI library on one end, finally with the Atmel library talking to the enhanced Teensy Wire library.

Once that was passing, I switched back to the KSPSerialIO plugin. I still wasn't getting any packets from it over the I2C bus, but only this morning thought to look in the KSP logs, and realised my extra code for the new vectors was throwing a boatload of exceptions. It took a couple of hours of tracing debug logs to figure out what I was doing dumb there and fix it.

From there it was a matter of updating my navball sketch to pick up and validate data from I2C and, almost accidentally, I had a functioning navball.

I've got most of the pieces already lined up to show orbital vectors, just need to integrate that code with my main branch. And then there's a lot of optimisation I want to do on this code. I want to convert all of the vector information KSPSerialIO sends to smaller fixed-point numbers before trying to get that code merged. Then in my rendering code I need to clear up the source of the weird vertical lines (which I think I can do with some better error handling in the vertex transformation). And then I need to look at adding buttons to switch the navball mode and finally start working on a new panel to house it all.

Edited November 30, 2015 by stibbons
Fixing images

[Sputnix]

[quote name='stibbons']... almost accidentally, I had a functioning navball.[/QUOTE]

I found this a few times with my build too :P

Seriously -- I am in awe of your skill and what you've accomplished. That looks so awesome! :) Great work!

On a practical note - do you think it will be as functional without the finer details we get on screen?
[Either way, it'd be pretty neat to have a display flashing that up! :D ]

[stibbons]

Quote

On a practical note - do you think it will be as functional without the finer details we get on screen?
[Either way, it'd be pretty neat to have a display flashing that up! ]

This is an excellent question that I still only have a vague, handwavey answer for.

All of the photos and video I've made so far are with the original navball model. I've got a branch where I've been slowly increasing the detail in that model - drawing segment lines at the 45 degree marks helped a lot to break it up in to small enough segments to eyeball current attitude. Then I'll think about doing something about adding initials for the cardinal directions, and possibly drawing different coloured lines so I can easily spot North. But I'm still tweaking the final look.
In addition, the navball markers are quite accurately positioned. I'm pretty sure I can get as close to a marker using this setup as I can with the on-screen ball.

What I am concerned about are lag and refresh rate. I'm getting updates from the game every 80ms, so 12.5fps. That looks quite jerky, and I'm thinking about trying to increase that up to 20fps or so. And even though I haven't experienced much delay with the original i2c setup, it's way too early to speculate if there'll be any extra lag from adding another controller to the mix.

Edited November 30, 2015 by stibbons

[stibbons]

Updated all the links in the first post. Ho hum.

Also just realised that a bunch of the bbcode needs fixing. More ho hum.

Edited November 30, 2015 by stibbons

[stibbons]

Over the last couple of weeks I've been working on a way to panel mount my LCD. Unlike everything else I've used in constructing this panel, it doesn't have any convenient mounting holes. I figured the best way to do it would be a couple of custom brackets behind holding it in place.

Started by learning how to use OpenSCAD to model the brackets. With the display datasheet in hand I was able to come up with something that would centre the screen, despite the slightly odd dimensions.

My 3D printer is... still in various pieces in the corner of my workbench, so I used one of the printers in my maker space to print my brackets in ABS plastic.

And then tested them for fit. The mounting holes came out a bit larger than I would have liked, so I might print these again. But the display sits very snugly in the brackets.

Once I had the brackets done, the rest was just designing and laser cutting a panel following my usual process. But, just to be on the safe side, I first cut a test piece out of some scrap bamboo ply to ensure I had my measurements right. This hole for the display is a bit bigger than it probably should be, so I'll do another test soon. But it was (mostly) a success!

I've ordered some small push buttons that will sit alongside the panel to select the navball mode (surface, orbit, target). I'll add mode labels to the left hand side of the display, and highlight the currently active mode. Not sure yet if I'll keep the two buttons on the other side, still need to think of something to do with them.

My controller is back in the shop. This week I'll hack a new hole to mount this in, then cut the final panel and attach it. The rest is (hopefully) just a little bit of software.

[stibbons]

Huh, weird. Looks like all of the bbcode in this thread was ported across except for the last half dozen or so posts. I've updated what I could, and will quietly go back to nerding around with microcontrollers.

[Freshmeat]

Neat going. I only wish that I had acces to 3d printing. For the extra holes, maybe a rotary switch for displaying something else on the display when you feel like (debug, coords, everything that you can think of)

[stibbons]

On 12/1/2015, 8:08:49, Freshmeat said:

For the extra holes, maybe a rotary switch for displaying something else on the display when you feel like (debug, coords, everything that you can think of)

Thanks.

I put two holes on the right there just because the buttons I bought came in a lot of five, and I figure I'll find a use for them at some point. I do, though, have a lovely five-position rotary switch salvaged from reclaimed medical equipment that wound up in my maker space. You can see it on the left in this old picture:

I already have a use for that in mind, but I suppose it could be integrated with the navball panel somehow. Hrmn.

I've been putting off finishing the hardware until those buttons arrived, but they've just come in today. The Christmas period is starting to get busy for me, though, so I have no idea if I'll be able to make much more progress on the assembly until the new year.

Still tinkering away with my software, too, but with nothing terribly interesting to show for it. I think I've written all the code required to render vector icons, but got distracted trying to convert it all to fixed-point numbers and haven't actually tested if it works yet. Um.