Flight Control, Mk II

[Freshmeat]

Here we go again.

I built a hardware controller for KSP a year ago using KSPserialIO by zitronen, and was pretty proud of it. However, it had several construction flaws, based on my complete lack of practical knowledge of electronics, and during autumn I started shopping for parts for a replacement.

I learned about shift registers and display drivers, and started to build a 7seg readout, but eventually abandoned the idea. I used shift registers to replace the internals of my first controller, but around Christmas it started to give out. I think I burned some pins through excessive drain, and connection became a matter of luck around the advent of 1.0. But then end of semester came pressing, and the project went on back burner until May.

Now, however, all exams are past, and I have used my spare time to plan, test concepts, and do the initial woodwork for a second generation flight control panel. Following features are planned.

Included features from the go:

 

• Separate unit housing dual joystick and two single direction joysticks, throttle and stage button. Included is a rotary knob to adjust strength of RCS as well as attitude. Stage comes with a lock and red/green status LEDs
• 144 x 80 7" monitor. Holds a max of 10 lines of text, possibility of simple graphics. This is going to replace the HUD1 unit from KER, a long standing ambition.
• Keypad to specify exactly what will be displayed on the monitor.
• Toggle control for action groups, SAS, RCR, light, gear, brakes. All toggles have a red/green single LED to indicate status at a glance.
• Lockable big abort button.
• Pushbuttons for map, camera, cycle active ship, time warp. These are done by wiring up a USB keyboard controller, as they cannot be controlled by KSPserialIO.
• Select rocket or atmospheric craft control scheme: This will switch roll and yaw controls, depending on whether I need to fly an airplane (roll on prim joystick), or a rocket (yaw on prim joystick). I might include a separate mode for rovers as well, but they handle pretty well in the rocket config already.
• Analog gauges for Charge/Current, Fuel, Monoprop and Radar Altitude (3/30 km, log scale)
• Warning LEDs for speed (slow/fast on descent and ascent), ressources, temp, connectivity. These will be done in red/green single LEDs.

 

Additionally, I have following ideas:

 

• Recalibrate joystick on the fly by keypad. (Hard as it does not scale linearly, but doable)
• Advanced input to the monitor: While I initially just aim for ten default display schemes, I want to customize the output on the fly, using some input scheme. This takes inspiration from the various DSKY projects out there.
• Rotary knob for selecting SAS control scheme. This hinges on zitronen including it in KSPserialIO
• Limited autopilot functions, most importantly an optimal descent assistant for vacuum environments. Ascent velocity assist for atmospheric takeoff is desirable, but until I get my hands on a proper drag coefficient calculator for my craft, it remains a wish. A way of calculating the correct orbit to hit a waypoint for a contract, taking into account the rotation of a given body.

 

All of these should provide plenty of time to waste on the project.

Shouts should go out to zitronen for making this possible, MrOnak, Mulbin, AmeliaEatYaheart, stibbons, T.A.P.O.R., Sputnix and everyone else who posted a question or an answer in the KSPserialIO thread, as well as the highly inspirational controllers you have shown to the rest of us.

Current status:

The flight control unit is done. It communicates with the main unit by an old SCART cable, with a few pins to spare. The big red button is staging, and just above it the lock in active position. After this picture was taken, I added a rotary potmeter to scale the input of the joysticks.

A view into the unit. You can see the primary and secondary joysticks, as well as the small board routing the input. Originally I wanted to use a VGA connector, but it turned out that I ran out of pins, and had to replace it. The joysticks are artifacts from an ancient age. A gameport joystick for attitude, and a C64 digital joystick for RCS.

The monitor. The main panel is build as a frame with bolted modules for easy service and replacement. The individual modules are painted black, and the frame the same grey as the controller. While a lot of modules around here are made of fine looking materials like printed dibond, 3d prints or aluminum, my budget says plywood. Labels will be paper prints in negative, with a bit of touch up around the corners once fitted.

The monitor itself has kept me occupied for the last couple of days. The TVout library is very processor intensive and interupts the timer of the Arduino, so I dont think it is going to play particularly nice with KSPserialIO. The solution I use is to use a spare Arduino Uno (clones come at less than €10) and transfer bytes over 8 pins from my Mega to the Uno. I cannot use SPI or I2C as a sane individual because TVout hogs the SPI pins and interrupts I2C, but after some fiddling and a full day of not being able to communicate with my family I got the results I wanted at some 20 FPS, enough for practical use.

Last unknown part is the keypad, but glancing at the documentation it does not seems so difficult. Then, it is just a matter of connecting the parts and writing the actual coding af the Arduinos, but that will not require anything but stuff I already have tried before by now.

Edited December 12, 2015 by Freshmeat
add tag

[Sputnix]

It's always awesome to see people take their ideas to a v2.0 level!

(I don't know if I'll have the energy / interest once I'm done )

RE: Display -- have you thought about using the Telemachus plugin?

(Depending on the data that you want displayed -- and I'm not entirely sure Telemachus would be useful).

Although, that requires a computer (unless you scored the 7" from an old eeePC, this brings you back to square one) :/

**

• Rotary knob for selecting SAS control scheme. This hinges on zitronen including it in KSPserialIO
  

Uh, what now?

What SAS control scheme(s) do you refer to here?

Edited June 25, 2015 by Sputnix

[Freshmeat]

Re: SAS

Back in March, zitronen speculated about adding the possibility of specifying what the different types of SAS, as in prograde, target etc: http://forum.kerbalspaceprogram.com/threads/66393-Hardware-Plugin-Arduino-based-physical-display-serial-port-io-tutorial-%2806-Jun%29?p=1712555&viewfull=1#post1712555

I do not know if anything came off it, but I have made room for it on the panel. It is one of the holes in the panel plate that holds my monitor in the picture. Yes, it makes no sense to have it there instead of the switch panel, but it is the only place I had room for it.

The monitor is a slave unit from a broken car DVD player, so I can only access it through composite signal. I have mounted it with its original print board and can see the original connectors, but I have no documentation and cannot find any on the web.

As for Telemachus, I use it on a spare tablet and my secondary PC monitor to display a map with position and a few graphs. It suffers from a slower update cycle, so I don't want to commit anything mission-critical to it. And while there is some really nice new front-ends for it, the original art style is rather far from my vision of Kerbal crafts.

[Sputnix]

Re: SAS

Back in March, zitronen speculated about adding the possibility of specifying what the different types of SAS, as in prograde, target etc: http://forum.kerbalspaceprogram.com/threads/66393-Hardware-Plugin-Arduino-based-physical-display-serial-port-io-tutorial-%2806-Jun%29?p=1712555&viewfull=1#post1712555

I do not know if anything came off it, but I have made room for it on the panel. It is one of the holes in the panel plate that holds my monitor in the picture. Yes, it makes no sense to have it there instead of the switch panel, but it is the only place I had room for it.

The monitor is a slave unit from a broken car DVD player, so I can only access it through composite signal. I have mounted it with its original print board and can see the original connectors, but I have no documentation and cannot find any on the web.

As for Telemachus, I use it on a spare tablet and my secondary PC monitor to display a map with position and a few graphs. It suffers from a slower update cycle, so I don't want to commit anything mission-critical to it. And while there is some really nice new front-ends for it, the original art style is rather far from my vision of Kerbal crafts.

RE: SAS --

Thanks for that. I must've missed that (but with 100 + pages, I was bound to miss a bit in there :\ ) was a great read though, and really kick-started my own project

RE: Telemachus --

I hadn't yet played with it, but had some ambitions to do a Mission control / space-craft type simulator using it.

For something like that, I suspect the delay is more true-to-life; I didn't realise there was such a delay - which, as you point out, is quite problematic.

Kudos on recycling old tech [i often like doing that - where I can; problem is you wind up having a whole lot of old tech lying around for extended periods of time with no practical use ]

[Freshmeat]

Quick update: I have started wiring the switch panel. It connects to a keyboard controller as well as the Arduino to emulate a few things you cannot do from KSPserialIO. End result is a 36 pin connection between the panel and the veroboard in the chassis, and by now I have done a handful. All other panels are assembled, but needs wiring. However, this is the big one, so it goes first.

[lawnmowerlatte]

a C64 digital joystick for RCS.

Hah, I knew I recognized that! Looking really good, can't wait to see more.

[ThereIs0nly0ne]

Quick update: I have started wiring the switch panel. It connects to a keyboard controller as well as the Arduino to emulate a few things you cannot do from KSPserialIO. End result is a 36 pin connection between the panel and the veroboard in the chassis, and by now I have done a handful. All other panels are assembled, but needs wiring. However, this is the big one, so it goes first.

This looks very cool. I'd love to see some more pictures of how you're putting all this together.

[Sputnix]

Quick update: I have started wiring the switch panel. It connects to a keyboard controller as well as the Arduino to emulate a few things you cannot do from KSPserialIO. End result is a 36 pin connection between the panel and the veroboard in the chassis, and by now I have done a handful. All other panels are assembled, but needs wiring. However, this is the big one, so it goes first.

w00t! I wish you luck!

Did you find a solution for the LCD screen in the end?

[Freshmeat]

As for the LCD, the current solution will make do fine. The main switch panel, however, takes forever to solder. It has 80 and some solder points (?), and 50 crimp connectors to mount. It is not that difficult, just time consuming. Right now half the connctors and a little more than a third of the soldering is done, and I hope to put some hours in the project again tomorrow.

[Sputnix]

Hang in there! It's tough work! I found its best to do small quantities at a time, otherwise you mess up, or get frustrated.

I'm keen to see how your V2 shapes up

[Freshmeat]

I got involved with a bit of LARP and had to learn to work cold iron and latex, so this has been on hiatus. But finally, I got around to assemble the parts this weekend to be able to fly again: I upgraded my control to Mk IIb:

It turned out that the serial port joystick I used for main flight stick was so worn that it did not return to zero on release, making it a pain to use. So I forked out for a three axis potentiometer joystick. This in turn meant that I could skip the digital joystick I used for RCS by using both axes of the thumb joystick in top, freeing some space for a cheap thumb trackball. The ultimate plan is to put away my mouse and keyboard while I am playing, and make do with my controller and a small wifi keyboard like this. I will need to replace the buttons on the trackball, though, they handle horribly.

Finally, I was able to add a selector for control schmes, switching the yaw and roll axes of the attitude stick when I fly planes instead of rockets. This has been a major stumbling block to aerospace for me, and one of the main motivations to start the Mk II controller.

The three axis joystick was an adventure in it self: When I ran diagnostics, readings where totally bonkers, and I thought I had made a  mistake somewhere on the stripboard. Desoldering, I started to test out everything. The z potmeter is not directly accessible from outside, there are just five wires: red, black, white, and two yellow for the button. So, +5 V, Ground and signal? Nope. Black is signal, white is ground.

Right now the thing flies beautifully, and RPM and KER HUD has been installed to handle my information needs. And after being grounded for several months I just want to go to space today.

The main unit hit a snag: Due to the rather large amount of switches (little short of 50), I multiplex the inputs in three groups. However, it suddenly occurred to me that currents run both ways in a wire , so I had to order a batch of rectifier diodes and insert them into the circuitry. That kind of set me back, but I have done panels for switches (main task), analog meters, TV display and keypad. SAS selector is halfway done, and warning lights is still just a box (but that only need LEDs and a header, so that is quick). then comes the task of wiring all the panels to a stripboard with shift-in and display driver IC's (CD 4021 and MAX7219) and wires between the Arduinos. Well, holiday is coming up.

[Freshmeat]

And another small, but rather significant update:

 

It may be hard to see, but the 7" LCD on the right now display flight information. Right now I have settled for following numbers:

• Altitude - the top of my monitor is pretty far away from everything else I look at during ascent.
• AP, PE, time to AP, time to PE - these should be self-explanatory
• Deviation N/S of runway in meters, and distance E/W to KSP runway in km - these are rather helpful during landing of an airplane, I can line up a plane long before I can see the runway itself. And given my rather abysmal atmospheric flight, every little bit helps.

The display is driven with the TVout library, and as anybody who has had it hands on it can tell it is a rather demanding piece of software. It uses interrupts that disturb the serial communication on the Arduino, so I have to use a separate unit for it (well, they come cheap off-brand). After some experimenting I found out that I2C was actually doable if the TV unit is set up as master, easing the entire process by many hours of head scratching (my custom 8 pin protocol was anything but fast).

However, for some reason the I2C always sends 32 bytes of information, nothing I did could make it send either more or less, so I had to make some choices. Right now I transmit 8 four byte variables from VData, being the above and vertical velocity. However, I plan to change the format so I send 7 variables and four bytes specifying what specific set of variables I send. Then I can execute a display scheme based on the packet id, having different packets for flight take-off and landing (including approach to different runways), rocket take-off, non-atmospheric landing (suicide burn guidance) and whatever else I think of.

A 4x20 char display arrived in the mail, and a couple of preassembled 7-seg LED displays should be on their way as well. I ordered them because it looked like I never would get the LCD going, and the price was reasonable. Now I wonder what information will be so important that it will get fixed display along with the fuel / batt / monoprop gauges.

As for doing the actual console I have a box primed and ready for grey paint, but I am starting to reconsider the layout of my controls. I changed my monitor and my computer table since I started, so it just might be feasible to cram everything into one unit instead of two. But with holidays just a week away I might have a chance of getting somewhere.

[stibbons]

3 hours ago, Freshmeat said:

However, for some reason the I2C always sends 32 bytes of information, nothing I did could make it send either more or less, so I had to make some choices.

That's one of the limitations that really frustrated me with the Wire library as well. You can change it by increasing the BUFFER_LENGTH define in Wire.h , but you'll probably soon run in to one of the other limitations that really frustrated me. Wire is synchronous - calls to send or receive data block until the operation is complete. Not such a big deal with 32 byte packets, but if you start sending 200 byte VData packets you'll probably run in to even more timing issues.

I ended up using Atmel's TWI reference libraries, modified just enough to work with Arduino. That lets me send the full KSPSerialIO VesselData packet across the bus, and it's fully interrupt-driven and asynchronous. On the downside, the library is lower-level, you'll have to do the work to prepare the packet yourself. And I have no idea if it plays well with TVOut. I'd be worried that two time-sensitive interrupt driven routines will result in too much stepping on toes.

If you're interested, have a look at my KerbalController code for an example of a master that sends VData. The library files are TWI_Master.[hc], and my code to send packets is all in twi.ino. For a slave that receives that packet, try the KerbalDisplay sketch. The library files are TWI_Slave.[hc], and my code that handles it all is in twi.ino.

Reading data from the slave to the master isn't that much more complicated, but you'll want to refer to Atmel application note AVR315 for the master, and AVR311 for the slave. On the master you'd just set the TWI_READ_BIT to true instead of false, and point TWI_Start_Transceiver_With_Data to an empty buffer. And on the slave you'd use TWI_Start_Transceiver_With_Data to pass in a data packet ready for the master to pick up.

[Freshmeat]

@stibbons I read very closely up on your code to figure out how to send and receive packets, learning a lot in the process. I have not used pointers in many years, but the concept turned out to be manageable on the level I need to understand, and I don't think I would have found memcpy on my own. I have no knowledge of coding apart from what I have picked up in various places, so anything intricate I need to learn from examples, and your code is a very good example for what I try to do a very small scale version of. 

As for using a different libary, I think that having a small packet with id is a better solution for my level of expertise. I _really_ don't want to place to high additional burden on the TVOut Arduino, and I have seen other references stating that I2C did not work properly with TVOut, so I count my blessings. The limited resolution only allows a few values to be on display at any time anyway, and further I must try to limit the scope of what I do codewise, if I am to hope that I get the controller to a proper playable state.

[Stoney3K]

If you want an easier solution for that LCD video screen, try to find an older model Raspberry Pi. They have a built-in composite output which just displays the Linux desktop.

[Freshmeat]

I did consider a solution like that, but two things kept me away:

1) Price tag. I get hit with import and sales taxes once the price exceed ~ €15, and that can almost double the price of a given product. An Arduino Uno sits at  ~ €5, while a Raspberry Pi would be something like €40 at the very least.

2) Lazyness. I have limited time for coding, and if I where to switch from Arduino to Raspberry, I would also have to switch from KSPserialIO to KRPC, and do all my coding from scratch. If I used the Pi as a graphics controller only, I would still have to deal with communication between the Pi and an Arduino.

[stibbons]

On 12/14/2015, 12:03:01, Freshmeat said:

I read very closely up on your code to figure out how to send and receive packets, learning a lot in the process.

Wow, that's a really nice compliment.  I'm glad you got something useful out of it. Feel free to hit me up if you have any questions.

And yeah, I see what you're saying with keeping your scope where it's at. Hope the rest of the build goes that well!

[Freshmeat]

Status update:

I decided to scrap the LCD in favor of the 4x20 display. TVOut updates rather slowly, so I had to limit the amount of information to much. After that, the rig ws servicable, although not satisfying:

Enter next generation:

 

The panels and protoboard where originally made for another case, but since they are modular it does not matter. By giving up the trackball I found room for two 2x40 displays and one 160x128 TFT. Power is supplied by an old PC PSU (thanks to @stibbons for that idea). The keypad is the remainder of an old phone, I hope to use it to activate some autopilot functions but that is far in the future. I can move my attitude joystick directly and hook it up, but after my high school bought a 3d printer I decided to print a combined setup. I also need to make wire for the panels apart from the main panel, but that still means most of the solderwork is done. A new conceptual addition is the momentary brake beside the throttle. As long as it is pressed throttle goes to zero and brakes get engaged. I found out I needed that after driving a quarter of the way around the Mun trying to do an Elcano (got derailed by 1.1 update, might return once the dust settles). Another addition is a real time clock circuit that will display an alarm when it is time to go to bed on workdays. For now, I hope a single Mega can power everything, else I will have to delegate displays to an Uno.

Right now end of semester is coming up, and I have a ton of work to do. Hopefully it will be better next month.

[Freshmeat]

No pictures today, but a small progress report: I have wired the gauges panel and built a small panel with switch for main power and a selector for rocket/aircraft/vehicle/debug configuration. The panel has leds for power and connectivity as well.

To do:

• Throttle panel + connector cable.
• Annunciator panel + connector cable.
• Translation panel + connector cable. Mostly popping the joystick into place and wire the connector for forward/back switches.
• Attitude cable. I can move the joystick panel directly from mk IIB
• II2C cable and connectors for two LCD panels and a real time clock.
• Keypad cable.
• SPI cable for my mini TFT display.
• PSU cable.
• Expand and rewrite my code significantly, but it can be done in steps.

My exams schedule is quite light this year, so I hope to make some progress over the next month or so. The cables, however is giving me grief, as I do not have ribbon cable. I braid some, and scavenge from old cabling I have around, making the entire setup rather ungainly.

[Gemini0915]

Looks like you are building a REAL thingy for the totally unnecessary VIRTUAL live too  ... iLike :thumbsup:

 

I'm wondering, are you doing this with an UNO or a MEGA ¿?

[Freshmeat]

@Gemini0915

I do this on a Mega, but that is primarily due to memory size. My first controller ran fine on an Uno, but I used most of the memory. Also, with the memory of a Mega, I could increase the buffer size to 256 bytes, enough to hold a full serialpacket in one go. This solved some connectivity problems I had.

Nothing much have happened since last post. Preparations for exams all over the place, it is as much work for the teachers as the students. I have gotten the I2C cable and wired two displays to my current setup, only to realize the code I had was hardwired to one display. So I set out to write a conversion instead of passing the numbers directly to display one, as I wrote about in your thread. The result is not comparable to @stibbons library by far, but it was nice to do things properly, understanding why it did what it did. I don't remember the last time I actually took time to plan out a piece of code beforehand, but I was stuck in a train traveling for several hours Sunday. The actual code is below, in spoilers:

Spoiler

void f2str(float fval, int BC, char *out){
  
  /*
  
  This function converts the float in fval to a string
  in out, containing a rounded result to BC significant
  digits, and an SI-prefix to account for large nnumbers.
  The function will not work generally with negative numbers,
  nor positive values < 1
  
  fval: value to convert to string, using prefixes
  BC: significant digits
  out: char array. Size at least BC+3
  
  out will have BC+2 printing chars and a null char.
  */
  unsigned long pbase=1UL; //Will be 10^(BC+1), float must have a smalle value than this 
                           // once we have found our prefix. Convert to float if 10^12 values are needed
  byte deca=; // index variable for prefix
  byte deci; // number of decimals
  char prefix[] = {' ', 'k','M','G','T'};
  
  if (BC < 1) out = "error: BC < 1";
  
  for (int i = ; i < BC; i++){ //pbase = 10^number significant digits
    pbase = pbase*10;
  }
  
  
  if (fval < ) {
    
    if (BC < 2) {
      out[] = 'e';
      for (int i = 1; i < BC+2; i++){
        out[i] = ' ';        
      }
    }
    else{
      out[] = 'e';
      out[1] = 's';
      out[2] = 'c';
      for (int i = 3; i < BC+2; i++){
        out[i]=' ';
      }
    }
    
    out[BC+2] = '\0';
  }
  else {
    while (fval >= pbase){
      fval = fval*0.001;
      deca++;
    }
    
    if (fval > pbase*0.1) deci = ;
    else if (fval > pbase*0.01) deci = 1;
    else if (fval > pbase*0.001) deci = 2;
    else deci = 3;
    
    if (deci == 2) BC++;
    
    dtostrf(fval,BC+1,deci,out);
    out[BC+1] = ' ';
    out[BC+2] = prefix[deca];
    out[BC+3] = '\0';

    
  }
}

 

Beware that the code is aimed specifically at the numbers I need. If it encounters a negative value, it will assume it reads an AP/PE altitude and thus the vessel is on an escape trajectory. It does not handle positive values smaller than 1 well, no prefixes below 10^0.

 

I tried to hook up my tft display. It is a strange beast, in that the logic gates must be at 3.3 V, even if supply jumper is set to 5V. And no matter what I did, I could not convince the card reader to detect a SD card. So I wonder how I am going to show deviation from prograde in an easy to interpret for a human and fast to draw for a controller manner. We'll see how it unfolds.

Edited May 30, 2016 by Freshmeat
Missing translation to english in code comment

[Gemini0915]

Same here, lack of memory. And with a MEGA you can get rid of a lot of IO multiplexers. To pull out the max, i had connected a 5" TFT ... every pin of the MEGA was used. But that failed, using the UTFT library increased a standard process loop from some 100us to 15ms , resulting a blood pressure increasing state due to instability of the whole mess. I will solve that by using a second (or 3rd) uC board.

 

On 30.5.2016 at 10:37 PM, Freshmeat said:

I have gotten the I2C cable and wired two displays to my current setup, only to realize the code I had was hardwired to one display.

I hit that trap too, seems you are using the same I2C backpack .... 0x27 xxD ... but this can be solved by small multiplexer circuit like the good old 4051 or some AND gates distributing the I2C data/clk to several character displays

 

[Freshmeat]

No, the backpack had jumpers for different addresses, so five minutes and a soldering iron took care of that. The problem was that I had made a print function that took a float and coordinates, then printed the formatted float in several substrings via lcd.print() and lcd.cursor(). Which of course always print to the same lcd screen.

Your findings with the TFT screen gives me a bad feeling about the one I want to hook up. I have a spare Uno lying around, if the thing turns out to be too slow, I will probably use it as a graphics coprocessor.

[Gemini0915]

8 hours ago, Freshmeat said:

Your findings with the TFT screen gives me a bad feeling about the one I want to hook up. I have a spare Uno lying around, if the thing turns out to be too slow, I will probably use it as a graphics coprocessor.

I have to say i'm not an coding expert. I learned assembler with a Z80 30 years ago and some BASIC programming on a 6510 machine (C64), but since then i was just busy with electronics engineering, code was always done by others. So, could be that my KSPctrl code is messy and is slowing down the 8bit calculator. Just give it a try, could be that you succeed, but it could be that you fail. You loose nothing (just some time), but you gain experience

 

8 hours ago, Freshmeat said:

The problem was that I had made a print function that took a float and coordinates, then printed the formatted float in several substrings via lcd.print() and lcd.cursor(). Which of course always print to the same lcd screen.

Did you not build an instance for each display ¿?

[Freshmeat]

IT'S ALIVE

It has been a quite busy month, but I assembled my controller first time about two weeks ago. Most systems worked, but I had several bad connections. So back to the garage for disassembly and methodical repair and testing; and this afternoon I was able to screw all panels in place and go to the software phase. Already, the test program provides me with routines for getting input, so I can integrate these into my previous software and expand from there. Still, a connector on the status leds for my toggles is temperamental, and the mount for one of the 4x20 LCD is hanging, but I figure I can resume playing within the week on a skeleton functionality. For now, I think I'll just celebratejust shy of a year of building finally paid off.