A Very Kerbal Kontroller

[PeteWasEre]

Hi All

Just wanted to share my progress on my custom controller. It all started when i found i had some useful HW laying around and found the wonderful KRPC mod by @djungelorm. Being and ex flight sim developer who is relegated to management these days I miss this stuff so I thought 'this will be easy and fun'! Turns out i was 50% right

In true Kerbal fashion it got out of hand quickly... I realised i had gone full Kerbal when i took the complete key binding list and tried to make a switch for everything..... Reality did dawn and a few got dropped, but not many!

At this point i have to say a massive thank you to @djungelorm for answering my many questions and actively taking on my requests for more features in KRPC.

So here she is  (p.s. can anyone tell me how to rotate images on imgur???):

 

Physical Layout:

 

The body is wood and designed to sit over the laptop with the screen still visible, and space on the right to still use the mouse. The panels are 4mm aluminium plate (yes, i know, but cheap trumps overkill) with stick on graphics and a clear stick on cover. Actually the 4mm was a pain as many switches wouldn't reach the depth and I had to machine out trenches in the back. I purposely am not going to describe my workshop practices as there may be children reading and blood was involved....

The light boxes on the side are hand made out of little bits of Perspex glued together with LED strips in the back... PITA x 10^343427436

The wiring did start to get a bit out of hand at the end, but given I was trying to use whatever I had its reasonable.

The space on the lower left is for a later Autopilot and perhaps KAS/KIS area... lets get this finished first!

Architecture:

The is an Arduino Mega in the back talking over USB serial to a Python program on the PC. As even a Mega doesnt have anywhere near the pinouts to do this there are also a bunch of MCP23017 extenders which proved to be so super easy to use. The Mega runs the side panel and the analogue inputs (joysticks and throttles) whilst the extenders run the main panel off. This approach really minimised the wiring to this panel. The lights are driven of ULN28003 arrays and also PWM dimmed. The fan is PWM speed controlled (at max freq to stop whine) off a temperature sensor near the Arduino.

(Originally it was mean to be an Arduino talking to a PI that ran a 10inch touch-screen taking to the PC. Then i dropped the touch-screen and moved to this approach which I think is a lot better anyway. Destruction leads to better design as Jeb likes to say!)

The code on the Arduino runs at a fixed 100Hz, and at the start of each frame checks for data from the Python module that drives the lights. If it receives data it will return data at the end of the frame, and if not it runs anyway but just doesn't send. This avoided a lot of timing issues and the need to synch the two programs. If the Python module pauses for some reason, the Arduino doesnt care.

Where am I at:

Most of the panel now works except the vessel and map focus switching, though there is a list of bugs to solve in the code and one nasty design oops in the HW that will require the extension board to come out and get modded with some diodes. I need to replace some of the rotary switches too as i mistakenly got 2x6 instead of 1x12. Also i cant yet control EVA Kerbals.

The arduino code is all done and just needs a final tidy. The Python code is still at 'just make it work' and needs a massive restructure and clean up. I will do this when I have the functionality sorted.

The last part will then be the graphic outputs. The idea is to use my two other monitors as info screens showing game data based on a mode selection on the panel. This is still in the conceptual design phase.

 

I have learnt a huge amount doing this and am happy to share my knowledge to anyone else who is crazy... err keen enough to take something like this on. I do plan at some point to document this all up too. Its very worth it, and after flying with sticks and switches i cannot go back!

Happy crashing!
Pete

 

[TotallyNotHuman]

*tips hat*

You, sir, are a genius. I haven't the foggiest idea how to assemble a controller, much less take the time to do exactly that. For this, I applaud you.

[Freshmeat]

I think this clearly shows the difference between someone who knows what he is doing and people like me. Mad props to you, may all your landings be fiery.

Out of curiosity, how do you produce the graphics on the panel. Procured from the web?

[PeteWasEre]

29 minutes ago, Freshmeat said:

Out of curiosity, how do you produce the graphics on the panel. Procured from the web?

@Freshmeat - thank you for the kind words! The graphics were painfully drawn in Open Office Draw and printed on self adhesive paper in a standard ink jet. This limited me to less that A4 so the main panel has some joins but they are not too visible.

Its then covered with self adhesive clear A4 sheets that i will use to print the light box labels onto. It prints nicely in an inkjet as long as you are careful to let it dry which takes a while. All this stuff came from Ebay.

I originally was going to use 2mm perspex to cover the graphics but the buttons were a PITA and then it started to crack so i binned it.

I wish i could have used Front Panel Express who have a free design program which i used for the initial layouts. You can then upload it to them and they will machine it out for you including infills, slots etc. The cost is not cheap (the program calculates it for you on the fly) but reasonable, but postage to Australia and our great Fx rate killed that idea fast.

[Freshmeat]

Thanks for the info. Actually, the plastic cover is what they used on several early soviet crafts, I  happened to see them at an exhibition this spring.

[Malekal237]

Pretty impressive, I wonder if you can share the code. I'm trying to make a controler too but i'm still new to Arduino and Python.

(sorry for my bad english)

[PeteWasEre]

On 28/07/2016 at 8:12 PM, Malekal237 said:

Pretty impressive, I wonder if you can share the code. I'm trying to make a controler too but i'm still new to Arduino and Python.

(sorry for my bad english)

Sure, would be happy too. I have no experience with GitHub though so give me a few days to figure it out as i have been meaning to set this up for a while. Will let you know when its done.

The python code I have is probably pretty bad, but it works. The C code for the Arduino should be better as C was always my favourite language!

 

[Malekal237]

Many thanks, I spent 2 days to figure out it work so your help will be appreciate.

[Andem]

Nice simpit!

[PeteWasEre]

@Malekal237 I have placed all my current code and documentation on Github here: Github Repo.

I plan to update this frequently as my system grows.

Hopefully it will work, I am a Git first timer. If it doesnt work let me know, and if something doesnt make sense I am happy to answer any questions!

Pete

 

[PeteWasEre]

Hi All

Status update time. All the functions of the controller have now been implemented and the HW oops's have been removed. The panel is essentially fully functional now. 'Controls Not In Agreement' logic has been implemented to prevent inadvertent switch errors on vessel change (what do you mean gear was up!?!?!?!) and it nicely uses the print on UI features of KRPC so it looks natural.

Vessel and focus switch turned out easier than i though thanks to the wonders of Python List comprehension! They are embarrassingly small lines of code now.  A lot of bugs got squashed in the process and now I am down to a lot of out there cases that are due to the nature of KSP. Like using LOX tanks with only Liquid fuel for an air breathing engine shouldn't give fuel warnings. The lego nature of KSP makes for a lot of variation! Still it has forced me to think a lot and some elegant solutions evolved!

A LOT of work then went into optimising the Python code. I moved the Python / Arduino relationship from serial to parallel but the real killer was the number of RPCs I would execute. However I just cannot express how awesome KRPC streams are. Set them up once and they pump data to you at no cost. So temperatures, resources, gear states etc are now all streams, and this made the output processing so fast (<1ms instead of 50-100ms) that paralleling the arduino was pointless. Python is waiting for the arduino now at that point.

Removing a lot of  dynamic building of lists for static items also helped, and when needed are refreshed on staging. A nice part of the streams is that they don't die if a part is lost so my crashing the ship doesn't crash the program. The python module now runs under 60ms mostly with the odd spike that i cant control. It's enough.

I also started the graphics side which runs as a separate process. After an epic and painful journey through all the python GUI addons that i couldn't get to work (i'm looking at you GTK and WxPython!) , I am back at good old TK. Its boring but it works. Basic functionality of message passing and data sharing is done, and I can show panel and game data on the screen,  so i can now proceed to build the rest.

And finally I have started documenting this by drawing up the schematics. They can be found in my github repo If they help anyone else then they have achieved their purpose.

My current todo list:

1. Finish the HW - graphic touch ups, labels for the indicator lights

2. Continue documentation

3. Continue Python graphics

4. Bug squashing

5. Keep working on the Atmospheric Autopilot module and panel design.

6. Figure out Github better so i dont track everything in Excel!

The main system element will get a boost again when the next release of KRPC comes out as it has a few fixes and features i need to continue.

Till next time, be good to your Kerbals.

Pete

 

[Malekal237]

Thanks for sharing your hard work. My prototype work with nanpy in the arduino, but I feel I can learn lot of things with your code.

[PeteWasEre]

Houston, we have progress!

Its amazing just how much time this takes. A few days surely and it would be done right? only out by a few orders of magnitude.... the problem is I think of new ideas faster than I think of solutions...

On the panel HW I tidied up the dimmer knob and the light boxes. Basically its done but I will wait to put the decals on the lights as I might change the function of some of them. However I have started cutting the Autopilot panel that you can see in the lower left of the panel image. The big rectangle is to hold the 40x2 LCD display that has also arrived (more on autopilot later) and works, proving very simple to hook up using the Arduino Liquid Crystal library. I now have to wait for the buttons to arrive as there are 21 buttons to go in to the lower area! I found some nice buttons with blue LED markings so it should look 'spacey'.

A lot of work has been going into the GUI SW. Getting the text going was easy enough, even the tabs with variable data like the rendezvous tab that can switch targets, or the systems tab that shows resource lists. Getting the plots going though was challenging! I started with the Launchplot based on some excellent work i found from Github user marioferpa and have since done a lot of tweaking. The orbit plots are all new work and the 3D view to get the angles right really stretched the mental muscles! They work mostly well, they don't like highly eccentric or hyperbolic orbits though, that will take more research. I made it so you can show either orbit plot, or both, so you can get a larger view and to ease load as rendering the #d plot is expensive. Need to optimise this part, with both plots is over 250ms, which with a 250ms frame rate is annoying.  With no plots its 35.

So i need to do some work on the remaining tabs, but areas like the resources and temps on the systems page, and the runway ILS data will need KRPC updates to finish. Also the GUI does not handle vessel switch or scene switch well, that needs some further investigation.

I also made it so the GUI can run without the panel,  so even when I am KSP'ing the old school keyboard way i still have my data

The autopilot concept is taking shape in my head. 3 axes; vertical, lateral and speed. I want to divide the LCD up into 3 areas and show the mode and set point for each axis. For example for vertical modes will be pitch, altitude hold, rate of climb, and for lateral mode heading, bank angle and if i can get waypoint info then that too! Speed mode is only hold, except i am thinking hover mode for landers too?

For each axis i will have 6 buttons: mode up/dn, setting up/dn, set and cancel. Then a master power, engage and cancel button. 

The beauty of this architecture is that i can just add one mode at a time as i figure it out.

Documentation is progressing. The Arduino code is fully documented now, but the python side will probably wait till i nail the architecture a bit more.

More than anything i need to actually PLAY KSP, rather than code, to find more bugs!

Cheers

Pete

 

 

 

Edited October 6, 2016 by PeteWasEre

[Wabbit]

This is awesome! I wish I had the patience to build something like this. Also, are the built-in controls as easy to use? Seems like spaced-out switches aren't as ideal as WASD, but I don't know.

 

[PeteWasEre]

@Wabbit  Thanks!

The controls take a bit of getting used too, but once you have the muscle memory and dont have to look for switches it feels the same or better. It feels more tactile than the keyboard. You do move more (which probably isnt a bad thing ) and while it wouldn't work for a fast paced game for KSP its fine.

Edited September 9, 2016 by PeteWasEre

[Freshmeat]

@Wabbit While it is cut off from the picture in the view, rotational and translational movement is done by two 7cm analog joysticks, allowing for fine control of the craft. The rest of the controls are somewhat faster than keyboard to use due to their spacing and grouping.

[Wabbit]

@PeteWasEre & @Freshmeat ah, thanks for clearing that up. Also, is that a dry-erase board for the action group center? That's awesome!

[PeteWasEre]

@Wabbit Yep, stick on dry erase. A roll of more than a meter cost a few bucks on ebay. Works a treat.

Oh and by far the nicest fine control is the throttle. Powered landings are soooooooo much easier now. I can hover at will.

Edited September 10, 2016 by PeteWasEre

[Freshmeat]

Definitely agree on the throttle. My first hardware project was a rotary potmeter in an Arduino, while I used keyboard for everything else.

[PeteWasEre]

That makes me wonder that it could be a nice intro tutorial for people who want to get into HW panels. I see a heap of comments on all our simpit threads about people who love the idea but dont know where to start. 

I am tempted to write something up, if there is interest I can then add more to it. Might have a crack this weekend if I have time.

[PeteWasEre]

I have an Autopilot Well I have a working panel at least, still working out how to drive KRPC autopilot but it does fly and follow commands.

The ghosting in the first pic of the LCD is me being too slow with the camera, its just about to change! (If you get the reference you are showing you are as old as me )

The panel was a lot of fun to make, and quite different from the others.

Physically I previously used panel mount HW everywhere but this time the switches were board mount so i had to make and mount boards to hold it all to the panel, and that meant more visible screws on the front but the black hex heads look ok so I don't mind. The only frustrators are that the graphic printed in a slightly lighter grey (printer settings i think??) and I couldn't get the power button cap in silver or the others in black. Minor annoyances to tease my OCD only.

The LCD was also a difference but so damn easy to integrate I am wondering why i never used them elsewhere. Just hook it up and go, though the Liquid Crystal Library is very slow and causes an overrun at each screen refresh which is only on user input, and at 40ms its still ok. With the blue LCD and the blue lit switches I think it looks quite nice! Balancing the LED levels was a bit fiddly though, and chewed up a lot of resistors. All the lights in the switches and the LCD itself are linked to the main dimmer knob so they dim really nicely with the rest of the panel. LCD contrast is a pot on the back though, i tried a LP filter approach but it didnt work so I went old style. It shouldn't need to change much, only drift with age.

The code is a bit more extensive than usual as i am handling all the switching on the Arduino end and only transmitting the final result to the Python code to avoid lots of data transfer. This was compounded by the 3 axis approach I am pushing for and that I want to be able to select the next setting whilst the first is held. This took me back to good old C Structs and lots of arrays but they worked really neatly.

So in the photo you will the Lateral axis is on and set. In the vertical axis I am preparing the next mode and I can change this as much as I want until I am happy then press 'Set' and it will lock in and look like the lateral mode, or cancel to go back to the current mode setting. Finally the speed setting shows you what happens when the axis is off. The master CANCEL will turn off all 3 modes for when it goes pear shaped....

Its built so that each axis can just add modes to a struct with their own min/max, multipliers (so I don't have to change altitude 1m at a time!) and with individual prefix and suffix for units. I can just add them whenever I like.

Transferring to python was fun as i had to split INTs into multiple bytes and then recombine, and the out of the box doesn't handle negatives well! A custom function fixed that and now it works nicely, and the focus is working with KRPC to understand how it tunes gains as my first trials oscillated... a LOT. It seems to not like fighters with massive control ranges.... shame I do.

Nice thing is though you can overwrite the AP with the stick still and then let go and it takes over. 

I am still working though the docs, the schematics are done but the design doc now needs updating.

The plan from here is:

1. Get way more AP modes, will need to work with the KRPC dev to get this going

2. Implement a queue for cautions and my new clear caution button (Cautions should flash at first till cancelled).

3. Keep working on the Python GUI especially for atmospheric flight and rovers.

4. MOAR DOCUMENTATION!

5. Migrate to 1.2 and all the joy that upcoming KRPC builds are promising

6. Play KSP!

Till next time!

Pete

 

 

Edited October 6, 2016 by PeteWasEre
Fix pics

[stibbons]

Surely you can't be serious!

That autopilot looks fantastic, great work. Would love to know more about your buttons, mostly because I struggled with my little illuminated PCB mount ones as well. What sort of buttons are they, and how did you make the caps? 

[tjsnh]

This is absolutely amazing.

I'd LOVE to have a control board like that. You should make these and ebay them!

[Freshmeat]

It seems as if you are going to have the most advanced control unit around here. I tried to construct an altitude autopilot myself, but cannot get rid of the oscillations.

[PeteWasEre]

20 hours ago, stibbons said:

Surely you can't be serious!

I am serious, and don't call me Shirley! ah that movie never gets old!

Thanks The buttons are right off eBay, caps and all. There are a bunch of vendors selling them, all in from China which means long delivery but you can't argue with the price at a buck each. The feel is nice but careful with solder temp as they are not super robust. The pin spacing is not quite 0.1" so it took some plier work to get them in, along with a good shove, then more fiddle to get them straight in the holes. There are heaps of styles of cap available (they just clip on) and colours also, and the LEDs are super bright. I had to add resistance to tone them down a few times. Here is a link to one -

http://www.ebay.com.au/itm/331584970800?_trksid=p2060353.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT

 

@tjsnhThanks for the praise! and if only it were that easy... there is probably $300 in parts in this now, and hundreds of hours. Without going to a production version its just not viable as it would need to be $1k to make it worthwhile. With mass buy of parts, proper PCBs with SMD parts the cost would come way down, but I don't have the skills to do that.

However the build is the most rewarding part. I think a lot more people can do this if they just have a go, and heaps of people on here will gladly help answer questions or provide guidance to get people started.

I will get to that intro tutorial for a basic HW throttle up as soon as RL stops getting in the way!

Once you have one control working the rest is cut, paste and adjust. The rest is a housing but it doesn't have to be fancy. One guy on here made one out of craft sticks, and I have made a guitar amp that's based on a cake tin before!

@Freshmeat I'm tryin'

Would be curious to know what approach you used. I spoke to the KRPC Dev and he has no plans for higher level modes, so I need my own PID to turn altitude hold into a pitch command to give to KRPC's autopilot. I suspect similar issues when I have one PID driving another, and my control theory classes are approaching 20 years ago!