Back in business (more or less)

[Freshmeat]

My Mark IIb control panel broke down in the spring due to a careless shortcut, and I have been building and redesigning this one on and off since then. I actually missed 1.5 completely, but finally the hardware is at an acceptable configuration.

So, after a few time consuming mistakes, I flew an initial test flight with my Flight Control Mk IIId, and was happy with the result. What started when I looked at the price of a joystick with throttle and thought I could make one cheaper did turn out to be a hobby consuming hundreds of euros and opening a whole new field of learning. When I started, I knew a bit of electrics, barely more than Ohms law and the underlying physics. I had written small pieces of software in a lot of languages, but never looked at the beast known as C.

The layout:

When I realized I needed to redo the panel, I gave some thought to what functionality I was using at the most, and what I needed to see while I still could see the navball. This meant that the two main LCD displays was kept center top, providing me with whatever information I need at the current stage in flight. Below that analogue gauges showing information I need to be aware of approximate magnitude of without having to read a number. A real time clock is also center, it starts blinking a 'b' once time reach past 10 pm for reasons that should be obvious.

The joysticks are placed at a distance that corresponds quite close to how far my hands are when I put them in front of me. I used to have them in the corners, but It turned out that I always was pulling a bit off axis as I had to reach to the side for them. Throttle is by the left hand, as I need attitude and throttle control in conjunction far more often than throttle ans translational control. Below the throttle is a momentary brake, and the big red stage button and its toggle.

Toggle switches right upper corner have their functionality lit up either red or green, and as they are rather big I can reach them with either hand. The keypad on right side, on the other hand, is so small I need to focus on it. Apart from time warp control, it is mostly used for tertiary functions, such as science gathering, switching navball mode when I want something else than the default, or cycle camera or craft focus.

Lower right corner is a number of rotary knobs. This is partially selectors for SAS mode, cam mode/map/IVA and control panel mode (rocket, aeroplane or rover), partially a set of trimmers for the attitude joystick and engine percentage. The LED display in that area show the value of a trimmer when said trimmer is adjusted. Finally, the big red abort button is well out of reach in case I should hit it accidentally, but easy to hit if I actually need it. As with the stage button, is has a toggle switch that physically disables the circuit when locked.

The hardware

For this panel I went with an Arduino Due. My previous build used a Mega, but I had instances of it not being fast enough when doing a bit of trigonometry and some square roots for my LCD displays. The Due runs at a native 3.3V, so I had to make a level shift protoboard for those units that run at 5V. The 5V are supplied by an old PC PSU, but given the low demands of the system I can keep said PSU off and just use the 5V 2A always on line. Still, nice to have all the power I can dream of within easy reach. Luckily, KSPSerialIO and Win10 talks just fine with this board, although I also have a CH340G USB to serial adapter connected to Serial1.

I finally caved in and bought a crimping tool and proper connectors for my wires instead of soldering bits of header to the wire, and ribbon cables for most of the long connections. The protoboards I use are laid out as breadboards, saving a lot of soldering as well, and the wires on the board are single core. These improvements in manufacturing have been costly, but well worth the investment. Loose wire strands generate a lot of noise, and I had to scrap two protoboards where I could not locate the culprit. I have in recent years started to suffer from farsightedness, a fact I found out by having more and more difficulty soldering said protoboards. When soldering these days I use a magnifying lamp my wife exchanged for a better one (she does needlework), and have a set of reading glasses to go with my contact lenses.

The annunciator and toggle status lights are all WS2812B LED strips, which saved me a ton of soldering. They are mounted on the button of 3d printed grids and shine through a layer of PVC slides with the actual print and food wrapping paper beneath to diffuse the light sufficiently.

All digital switches are connected to 74HC165 or CD4021 shift in registers, and the rotary selectors are connected to 74HC147 encoders, which in turn are connected to shift registers. The reason for using 74HCxxx IC's is that they run at the Dues native 3.3V, so I did not have to level shift the signal to 5V. That was not the case for the 7seg LED modules, that are bought as units with integrated MAX7219 IC's, or the 4x20 LCD displays and the DS3231 real time clock, both types are 5V I2C connected units.

The translational joystick is carried directly from my last control panel, and I am still very happy with it. It consists of a thumb joystick and a small piece of stick between two micro switches for three axis control, in a 3d printed casing. While I do use the twist of my attitude joystick for rotation, I would not like to depend on it for fine control or fast reaction.

I use a slide potentiometer for throttle. I spent a bit more to get a fader for a mixer instead of a standard pot, I wore my previous throttle out and had problems with unintended engine ignition.

The keypad is made from scratch with push buttons on a protoboard and another 3d printed grid to keep them aligned. There are still quite some empty positions on the keypad for when I get ideas to expand my functionality.

The software

On this panel, I have several functionalities that cannot be activated through KSPSerialIO, so I turned to kRPC. Unfortunately, while I could make a working Python client for kRPC and it even did some of the computational heavy lifting for the Arduino, I experienced considerable latency. This is surely partially due to my very imperfect implementation of the serial communications, but I knew that KSPSerialIO worked fast and out-of-the-box, once I added __attribute__((packed)) to the packets due to 32-bit architecture of the Due. So in the end I just decided to use both plugins, with kRPC handling complicated, non time dependent operations. First iteration had me send information to an Uno over I2C to send to kRPC, but in the end I connected a secondary serial port and cut the middle man.

The Interesting ability of kRPC is to access almost everything in the game. In every vessel I made, I assigned solar panels to action group 1, ladders to AG2, science to AG3, engine mode to AG10 and so on. With kRPC, I just ask nicely to open all solar panels, with the important qualifier that there is no docking port between them and the root part in the three hierarchy. This means that when I carry a station part in my spaceplane and extend the solar panels, the solar panels of the station part does not try to unfold inside the cargo bay. In a similar vein, I have toggles for radiators and cargo bays.

Science and repeatable science is on different push buttons, although I need to fiddle a bit with this part of the code: If I carry two goo containers, I only want one to open at a time.

The code looks for the smallest storage of electrical charge and ties it to a toggle as well. This means that if I forget to extend my solar panels and a probe goes dead, I have a reserve of power to reactivate it. Admit it, you have been there as well.

Communications between the kRPC client and the Due is still the biggest issue in the software. I sometimes get massive timeouts, and I still need to implement fast and reliable transfer from the client to the Due. kRPC can access information about misalignment between two vessels when docking, radio signal strenght, and the life support resources. I would like to have an alarm going of based on that information.

On the  KSPSerialIO side, there is lots of code reuse. I had made functions to deal with LED displays and the information on the LCDs is mostly carry over. Interesting notes are that I  calculate circularization dV during the orbital phase of ascent when in rocket mode, and the deviation from KSC runway in aeroplane mode. I also have distance, relative velocity and approximate expected time of arrival showing up during rendezvous.

Code to do

While the controller works, there is still lot to be done. I have a 7seg to spare that should show time to maneuver node or rendezvous, and most of the annunciator is not programmed yet. Also, It would be nice to be able to call kRPC autopilot sequences from my panel, I have several standard launchers that could benefit from automated launch. Also, a general clean up of things that work but need polish on the second LCD display, it is not fully utilized yet.

Source Code and thanks

I finally learned how to use GitHub, so my code is available there for both Arduino and kRPC client. I learned a lot from reading other peoples code on the web, and especially @PeteWasEre have good example of using kRPC. As always, @stibbons is a fountain of knowledge, as well as the kRPC discord. And everybody else in the KSPSerialIO thread.

[PeteWasEre]

Great work! You really went all out on the features! I especially love the battery well idea, pure genius, that's straight to the top of my to-do list...

I have given some thought to a Due upgrade too, a big reason i scrapped my autopilot panel was the lag on the mega or a comms mess to process on the PC. The level shift always put me off though as you miss one 5V and zap.... guess it just needs some care and patience! Might have to reconsider that too.

The python lag is a problem, and i don't see a way around it without changing to another client language, probably C# which i have 0 knowledge of. I did though spend a LOT of time bench marking parts of the code to find the delays and rewriting sections to improve performance. If you are self taught in python like I am then its amazingly easy to write effective but inefficient code!

I will have to take a look at your code as i have often wanted to have a 'fast' and 'slow' split so i can focus on time sensitive things like controls and camera. using KSPserialIO for the fast is a good idea to consider.

Love the shiny look! If you are planning to add labels near switches i have had great success on metal with rub on 'letraset' style lettering for my guitar amps. They are hard to find these days but with patience and a quick coat of spray clear gave a really nice look and worth a search.

Cant wait to see this evolve! And many thanks for the nod kind sir

 

[Freshmeat]

Thanks for the kind words. I have given much thought on how to letter the surface, but in the end I have settled on printing on overhead and gluing the print to the panel. I considered letraset, but given my motor skills I was afraid that I would mess up the spacing and alignment. If you look closely you can see lettering around the rotary selectors, but the problem is that I am restricted to dark colors. So I tried to ensure that as little lettering as possible was necessary in the build.

As for the code, feel free to ask questions, I am not exactly generous with comments nor consistent with variable names. Be aware that two plugins require an extra serial port, but I find it worth it.

[tsaven]

I'm sorry for bumping an old thread, but this thing is absolutely beautiful.  Would you be able to tell us where you got some of the parts?  Specifically, those analog gauges and the button matrix in the upper-left?