Darkblade48

Plugin link does not seem to work Edit: Seems to be working now

If you click the link, it takes you to a Github page with both the low resolution and high resolution zip files.

The plugin goes into the GameData folder, similar to other mods. For the Arduino code, if you open KSPIODemo10.ino (and you are using the Arduino IDE), you should see other "tabs" that contain the other ino files. When you compile and upload to the Arduino, they are all uploaded.

Oh of course! I don't know why I was making it so complicated by defining out all the cases I didn't want the rocket to stage and then just putting the one case as part of the 'else' statement. Edit: Quick question regarding pin assignment; since the Arduino uses TX and RX to communicate, I assume that we cannot assign these pins (pins 0 and 1 on an Uno) for use?

Just a quick coding question (to see if I am making this overly complicated). I have two switches (STAGELOCK and STAGE) as well as an LED. The behaviour I want is as follows: When STAGELOCK is toggled, turn on LED. When STAGELOCK is toggled and STAGE is triggered, launch the rocket. Both STAGELOCK and STAGE are using internal pull-up resistors, so this means they normally read HIGH. I have the following code for the first part. if (digitalRead(STAGELOCKPIN)) //pull-up resistor is used so this pin is normally high digitalWrite(GLED, LOW); else digitalWrite(GLED, HIGH); //once key lock is toggled, turn on LED For the second part, I am not sure if it is necessary to define all the cases. There are 4 cases and my desired actions: 1) STAGELOCKPIN is high (due to pull-up resistor), STAGEPIN is high = rocket does not launch 2) STAGELOCKPIN is low (toggled), STAGEPIN is high = rocket does not launch, but LED is turned on (taken care of above) 3) STAGELOCKPIN is high, STAGEPIN is low (this is the case where you try to press the launch button without disarming the safety) = rocket does not launch 4) Both STAGELOCKPIN and STAGEPIN are low (both switches toggled) = rocket launches I have the first 3 cases coded as follows, but I am not sure if it is necessary to explicitly stage cases 2 and 3 (also, the fact I am inverting the boolean logic is quite messy). I am unsure what would happen if I do not define case 2 and 3. // HIGH && HIGH || HIGH && LOW || LOW && HIGH if ((digitalRead(STAGELOCKPIN) && digitalRead(STAGEPIN)) || (digitalRead(STAGELOCKPIN) && !digitalRead(STAGEPIN)) || (!digitalRead(STAGELOCKPIN) && digitalRead(STAGEPIN)))　 MainControls(STAGE, LOW); else MainControls(STAGE, HIGH); //LOW && LOW

Excellent; now to figure out how to connect it up and get it to work in KSPIO

Thanks for the information; the Bounce2 library was helpful. I managed to integrate it with the KSPIO code, but I am not sure if I have done it correctly (there's no error, and the controller still seems to work). Briefly, in KSPIO.ino, I have Bounce debouncer = Bounce(); prior to the void Setup() and then have debouncer.update(); int value = debouncer.read(); in void loop (). In output.ino, I have debouncer.attach(SASPIN); debouncer.interval(5); along with the other pins. Seems to work fine for me, but even without the software debounce, I wasn't getting bouncing... Another question; if I wanted to use a pot/slide pot for throttle control, would any resistance value be fine? 50k linear pot, for example?

I thought a switch was simple too! I think the main reason I got confused was because my momentary switches are SPST, while my toggle switches are all SPDT. I wired the SPDT first, so my mind was "set" in that logic, so I kept it the same for the SPST switches, which was wrong I'm probably going to add some fancy LEDs and such myself too, but have to figure out how to multiplex/use shift registers so that I can expand the number of pins I have first. My abort lock toggle is one of those fancy ones with a built in LED, so it'd be nice to get it working! As for the debounce, I'll take a look at the software libraries, I believe there is an example that is included in the Arduino IDE, so I'm thinking I can just adapt that for use.

Thanks for the reply, I think I'm finally starting to understand this now. As I suspected, this would be the easiest case. Since the Arduino only has internal pull-up resistors, choosing to use pull-down resistors would mean additional hardware, hence, I went with the internal pull-up resistors. However, because of this, from what I understand, the state of the input is inverted to what I want to put in the control packet, hence, the boolean logic must also be inverted (i.e. the state of the input is HIGH, but I want the control packet to read LOW, and vice versa when the button is pressed). This is made more confusing because some of the switches I have (toggle switches) are SPDT, meaning depending on how I connect them, and depending on how I set my logic will ultimately affect how the game interprets it. I just realized that I have my toggle switches set one way, and the push buttons set another way (oops!) Aha! I thought this was the case. I noticed that sometimes if I held down the button slightly, my rocket wouldn't stage (because it was suck at 0 and preparing for the next rising transition). I'm smacking my forehead and should have realized it at the time! On another note, either a pull-up or a pull-down resistor will be required to prevent floating (erroneous) value reads, right? This code makes sense. I think mainly because when using pull-down resistors, the logic "makes sense" to humans, i.e. using a pull-down resistor, the bit value is LOW and so, the value passed to KSP is also LOW. Once you press the button, then the logic goes to HIGH, which also triggers the action. With a pull-up, everything is inverted! I read through all 80+ pages of this and even bookmarked where Mulbin had a similar problem (page 20 something), but didn't realize that this was the case here as well! Is there any reason you have the Stage pin and the Stage Lock pin separately and not simply wired in series? Also, is (software) debouncing absolutely required (I would assume for toggle SPDT switches, no, but for push buttons, perhaps?)

Reading your reply, some light is being shed, but I have a few more questions (sorry for all the questions) You mentioned there can only be 8 states; is it possible to have more, or is it limited to the number of possible bits in a byte (8 bits)? Now back to the code: A pull-up resistor for STAGEPIN would always return HIGH. With the wrong logic, when STAGEPIN is HIGH, then the STAGE bit is also set to HIGH, meaning it auto launches. This makes sense to me. I assume the STAGE bit is then set to LOW (after it is triggered once), so that the following stages also do not activate by themselves. Once I invert the logic, Since STAGEPIN has a pull-up and is reading HIGH, then the STAGE bit will read LOW (i.e. do not stage). When I press the button, STAGEPIN will read LOW, which causes the STAGE bit to read HIGH -> my rocket will stage. This makes sense. However, let's say I was using a pull-down resistor. Now the value of STAGEPIN will default to LOW. Which way would be the correct logic? To me, this seems correct. Read STAGEPIN. It is LOW (due to pull-down resistor). Thus, STAGE bit is also LOW (will not stage). Once I press the button, STAGEPIN is HIGH, so STAGE bit is also set to HIGH and my rocket will stage. Is this correct? Originally, I had my ABORTPIN and its logic set up the same (incorrect) way, i.e. If my thought process above was correct, why doesn't my rocket automatically ABORT everytime I launch? And finally, with the wrong logic, how come the rocket will only stage incorrectly upon the first load? If I go and launch a second rocket, it doesn't auto-stage.

Genius! Switching the logic around worked, though I'm trying to figure out why. I am using the Arduino's internal pull-up, which means the default (button not pressed) would indeed be HIGH. Looking at main controls () How does the value of STAGEPIN (either 0 or 1) get passed to MainControls() to either make STAGE have a HIGH or LOW value? Looking at MainControls () doesn't provide me with many clues (mainly because I don't know what it's actually doing).

So I have been investigating my issue and I believe I have been able to reproduce it successfully now. Hardware wise, I have two toggle switches connected to RCS and SAS (as per first post, pin 9 and 8, respectively). Pin 8 or 9 --> switch --> ground, as per instructions. No other wires. When I load KSPIODemo10, I get the expected behaviour, SAS and RCS turn on/off as expected. Now, I made the following changes to the Arduino code: In KSPIODemo10.ino: In output.ino - added staging in void controls (), commented out CPacket.Throttle, added pullup resistor for stage pin in void controlsInit () Now, I launch KSP (clean install except for KSPSerialIO) Go to VAB -> 1 man command pod, add a SRB to it and launch. A successful connection to the COM port is established, but the rocket will immediately take off. This is despite having nothing connected to pin 2. (Note: If I go ahead and connect pin 2 --> momentary button --> ground and make a multi-staged rocket, only the first SRB stage will auto-launch. The other stages will stage as expected when the momentary push button is pressed). Can anyone test to see if this is reproducible? Edit (more tests): Once the rocket is airborne, I press escape, click Space Centre (ignore the warning and proceed to Space Centre). The rocket will be on the launch pad. Click it, press Fly. The rocket will immediately take off again. Go back to the Space Centre (ignore the warning and proceed as before). Click the rocket on the launch pad and recover it. Go back to VAB, build the exact same rocket as before (it should still be loaded), and launch again. This time, the rocket will not auto launch. Go to Space Centre again, click the rocket on the launch pad, and click Fly. The rocket will not launch automatically.

I have a key lock switch (http://p.globalsources.com/IMAGES/PDT/B1008164425/Keylock-Switch.jpg) that is wired in series to a momentary push button. One side of the key lock switch goes to the assigned pin, while ground is connected to one side of the momentary switch. I also have the assigned stage pin internal pullup enabled with the following code, so I shouldn't be getting floating values. I notice that this problem happens when the Arduino is connecting to the interface for the first time after I launch the game. If I revert to VAB and try to launch again, everything is fine. I'll try to recreate this more accurately for troubleshooting.

Excellent; commenting out that line seems to have sorted out that problem. However, I am still getting an unusual problem with the first stage auto-staging. I've noticed it happens most frequently when I am launching my first ship after starting up the game. If I try to launch subsequent ships, there is no problem. This auto-staging happens even though my stage button is not being pressed.

So I am encountering a weird bug. http://imgur.com/Va5IkGK The picture doesn't say much, but when I have my controller plugged in, my throttle controls go wonky (even though I do not have anything hooked up physically to throttle controls). Pressing shift will increase throttle, as expected. Pressing 'Z' will increase my throttle to 100% instantly, as expected. Pressing control will decrease throttle, but only to the 1/3 mark (it will not decrease any further). Pressing 'X' at this time will kill my throttle instantly, but only to the 1/3 mark. If I press shift at this time, the throttle will suddenly jump to zero before starting to increase again. Anyone else have this problem? I don't think it is an Arduino coding problem, but am not sure. I'm wondering if this has anything to do with it...

Not to worry! You have already contributed so much by writing the plugin and the Arduino code. Besides, trying to figure out which parts of code do what is kind of like a puzzle. On another note, like Mulbin, when launching rockets from the VAB, the plugin seems to work fine, but if I load a rocket via the Launchpad, exit back to the space centre (leaving the rocket on the launch pad) and then try to reload the rocket via the Launchpad, I start to get weird results (auto staging; i.e. once the rocket loads, the first stage automatically stages!) This is despite not even having pressed my stage button. I need to do more testing tonight; I'm not sure if it's software related, or just due to me having a short somewhere (I've checked to ensure I have the internal pullup enabled so that I don't have floating values, so it shouldn't be that; hardware wise, I have a key-lock switch wired in series to a momentary push button, so both need to be closed before the Arduino reads a logic LOW)...

Yup. Went ahead and gave it a shot! Managed to get SAS, RCS and Gears working so far!

So if I understand this correctly, RCS is on the RCSPIN (9 in the demo code). When the pin value is read as high/low, the RCS enum value is set to either high/low, respectively. I'm assuming this is somehow then passed to the plugin to enable/disable RCS in game. Currently, in the demo code, Pins 5-7 are assigned for indicator LEDs, but if I were to (say) add in lights and brakes, I could simply just replace those lines with and then add the following to output.ino I made sure that the digitalRead matches the defined pin names (LIGHTSPIN) and then that the MainControls() part matches the defined enums in KSPIODemo.ino Finally, in the output.ino, I am also noticing I am assuming that I will also need to enable the internal pullup resistor for say LIGHTSPIN (pinMode(LIGHTSPIN, INPUT_PULLUP;) to ensure that I don't get floating values?

First, I want to thanks zitronen as well as everyone that is working on this project. I think it's a great way to combine programming, electronics with KSP (all things that I have interest in!) and as such, I'm currently trying to build my own KSP controller with some basic buttons, switches and an Arduino Uno. I'm still quite new, and was looking over the KSPIODemo10 example code and was not sure about one thing. So far, I understand that Are the defined pins for SAS (pin 8), RCS (pin 9) and so forth. Additional pins can be assigned to (say) control groups, lights, gears, brakes, etc relatively easily. However, I then see another part of the code I'm not quite sure what these assignments do. Are these pin assignments (i.e. if I wanted to assign (say) lights to pin 7, would this be possible? Though, looking at the top part of the code, it looks like pin 7 is assigned to a red LED for low fuel warning too...)

Excellent! Was hoping this would get updated!

Thanks! Hopefully I did it correctly (we'll find out soon enough!)

Excellent.

Where would these changes be made to the existing CFG that madadam has made?

Has anyone tested this in 0.90 yet?

Glad that this is at least documented. I was having a hell of a time trying to narrow down what was causing my EVA effects to disappear.