AmeliaEatyaheart

I'm using a stack of 4x7-segment LEDs connected to a custom board, driven by a multiplexed display driver. I tried the 8 digit 7 segment displays off ebay but they EAT power like it's going out of fashion. :'( I've built a multiplexed LED driver before, with good results The circuit I've cooked up for the KSP panel is extremely similar, just lighting up 8 LED's (one memory byte) at a time, and using persistence of vision to run a huge bunch of them. It runs off about 300mA, and would not really change if it was running a small number of LEDs or a full set of 128 columns. Should be able to run 128 chars of 7-seg's worth quite nicely

Mini update: Been working on the PCBs of late, so I thought I'd show em off the flight readout will have a stupid amount of 7 segment displays, a small graphic LED which I hope to use to show a navball, or a simple orbital map, and a character LCD for any extra info that doesn't fit on the 7-seg's such as current SOI, Terminal velocity indicator, various alarm statuses... And the reason it's taking so long to get made There's a few different projects on that panel, the two bigger boards to the upper right and the small shield lower right are for the mass 7-segment display (6 rows by 8 digits, plus indicator LEDs) The driver board will run two of those with a bit of greenwiring It's an expensive project, and it won't get done before the end of the summer break (southern hemisphere, so... end of jan maybe?) so I thought I'd make a post and show that this project may be running on slow, but not forgotten

You have totally out-done yourself; that is amazing! I can't wait to see it when it's ready! Do you have a thread for your panel as well? If not, you should make one

Hmm! Maybe I'll have to modify the fuel gauge to do both after all! MrOnak, ty! I do need to learn more about some (i.e. A LOT) of the internal Arduino library functions - it's not uncommon for me to write a function and find out later that there's an inbuilt version of the same thing.

My sin is this in reverse... Dilwise got stuck in the orbiting lab, instead of the lander craft (which had a backup probe controller), which meant that once the initial science on Mün was completed, I couldn't grab it and stow it in the capsule. I could have called it a mission success at that point, but I wanted more science! So Dilwise Base-jumped from Münar orbit. In all fairness, the impact wasn't THAT hard (only 30-40m/s), and he 'landed' about 1.2km from the craft, which was not bad for manual aiming with a jetpack. How he survived I will never know. Good thing I brought a rover to pick him up and save the walk!

The default packet delay is 80ms, which seems fine for most things. I'm not even running any switch debouncing code with a delay like that, and not had any problems. tell me about it Had a few FP projects with borked maths. I've given up testing for x==0 now, just test for x<0.001 or something like that My SOI code would break if the planetary parameter for mass (GM) changed, or had two bodies with the same GM value. Otherwise, it looks up craft orbital velocity, semi-major axis, apoapsis, and periapsis from the KSPplugin

There are several ways to ration out how often the function is called; the code block I wrote will only call ResolveSOI() when it has changed enough to warrant a re-calc (eccentricity changes from hyperbolic to elliptical, visa-versa, makes a sudden jump, or is unknown). But it's not a really intense subroutine either. So far I have not had any false reportings of SOI with this code block, so do feel free to use it I'd honestly be shocked if it slowed the mega2560 down, even if it was called every loop. It's a floating point function, sure, but... it's not super-complicated I'll have to have a look at github, to be honest this is the first Arduino code I felt was of value to share, so haven't really thought of all that stuff - I consider it released on a 'have fun with it, no restrictions, just give me name credit' type basis

I was trying to goad stibbons into unleashing their evil genius, but /gasps WHY DID I NOT THINK OF DOING THIS BEFORE!!!!!!!!!!!!!!!!!!!!!!!!!! THAT'S THE ONE THING I WANT TO ADD TO MY PANEL THAT'S NOT ALREADY THERE!!!!!!!!!!!!!!!! Duh Amelia, calculate it yourself, the info's all there! p.s. already did the same thing for calculating which body you're orbiting, gonna re-post it so someone can 'borrow' it if they like http://forum.kerbalspaceprogram.com/threads/100977-Hardware-Custom-KSP-flight-panel-with-flight-computer?p=1561721&viewfull=1#post1561721

I wrote some Arduino code to calculate what SOI you fall under - I'm pretty sure it will fail if eccentricity is EXACTLY 1.00000000 (overflow error possibly?), but for any other orbit (elliptical, circular, hyperbolic) this will calculate what you're falling around #define NoSOI -1 #define KerbolSOI 0 #define KerbinSOI 1 #define MunSOI 2 #define MinmusSOI 3 #define MohoSOI 4 #define EveSOI 5 #define DunaSOI 6 #define IkeSOI 7 #define JoolSOI 8 #define LaytheSOI 9 #define VallSOI 10 #define BopSOI 11 #define TyloSOI 12 #define GillySOI 13 #define PolSOI 14 #define DresSOI 15 #define EElooSOI 16 //same codes as in a savefile double Oldecc=-1;//keep value of orbital eccentricity for comparison next loop int currentSOI=-1; void UpdateDisplayOnNewPacket() { if (Oldecc==-1 || currentSOI==-1) currentSOI=resolveSOI();//force refresh if SOI unknown. else if (Oldecc<=1 && VData.e>1) currentSOI=resolveSOI();//force refresh of SOI if orbit jumps to hyperbolic (e.g. entering a smaller SOI) else if (Oldecc>=1 && VData.e<1) currentSOI=resolveSOI();//e.g. jumping to solar from planetary else if ( (VData.e>(Oldecc*1.05) ) || (VData.e<(Oldecc*0.95) ) ) currentSOI=resolveSOI(); //force refresh if the eccentricity 'jumps'; indicates an SOI change without a hyperbolic orbit (e.g. Laythe horseshoe orbit) //'resolveSOI' could be run every loop, but conditional states used to save some processor time. //add more display update code here ... Oldecc=VData.e; //preserve data for next run through loop } //--------// double resolveSOI() { //will attempt to find mu, and from that, figure out which world we're orbiting. //eqn: mu=v^2 / ( (2/OrbRad)-(1/SMA) ) for e<>1. //eqn: mu=(V^2 * OrbRad)/2 for e==1 aka parabolic orbit. //all distances in this function are expressed in km, not m, hence a lot of n/1000. //references- http://en.wikipedia.org/wiki/Hyperbolic_trajectory#Velocity //http://en.wikipedia.org/wiki/Orbital_mechanics#Formulae_for_free_orbits double SemiMajorKm=VData.SemiMajorAxis/1000; double mu=0; double _BodyRadius=0; if (VData.e>1 && SemiMajorKm>0) SemiMajorKm=-SemiMajorKm;//SMA must be a negative figure for e>1. //this is a catch-all - hyper orbits in KSP always have a -ive SMA. _BodyRadius=((SemiMajorKm*2)-(VData.AP/1000)-(VData.PE/1000))/2; double vsquared=(VData.VOrbit/1000)*(VData.VOrbit/1000); if (VData.e!=1) mu=(vsquared)/( (2/(VData.Alt/1000 + _BodyRadius))-(1/SemiMajorKm) ); else mu=(vsquared)*(2/(VData.Alt/1000 + _BodyRadius))/2; //value will be comparable to wiki mu values, divide 10^10 (conversion factor of m^3 -> km^3 if (mu<=0) return -1;//calculation error if ( (3531.6*0.95)<mu && mu<(3531.6*1.05) ) return KerbinSOI; else if ( (65.138398*0.95)<mu && mu<(65.138398*1.05) ) return MunSOI; else if ( (1.7658*0.95)<mu && mu<(1.7658*1.05) ) return MinmusSOI; else if ( (168.60938*0.95)<mu && mu<(168.60938*1.05) ) return MohoSOI; else if ( (8171.7302*0.95)<mu && mu<(8171.7302*1.05) ) return EveSOI; else if ( (301.36321*0.95)<mu && mu<(301.36321*1.05) ) return DunaSOI; else if ( (18.568369*0.95)<mu && mu<(18.568369*1.05) ) return IkeSOI; else if ( (282528*0.95)<mu && mu<(282528*1.05) ) return JoolSOI; else if ( (1962*0.95)<mu && mu<(1962*1.05) ) return LaytheSOI; else if ( (207.48150*0.95)<mu && mu<(207.48150*1.05) ) return VallSOI; else if ( (2.4868349*0.95)<mu && mu<(2.4868349*1.05) ) return BopSOI; else if ( (2825.2800*0.95)<mu && mu<(2825.2800*1.05) ) return TyloSOI; else if ( (0.0082894498*0.95)<mu && mu<(0.0082894498*1.05) ) return GillySOI; else if ( (0.72170208*0.95)<mu && mu<(0.72170208*1.05) ) return PolSOI; else if ( (21.484489*0.95)<mu && mu<(21.484489*1.05) ) return DresSOI; else if ( (74.410815*0.95)<mu && mu<(74.410815*1.05) ) return EElooSOI; else if ( (1172332800*0.95)<mu && mu<(1172332800*1.05) ) return KerbolSOI; return mu; //catch-all line - unknown value, returning calc result for analysis. } If I update it, it'll get reposted here. But I'm pretty happy with it, and it's worked cleanly so far Edit: This function actually calculates the gravitational constant * planet mass (µ, or GM) for a given body, so who knows, this might be useful for other orbital calculations as well More edit: Also calculates things like distance to CENTRE of planetary body, which comes up a lot in equations as well.

Done I had to cut out mod parts (I use a LOT of mod parts), but should work as expected (i.e. not work ) As I said, the flight parameters sent to the panel definitely appear to be attached to current vessel, it appears to be just the controls going back into KSP Thankyou!!!!!

At first I thought it was just one ship, but it seems to be any ship that has multiple controllable stages (I use command probe parts a lot). As far as I can work out, the flight readouts switch to the new vessel when KSP switches vessel, but the analogue controls stay with the 'main' ship, even if the camera is following another ship. Also: While the ship is running off the analogue controls, the keyboard controls (WASDQE, IJKLHN, shift/ctrl throttle) will not respond - I vaguely remember that from the notes, but when I switch vessel and the analogue controls are still focussed on the old ship, the keyboard controls become live again for the newly focussed ship. Not sure if that helps you hunt down the gremlin, but hope the info helps

Oh, I never said autopilot was't legit, just that I didn't want flight to be controlled. Also, you do realise that the navball values as well as G-forces (or, as MrOnak suggests, fuel consumption) are sent through the plugin? Tell me, how do you calculate a flight / gravity turn as a function of speed and altitude?? /giggles

The hamster wheel might go faster if you get one of those goo pod creatures...

Having a problem with the plugin atm, wondering if I can get a bit of advice... So, I launch a ship, with a probe stuck on the top, and when the probe seperates, the game focus stays on the previous stage. When I switch vessels, the plugin analogue controls will not respond, or will still drive the other ship! The selected craft will run, but only on standard keyboard controls. Once the ships are seperated by over 2.5km, I can switch ships in mapview and the analogue controls are restored, but it's a bit disconcerting! Obviously my staging sometimes leaves something to be desired, but... what's going on with the plugin controls? O_o (Very confused!)

I LOVE THAT SLIDER POT O_O <3 Also, mad props for the big red button!

Looks good! ...what is this 'enough' I/O you discuss? Sounds like dark magicks to me. If you decide to stop swearing that you need more inputs, Have a look at the mcp23017 I2C extender, that's how I got all the switches and LEDs on my panel working

I have one thing to say... hehehehehehehehehehehehehehehehehehehehehehehehehe... You're gonna have a LOOOOOOOOOOOOOTA fun with all those switches <3 Big phat toggles, missile switches and big red buttons is what makes a simpit fun <3 Suggestion: If you get serious about readouts as well, invest in a 20x4 character LCD. The library to use them is included in the Arduino IDE, and there's heaps of tutorials out there to help you make em work Also, OP: You asked me about buttons in another thread, check your PM

Thanks guys! I plan to update this thread sporadically as updates happen - while I'm more keen to make the readouts happen, I haven't been able to get the circuit boards made yet, so I've concentrated on getting the switch panel finished I added some flickering lights code to the switch panel, so if the ElectricCharge drops to less than 5 units, the lights start flightering, if the power drops to 0, most of the buttons will just flat-out stop working

Feel free to borrow as you please; it's great to be able to borrow and share ideas, it's how we all learn from eachother I had not considered messing with the RCS light when out of monoprop, that's an excellent idea! i might add my flickering light code but get it to read monoprop instead of electric charge... As for the staging light, it will only light up if the stage lock safety switch is armed - I wanted it to retain that feel of being under manual control at all times. It's one of the few buttons that still work if the 'ship' runs out of power as well I may add a red LED for zero stage fuel remaining, but that won't work for asparagus type staging. (Though in all honesty... I did briefly consider auto-staging once the stage is out of fuel, but then I felt like it'd be like flying an autopilot)

Honestly, what sort of switch will depend more on what software is sitting in between your switch panel and the computer interface for KSP. ST or DT is not a huge issue, I usually get DT switches just in case I want to modify my wiring later, but the important bit is whether they are latching or momentary. If you're using zitronen's code / arduino, and just modifying the code that he wrote, I'd recommend latching switches for RCS and SAS; same for most control groups if you use those as well if you're proficient with code, but hardware is new, momentary switches can be more versatile though. Just remember, wire switches between Ground (-0V) and the desired input pin, and you code will be testing for input low, not high. Example: #define SASpin 4 void setup() { pinMode(SASpin, INPUT_PULLUP);//if no actual button connected, then staging will not misfire. //... more code } //output tests: if (digitalRead(SASpin)==LOW) //inputs are active low MainControls(SAS, HIGH); else MainControls(SAS, LOW); //...more code Hope that gives you an idea of how to make the things work

Hey everyone! I'm still new to the forums, but been playing KSP for a while now. As a space nerd and electronics nerd, I wanted to combine my two interests, and deign a flight computer, partly to clear the screen from display mods. They work great, but take up precious screen space! however, I know sweet stuff-all about how to write mods for the game. Thankfully, there are people out there with more/greater talents, and someone had already written a plugin to add external hardware - and they wrote it for Arduino! That suited me rather well, as I've made a few Arduino projects in the past So, without much further ado, the flight panel to date! Current flight / orbital parameters output, and proposed 7 segment board - I need to re-do that though, as those modules EAT power... Cardboardian template for the control panel Fuel gauges - won't help for ion drives, but is otherwise helpful and fun - especially when firing those lovely 3.75m engines! The cardboardian front panel got upgraded to "let's add some not-quite-dodgy wiring and see if it works"... I'd like to believe Jeb would approve of the bare wire and spit-polish approach And just this week, recieved a bunch of those playstation-type thumbsticks for flight control! I was hoping to get an old-skool gamepad joystick working, but the springs are broke, and I kept spinning out of control. I was planning on treating this primarily as a flight readout panel, but after going through zitronen's code and realising how much spaceship controls I could add, it was too much to resist! So now I have to get/make a nice case for it all ----- Also, many thanks to both zitronen for writing this awesome plugin, and Mulbin for collecting a bunch of other hardware projects that other awesome people have made, that helped to inspire me http://forum.kerbalspaceprogram.com/threads/66393-Hardware-Plugin-Arduino-based-physical-display-serial-port-io-tutorial-%2808-Oct%29 http://forum.kerbalspaceprogram.com/threads/66763-Custom-hardware-simpit-repository-For-people-who-take-KSP-a-little-too-far

Thankyou very much, I'm rather flattered you like my work that much! Again, thanks to zitronen for making this plugin - my panel would have only been a rough idea at best without that magic! Some of my hardware is abismally simple - the 5V voltmeters I run are all driven direct from the Arduino's PWM lines, I didn't even bother with any filtering! They do 'jump' between PWM steps though, so filtering would likely help with that. I have to admit, I do like mine looking a bit dodgy like that though If you are going to build some filetering, keep in mind these voltmeters are usually just ammeters with an inbuilt resistor, so if you add another resistor you won't get full voltage swing. Play around with your multimeter and some caps and see what happens Those rectangular push-buttons - honestly... ebay, ebay, ebay. The trick is bargain hunting, and don't be afraid to mess with the hardware. Those buttons - some of them were 12V, 24V, and 220V, go figure! I got all momentary buttons, ripped the LEDs out, rewired them without the inbuilt resistors, then added external resistors so that I can adjust the brightness on my I2C board Any push-on-push-off action is purely done in code; I wanted all the buttons to be fixable if I wanted to change the action As far as the curved inlays on the panels go - I'm assuming you mean the rescaled meters? I scanned in one of the original plates into my CAD program, and from that image, re-drew it from scratch - never mix old and new imagery unless you're that good. And yea, Adafruit is an awesome resource for hobby / arduino gear - most of my parts either came from there or ebay Edit: Decided to take up your suggestion and start my own hardware thread: http://forum.kerbalspaceprogram.com/threads/100977-Hardware-Custom-KSP-flight-panel-with-flight-computer

Thankyou! Yep, mass-wiring's a pain. I used a lot of pre-fabbed wires with female single headers, and just cut one end off. My main ground bus is uninsulated tinned copper, because it was just easier to solder up. Plus, it makes it look dodgy as I do a bit at a time, make that bit work, and that motivated me to do more wiring I gotta get some PCBs made up for the mass 7-segment board though, and that takes time (to get it right) and money. I do not expect to get my panel complete fast, but once it's done, it'll look amazing Plus I plan on making a clone of my panel for a close friend, so PCBs make it nice looking and less work - the perfect combination!

By the way MrOnak, I love that circuit board you cooked up, you're a lot more patient than I am! May I assume all those numbered caps are for button de-bouncing?

I've also been working on a panel, based (heavily) on zitronen's plugin The control panel will also flicker and (mostly) die if ElectricCharge runs dry... Eventually I will mount everything in a proper case; until then it's all genuine cardboardian alloy