Antipaten

I'm using an Arduino Pro Micro clone for emulating joysticks in my project. Any 32u4 based arduino board can emulate keyboard and mouse right out of the box. Emulating joysticks requires an addon library (ArduinoJoystickLibrary) but it's trivial to use if you have 1.6.6+ of the Arduino IDE. (It was trickier in previous versions) KSP however has a strange quirk in the joystick handling. If I have several arduinos and emulate one joystick on each, everything works as expected. If I have a single Arduino and emulate two or more joysticks on it, KSP becomes confused of which joystick has which axes. You can assign the x-axis of one emulated joystick and KSP still tries to read values from the same axis on another joy during gameplay in an unpredictable way. The joystick buttons on the other hand works just as expected even when using multiple joysticks on the same Arduino so it's simple to use more than the 32 buttons per joystick that windows is able to handle. I solved the problem by writing the same axis values to all emulated joysticks at all time thus eliminating the need to predict any behaviour on the KSP side. This had the downside that I had to add an extra axis to the USB descriptor of each joystick in order to have enough different axes for rotation, translation and throttle.

I'm in the process of making my simpit KSP version proof by reducing it to an over powered mega joystick. My manual controls will have no functionality other than lots of analog axes and buttons. The reason for this is that the mods I've tried so far to pull data from the game tend to cause increased lag. The lag isn't very noticeable in testing the simpit, but becomes limiting when actually playing the game, using larger ships and a few extra mods. I hope the multi threading in Unity5 will fix this. If so, I will add displays and some automation later.

I haven't used Arduino to connect dirctly to kRPC. I use a Python script for the RPC calls and relay the data to Arduino using serial.

Thanks a lot. I will try the new release on a clean install and see if it works and if it does, I'll add my other mods i priority order. It may take a while though as I'm taking a break from KSP and my simpit at the moment, playing some Path of Exile while recovering from a couple of months of soft and hardware debugging. :-)

I have a few mods but I uninstalled all the graphics intense ones and lowered the graphics settings. The save contains quite a few satellites and stuff but I mainly asked because there was a marked difference between when kRPC was installed and when it was not and wanted to know if it was a common problem. I will run a more systematic testing on a clean KSP installation with the latest version of kRPC before I'm ready to cry bug for real. :-)

A small rocket is around 30 parts and a large is around 100. I get short "red lag" even without clients connected and no phys acceleration. Without the mod i can use 2x phys acceleration with green figures for the same (low part count) ship. Hopefully this will sort itself out when KSP 1.1 is released and we get the multihreading Unity5. Single threading is a real P.I.T.A as it is virtually impossible to throw better hardware on performance problems. I just wondered if anyone had encountered it and knew if I've done something silly in the settings. They are pretty much vanilla except for starting the server automatically and auto accepting clients. I didn't notice the lag until I really tried running the game for real using my control panel. The panel emulates joysticks for input to the game and only uses kRPC for reading fuel levels, acceleration, atmospheric density and mach number from the game every 200 ms.

I don't know if I'm doing something wrong, but when I started testing my control panel for real gaming I noticed that I had severe lag problems even with small rockets and it quickly became unplayable even at a modest part count. The problem becomes less pronounced if I request less data from the game but it isn't until I disconnect completely from the RPC server that it becomes a noticable difference, even when I set delay between reads as high as 200ms. There is still some lag even if there are no connections at all to kRPC that is enough to make big ships unflyable. This leads me to assume that something in the mod causes a delay in Unity and as it is single threaded it causes the entire game to stutter. Does anyone else have the same problem?

Hi Mulbin! Could you please update the link to my project? I moved it to http://antipaten.blogspot.se/ when the blogs were wiped due to the forum migration.

Oh, I will! :-)

[quote name='Sputnix']:O Blasphemy! * * * On a more serious note - did you try to increase the buffer size on the arduino itself?[/QUOTE] I increased it to 256 bytes but no change. :-(

[quote name='stibbons'] I'd be interested to see the code for your current work![/QUOTE] It's still ugly but it works. I will clean it up when I've learned enough Python (and maybe C++) to do it. I've used Python 3.5 and only added kRPC and the serial lib. The Arduino code is just the part that handles the serial communication. It's much more primitive than KSPserialIO as I have no buffering or checksums. If I get a bit error I will simply get confused data. I don't think that's a big problem though as the actual serial connection is located inside the chip and the rest is USB. If it becomes a problem I will add a checksum and send it before the payload. I've made a separate header file for the type declarations as I needed them to be added before the main program during compilation. If I just tossed everything into the .ino file it got added in some arbitrary place in the end of the compile. Edit: By the way. The Python code can handle multiple serial connections. I've tested it with two, but it should be able to handle more. Remember however that transmissions are not concurrent so each additional clients will get an increasing transmission delay. EditEdit: Maybe I should point out that this is in no way a plugin replacement to KSPserialIO and is not intended to be in the future. It uses a different data format and only transfers what I have use for at the client side at the moment. It should however be rather simple to adapt to your own needs by adding those fields that you need (and remove those you don't. Another note: This is for 1.0.4. I'm still waiting for a kRPC that is compatible with 1.0.5. Go and give djungelorm some appreciation so it's clear we want this update badly. :-) [B]K42_server.py[/B] [CODE] import krpc import serial import time import os import struct from serial.tools.list_ports_windows import * conn = 0 slask = 0 a=0 p=0 ser = [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0] s = 0 vessel = 0 os.system('cls') while ...: time.sleep(0.5) try: if s < 1: ports = comports() for port in ports: try: ser[s] = serial.Serial(port[0], 115200) ser[s].timeout = 1 ser[s].write_timeout = 1 slask = ser[s].write(b"Mhi\0") slask = ser[s].read(4) if slask != b'K42': ser[s].close() ser[s] = 0 #print("Handshake failed for K-42 on", port[0]) else: s += 1 print ("Connected to client on", port[0]) except serial.SerialException: print("Could not open serial port",port[0]) ser[s] = 0 except serial.SerialTimeoutException: print("Serial communication timeout") ser[s].close() ser[s] = 0 if conn == 0: try: conn = krpc.connect(address='192.168.0.101', name='K-42 Connector') print ("Connected to kRPC!") except krpc.error.NetworkError: conn = 0 else: if vessel == 0: try: vessel = conn.space_center.active_vessel print ("Vessel selected:", vessel.name) Warp = conn.add_stream(getattr, conn.space_center, 'warp_factor') Apoapsis = conn.add_stream(getattr, vessel.orbit, 'apoapsis_altitude') TimeApoapsis = conn.add_stream(getattr, vessel.orbit, 'time_to_apoapsis') Periapsis = conn.add_stream(getattr, vessel.orbit, 'periapsis_altitude') TimePeriapsis = conn.add_stream(getattr, vessel.orbit, 'time_to_periapsis') Gforce = conn.add_stream(getattr, vessel.flight(), 'g_force') AtmDensity = conn.add_stream(getattr, vessel.flight(), 'atmosphere_density') RadarAltitude = conn.add_stream(getattr, vessel.flight(), 'surface_altitude') Mach = conn.add_stream(getattr, vessel.flight(), 'mach') VerticalSpeed = conn.add_stream(getattr, vessel.flight(), 'vertical_speed') HorizontalSpeed = conn.add_stream(getattr, vessel.flight(), 'horizontal_speed') SolidFuelCurrent = conn.add_stream(vessel.resources.amount, 'SolidFuel') SolidFuelMax = conn.add_stream(vessel.resources.max, 'SolidFuel') OxidizerCurrent = conn.add_stream(vessel.resources.amount, 'Oxidizer') OxidizerMax = conn.add_stream(vessel.resources.max, 'Oxidizer') LiquidFuelCurrent = conn.add_stream(vessel.resources.amount, 'LiquidFuel') LiquidFuelMax = conn.add_stream(vessel.resources.max, 'LiquidFuel') MonoPropellantCurrent = conn.add_stream(vessel.resources.amount, 'MonoPropellant') MonoPropellantMax = conn.add_stream(vessel.resources.max, 'MonoPropellant') IntakeAirCurrent = conn.add_stream(vessel.resources.amount, 'IntakeAir') IntakeAirMax = conn.add_stream(vessel.resources.max, 'IntakeAir') XenonGasCurrent = conn.add_stream(vessel.resources.amount, 'XenonGas') XenonGasMax = conn.add_stream(vessel.resources.max, 'XenonGas') ElectricChargeCurrent = conn.add_stream(vessel.resources.amount, 'ElectricCharge') ElectricChargeMax = conn.add_stream(vessel.resources.max, 'ElectricCharge') Parts = conn.add_stream(getattr, vessel.parts, 'all') Stage = conn.add_stream(getattr, vessel.control, 'current_stage') SAS = conn.add_stream(getattr, vessel.control, 'sas') RCS = conn.add_stream(getattr, vessel.control, 'rcs') Gear = conn.add_stream(getattr, vessel.control, 'gear') Lights = conn.add_stream(getattr, vessel.control, 'lights') Brakes = conn.add_stream(getattr, vessel.control, 'brakes') Abort = conn.add_stream(getattr, vessel.control, 'abort') except krpc.error.RPCError: vessel = 0 if vessel != 0 and s > 0: try: if LiquidFuelMax() > 0: # Percentage of max in stage (if none always 101%) LiquidFuel = 100 * LiquidFuelCurrent() / LiquidFuelMax() else: LiquidFuel = 101 if OxidizerMax() > 0: # Percentage of max in stage (if none always 101%) Oxidizer = 100 * OxidizerCurrent() / OxidizerMax() else: Oxidizer = 101 if SolidFuelMax() > 0: # Percentage of max in stage (if none always 101%) SolidFuel = 100 * SolidFuelCurrent() / SolidFuelMax() else: SolidFuel = 101 if MonoPropellantMax() > 0: # Percentage of max in stage (if none always 101%) MonoPropellant = 100 * MonoPropellantCurrent() / MonoPropellantMax() else: MonoPropellant = 101 if IntakeAirMax() > 0: # Percentage of max in stage (if none always 101%) IntakeAir = 100 * IntakeAirCurrent() / IntakeAirMax() else: IntakeAir = 101 if XenonGasMax() > 0: # Percentage of max in stage (if none always 101%) XenonGas = 100 * XenonGasCurrent() / XenonGasMax() else: XenonGas = 101 if ElectricChargeMax() > 0: # Percentage of max in stage (if none always 101%) ElectricCharge = 100 * ElectricChargeCurrent() / ElectricChargeMax() else: ElectricCharge = 101 MaxHeat = 0 p = Parts() for part in p: MaxHeat = max(MaxHeat, part.temperature / part.max_temperature) MaxHeat = max(MaxHeat, part.skin_temperature / part.max_skin_temperature) MaxHeat *= 100 # Percentage of max for most sensitive part Switches = 0 if SAS(): Switches += 1; if RCS(): Switches += 2; if Gear(): Switches += 4; if Lights(): Switches += 8; if Brakes(): Switches += 16; if Abort(): Switches += 32; msg = struct.pack('<4sB10f10B', b'MSG\0', int(Warp()), Apoapsis(), TimeApoapsis(), Periapsis(), TimePeriapsis(), Gforce(), (AtmDensity()/1.136), RadarAltitude(), Mach(), VerticalSpeed(), HorizontalSpeed(), int(LiquidFuel), int(Oxidizer), int(SolidFuel), int(MonoPropellant), int(IntakeAir), int(XenonGas), int(ElectricCharge), int(MaxHeat), int(Stage()), int(Switches)) for connection in ser: if connection != 0: slask = connection.write(msg) # unsigned char Warp; # float Apoapsis; # float TimeApoapsis; # float Periapsis; # float TimePeriapsis; # float Gforce; # float AtmDensity; # float RadarAltitude; # float Mach; # float VerticalSpeed; # float HorizontalSpeed; # unsigned char LiquidFuel; # unsigned char Oxidizer; # unsigned char SolidFuel; # unsigned char MonoPropellant; # unsigned char IntakeAir; # unsigned char XenonGas; # unsigned char ElectricCharge; # unsigned char MaxHeat; # unsigned char Stage; # unsigned char Switches; except krpc.error.RPCError: print("Vessel disconnected") vessel = 0 except OSError: print("Server shut down") time.sleep(1) conn.close() conn = 0 vessel = 0 except ConnectionAbortedError: print("Connection aborted") time.sleep(1) conn.close() conn = 0 vessel = 0 except KeyboardInterrupt: print("Quit") for q in ser: if q != 0: q.close() if conn != 0: conn.close() time.sleep(1) break [/CODE] [B]serial.h [/B][CODE] // Kommodore_42 communication Code v 1.0 // Copyleft: Rescalable Decomposites 2015 // No rights Deserved #define KSPOUT_SAS 1 #define KSPOUT_RCS 2 #define KSPOUT_GEAR 4 #define KSPOUT_LIGHTS 8 #define KSPOUT_BRAKES 16 #define KSPOUT_ABORT 32 struct KSP_ODATA { unsigned char Warp; float Apoapsis; float TimeApoapsis; float Periapsis; float TimePeriapsis; float Gforce; float AtmDensity; float RadarAltitude; float Mach; float VerticalSpeed; float HorizontalSpeed; unsigned char LiquidFuel; unsigned char Oxidizer; unsigned char SolidFuel; unsigned char MonoPropellant; unsigned char IntakeAir; unsigned char XenonGas; unsigned char ElectricCharge; unsigned char MaxHeat; unsigned char Stage; unsigned char Switches; }; [/CODE] [B]serial.ino [/B]I've removed some code that sent and cleared error indicators on my alarm module. I haven't tried to compile it in its current form so there might be I've removed too much somewhere. Just let me know if it looks uncomprehensible and I'll post the complete code. [CODE] // Kommodore_42 communication Code v 1.0 // Copyleft: Rescalable Decomposites 2015 // No rights Deserved void getFromSerial() { static unsigned long timer_KSP; // Get data from Kerbal using K42-server and kRPC if(Serial.available() >= 3){ while(Serial.peek() != 'M') Serial.read(); // Get rid of garbage Serial.readBytes(s,4); // Get header if(strncmp(s,"Mhi",4) == 0){ // Handshake Serial.print("K42"); // Return handshake }else if(strncmp(s,"MSG",4) == 0){ // Data packet b = (byte *) &ksp_out; for(i = 0 ; i < sizeof(KSP_ODATA) ; i++){ // This doesn't work very well actually. We get garbage if packet is truncated. b[i] = Serial.read(); } if(!ksp_avail) { ksp_avail = true; } } timer_KSP = millis(); } else { // We didn't get anything within reasonable time. if (millis() - timer_KSP > 2500) { // Timeout 2.5 seconds timer_KSP = millis() - 2400; if(ksp_avail) { ksp_avail = false; } } } } [/CODE]

TL;DR; I've quit using KSPserialIO as it crasches the game. I use kRPC instead. /TL;DR; Long story: If anyone is having problems really [I]playing[/I] the game using your hardware controls It may be due to KSPserialIO. My game crashed after playing only a couple of minutes and I in the end I removed every single mod except KSPserialIO in order to make it run reliably. I still had crashes (or actually lockups) after 3 to 10 minutes. Nothing in the logs so I couldn't pinpoint what went wrong. I tried to decrease the number of control packets I sent back to KSP and even stopped using control packets entirely and added another joystick emulation to handle all the control axes and switches. It still crashed. Then I decreased the serial transmission speed as I didn't need to update as often when I didn't use the mod for input. That seemed to work, but in the end it only delayed the crashes and gave about ten more minutes extra game time before going catatonic. Then I finally threw out KSPserialIO and searched for at workaround. My first thought was to use Telemachus and write a json to serial converter in Python. While it certainly was doable it would force me to start dabbling with websockets and JSON in a language I didn't know. I searched on and found kRPC, a mod that makes KSP innards available using RPC calls over the network (warranty void if used outside localhost). This made connecting to KSP using Python or LUA using ordinary objects or function calls. Ok, I didn't feel like learning LUA so I still had to learn Python, but without the added hassle of web tech which was nice for a old school guy like me. It took me about three or four days to get the first kRPC to serial converter up and running and it worked most of the time. No game craches and if the converter crashed (which it did alot) I could restart it without having to restart the game. A couple of days later I had error handling in place and the whole thing run smooth as butter. After doing a Jool expedition in one single session without crashes I've decided that the problem is solved. <shameless_plug> For even more reading about my project go to my blog: [URL]http://antipaten.blogspot.se/[/URL] </shameless_plug>

Will this mod be updated to 1.0.5? With a little luck it may just need adding a variable for core temperature, but I don't know the inside of KSP so I'm probably wrong. BTW, I really love this mod. It saved my control console project when I had isolated the source of my recurring game crashes to KSPserialIO. Thanks to this I could solve it with a Python script. Well a Python script after having learnt Python that is, but anyway... :-)

That's a major task for a little 8-bit CPU at only 16MHz. I got an idea that I haven't tried but it could make things much easier on the CPU: Why not offload the CPU by going partly analog? If you output simple 400 Hz square wave you don't need any table lookups and no multiplication. Just output a 10 phase square wave and use an analog 400 Hz low pass filters to convert the signal to sine wave. If it works, all that Arduino would have to do is to wait for the timer instead of trying to do signal processing math with only a micro controller core.

I've also experienced the problem that SAS stops working when using manual input through the mod. SAS is still indicated as active but it stops doing anything until you disable it and reenable it. The problem is only when using input through this mod as both using a regular joystick and emulating a joystick with the arduino works fine. You don't have to toggle SAS using keyboard to make it work again, using serial though the mod also works.

It isn't actually that expensive to buy the simpler arduinos if you buy clones from China. I bought the pro mini clones I use in my modules for $3 each from Banggood.com and it should be possible to get close to $2 if you accept longer delivery times, buy a larger batch (i but I bought five at a time) or spend some time looking for a bargain on several web stores. The Pro Micro cost three times as much, need only one 32u4 to emulate all USB devices. The total cost for all arduinos was less than $40 and I still have one left over.

Declaring av SoftwareSerial object will reserve both pins, even if you only use one of them for serial output. I recommend you don't try to redeclare any of them for other purposes even if you don't use serial input as it may (will?) cause strange things. As for my K-42: Thank's a lot for the appreciation. I have the main code up and running and all 10 interconnected arduinos in the console works as planned. The problem I ran into the other day was that I've used up all RAM in the Arduino Pro Mini I use as master node when trying to implement the Guidance Computer functionality. I plan to get a Mega just for its larger memory capacity and use it to implement the guidance computer. I will probably keep the Mini as an output slave as it has better native support for emulating USB devices and also because that way I can keep much of the already tested and working code and use all memory in the Mega for guidance programs. As for the layout, it is totally changeable. I can swap places of any modules as I please without reprogramming or resoldering. There is only a four wire bus for power and data that connects them and it can be extended with any type of wiring that can handle a modest 100kb/s, which should be any audio wire as long as they are reasonably limited in length. I actually have some plans to extend the system and build an overhead panel with some 7 segment displays I have laying around, and later on maybe build a couple of module enclosures on my chair arm rests and move joysticks and throttle modules to them. I just love modularity. If I ever get sufficient space and wife acceptance I will build a real simpit and mount my module inside it.

If I understand your code correctly you're trying to use pin 2 and 3 for SoftwareSerial but they are also defined as input pins in Zitronens code. That will probably get really messy I/O-wise. Hope that helps a bit...

That's just the mockup that SpaceX use for PR. The real ones will have Apollo type Honeywell switches.

I'm running Windows 7 and it works fine. If you can get your hands on a copy of 7 it would probably be the best way on getting on with your project. Another alternative would be to run Linux and get proper 64 bit support too.

In the beginning of the Kuran program there was far advanced plans to modernize the old Kerpollo concept and replace all mechanical switches and gauges with touch panels. Fortunately a bright young engineer came up with a new concept called "simulation and testing" which immediately seemed quite useful for replacing the old random trial and error method from Kerpollo. Tests in a simulator showed that touch screens were impossible to use wearing thick spacesuit gloves and just as impossible using spacesuit boots. Another problem was that every time the guidance computer crashed and caused a green screen, all the instrumentation was lost. It was therefore decided that old school gadgets such as rudder pedals, joystick controls, mechanical switches and even analog gauges had practical applications in the near future of space exploration. Of course a special touch control only mockup was presented to politicians and press in order not to make the taxpaying part of kerbalkind disappointed. "For most kerbals, design IS ore important than functionality", as Steve Kerman, CEO of Banana Inc., always used to say.

I like your approach to this. Can't wait to see the result. A tape puncher/reader from an old Teletype would be even better than a floppy drive but is probably hard to find these days. Don't forget the snacks compartment. :-)

In case anyone is interested I take the liberty of promoting myselft in this thread... but that's what it's meant for anyway, isn't it? :-) I've begun a little article series on my simpit project in my blog here on the forum. The first part is about the construction of the enclosure and the module interconnect. Nothing radically fancy, rather a study in simplicity. I will post more further on with descriptions of each module when I got some spare time. Hope you enjoy. http://forum.kerbalspaceprogram.com/entries/3710-K-42-The-hardware-part-1-Backplane-and-enclosure

Have you tested the displays separately from the driver module? Green LEDs have a voltage drop of around 2.1 Volts while red usually is around 1.7 Volts. It could be that the driver voltage is too low to light the segments of some of the green LEDs. I've experienced that problem when swapping out single green LEDs in a build, one green LED lights up fine and another won't light up at all but it works with any red LED im trying. When testing with a lower resistance value all green LEDs turn out to be working. Edit: You asked me about what keyboard I used for my project. I found one on AliExpress that might be it. I'm not sure it is exactly the same but it looks identical as far as I can judge from a picture. http://www.aliexpress.com/item/Mechanical-keyboard-cherry-84-compact-mini-G84-4100-cherry-ML-Black-switches-portable-game-keyboard/32448772989.html?spm=2114.01020208.3.10.VryVDc

Tested. Looks like it works, IVA shakes as it should, but I can't say anything about how stable it is.