[Hardware, Plugin] Arduino based physical display + serial port io+ tutorial (24-11-19)

[FreakPsych]

Ok, so the serial port is sending the correct handshake request to the arduino, and arduino is responding correctly, but some how the plugin is not receiving properly.

A couple of things to try:

1. What if you just add a delay in the handshake() function before KSPBoardSendData(details(HPacket)); of say 500ms? Anythng less than 1.5 seconds should work.

2. Try running this code which basically spams the handshake reply:

byte handshake[8] = {0xBE, 0xEF, 0x04, 0x00, 0x03, 0x01, 0x04, 0x02};

void setup() {
  Serial.begin(38400);
}

void loop() {
  for (byte k = 0; k < 8; k++) {
    Serial.write(handshake[k]);
  }

  delay(20);
}

Ok, i have tried both, but none of them worked.

While spamming the handshake i can see the data on the serial port incomming into win10, but somehow it does not come into the addon. Strange... Maybe microsoft has something changed or forgotten in the serial librarys ?

I will play on win7 the next days. so no problem.

[zitronen]

Ok, i have tried both, but none of them worked.

While spamming the handshake i can see the data on the serial port incomming into win10, but somehow it does not come into the addon. Strange... Maybe microsoft has something changed or forgotten in the serial librarys ?

I will play on win7 the next days. so no problem.

Well the problem is not with microsoft, I'm sure the serial port stuff in .Net works just fine. The problem is we are forced to use a really crappy serial port library because we don't have access to the proper stuff from Unity.

I have a few other things I can try before I give up.

[Antipaten]

Hi Zitronen and everybody else too!

When using an Arduino based on Atmega 32u4 it is possible to send keyboard commands when throwing switches and pushing buttons.

One thing that messes things up is that I have no way of knowing if the key sequence actually is sent to KSP as I have no way of detecting if the KSP window is in focus or not. This may mess things up a lot when control keys are sent all over the place, writing in my editors or autosurfing the web. It would be great to have in the mod is a simple flag that tells if KSP is in focus, and if possible also if the key press is received by KSP as a keyboard command (as opposed to entering numbers into MechJeb for example).

I guess getting this wish fulfilled might be a lot more complicated than it sounds as it crosses the border between Unity and the operating system as well as between KSP and a diverse variety of mods. Anyway you decide, I love this mod as it makes it possible to create a much deeper immersion in the game than a simple keyboard, mouse and joystick combo ever could.

Edited August 22, 2015 by Antipaten

[Freshmeat]

@Antipaten: I've found it easier just to install a scavenged USB keyboard PCB with switches to connect proper pins for keypresses.

[Antipaten]

@Antipaten: I've found it easier just to install a scavenged USB keyboard PCB with switches to connect proper pins for keypresses.

That would still not solve my problem of avoiding to send the keypresses to the wrong program. I run KSP in windowed mode as I have three screens om my desktop. I like to have the wiki on one screen and make notes and calculations on another while playing. If there would be a working solution for having mapmode on an alternate screen, I would hook up a fourth one in an instant. You can't have too many information screens in a space program. :-)

Sending keypresses with an Arduino Pro Micro is trivial and a lot more compact and flexible than using av keyboard PCB. I use triple-key commands to get a bunch of key combinations that interfere as little as possible with normal Kerbal keyboard control. I want to retain the ability to fall back on flying with keyboard too until I feel that my simpit is space ready.

Edited August 24, 2015 by Antipaten

[Freshmeat]

Point taken.

BTW, I guess you know of Telemachus for sending information to additional screens? I usually keep a topographical map on a tablet during landing runs.

[Antipaten]

I know about telemachus but i haven't tried it yet.

You gave me a thought there actually. If I got a small screen and make it part of my simpit build I could use it to show telemachus data, maybe a little navball and some orbit rendering, maybe with a Raspberry Pi running the browser. Hmm... have to think about it. Thanks!

[zitronen]

That would still not solve my problem of avoiding to send the keypresses to the wrong program. I run KSP in windowed mode as I have three screens om my desktop. I like to have the wiki on one screen and make notes and calculations on another while playing. If there would be a working solution for having mapmode on an alternate screen, I would hook up a fourth one in an instant. You can't have too many information screens in a space program. :-)

Sending keypresses with an Arduino Pro Micro is trivial and a lot more compact and flexible than using av keyboard PCB. I use triple-key commands to get a bunch of key combinations that interfere as little as possible with normal Kerbal keyboard control. I want to retain the ability to fall back on flying with keyboard too until I feel that my simpit is space ready.

I don't quite understand what you are doing, is your program trying to send key commands to KSP automatically all the time? If you are just pressing the buttons yourself I don't see how you can even play KSP if it's not in focus??

[Antipaten]

I don't quite understand what you are doing, is your program trying to send key commands to KSP automatically all the time? If you are just pressing the buttons yourself I don't see how you can even play KSP if it's not in focus??

My device will be able to send keyboard commands even if I'm away fishing as it will eventually contain a small autopilot able to make launches and landings. Even if I've not yet implemented the automatic features, manual control can be destructive if it sends commands to the wrong program, and I am a heavy multitasker when using computers.

I'll try to give you a use case:

I'm playing KSP on my center screen, approaching Duna. On my left screen I have a web browser showing data on Duna so I know what atmospheric height it has (OK! I have bad memory. Just accept it for now.) Om my right I'm writing the next Great American Novel of my generation (not very believable as I'm not from the US and a mediocre writer at best, but you get the point, important stuff and such). As all great authors I haven't made a save for a couple of hours while writing the most profound passage ever put into words. Oh ooh! :-(

I wait until I hit the atmosphere and throw the airbrake switch to slow down. Nothing happens in Kerbal, but my word processor, which has focus, quits without saving and Valentina becomes a screaming fireball going down while I curse all powers in the universe.

Outcome: Player ragequitting, unistalling the game and using office chair to demolish the control panel.

If I had a bit in KSP Serial IO that indicated if KSP had focus, I could program my control panel not to send the keyboard command immediately but instead sound the master alarm and indicate a computer failure. That way my novel would still be intact waiting for me to make a save. I will not be freaking out, and I can bring focus back to KSP. When my control panel notice that focus is back it can send the keyboard commands and shut off the alarm.

Alternate outcome: Mission successful, happy player, Nobel prize in litterature, funny postings on forum.

[zitronen]

My device will be able to send keyboard commands even if I'm away fishing as it will eventually contain a small autopilot able to make launches and landings. Even if I've not yet implemented the automatic features, manual control can be destructive if it sends commands to the wrong program, and I am a heavy multitasker when using computers.

I'll try to give you a use case:

I'm playing KSP on my center screen, approaching Duna. On my left screen I have a web browser showing data on Duna so I know what atmospheric height it has (OK! I have bad memory. Just accept it for now.) Om my right I'm writing the next Great American Novel of my generation (not very believable as I'm not from the US and a mediocre writer at best, but you get the point, important stuff and such). As all great authors I haven't made a save for a couple of hours while writing the most profound passage ever put into words. Oh ooh! :-(

I wait until I hit the atmosphere and throw the airbrake switch to slow down. Nothing happens in Kerbal, but my word processor, which has focus, quits without saving and Valentina becomes a screaming fireball going down while I curse all powers in the universe.

Outcome: Player ragequitting, unistalling the game and using office chair to demolish the control panel.

If I had a bit in KSP Serial IO that indicated if KSP had focus, I could program my control panel not to send the keyboard command immediately but instead sound the master alarm and indicate a computer failure. That way my novel would still be intact waiting for me to make a save. I will not be freaking out, and I can bring focus back to KSP. When my control panel notice that focus is back it can send the keyboard commands and shut off the alarm.

Alternate outcome: Mission successful, happy player, Nobel prize in litterature, funny postings on forum.

Ok what keys are you trying to send? Most of the input commands (stage, abort, control groups, axes, etc.) can be sent directly through the plugin over serial in the background without having to use the keyboard commands.

[Antipaten]

Ok what keys are you trying to send? Most of the input commands (stage, abort, control groups, axes, etc.) can be sent directly through the plugin over serial in the background without having to use the keyboard commands.

Some pictures of my project can be found at:

https://picasaweb.google.com/100548400606454481782/Kerbal?authuser=0&feat=directlink

I've also started writing a series of blog articles on this forum that describes my projekt more in detail:

http://forum.kerbalspaceprogram.com/...-and-enclosure

They might give you a better idea of what I'm building. Joysticks use your mod, as do stage abort, CG 1-10, RCS, Brake Light, SAS etc.

Come to think of it, if you could add support for Action Groups Extended it would also solve the problem, but that would increase the packet size quite a bit over your 255 byte limit.

This is the current mapping of switches to key combinations and action groups so far (I'm using Action Groups Extended):

[TABLE]

[TR]

[TD][/TD]

[TD][/TD]

[TD=colspan: 2]Key combination[/TD]

[TD=colspan: 2]Action group[/TD]

[/TR]

[TR]

[TD]Power & Com.[/TD]

[TD][/TD]

[TD]Up[/TD]

[TD]Down[/TD]

[TD]Up[/TD]

[TD]Down[/TD]

[/TR]

[TR]

[TD]Reaction wheels[/TD]

[TD][/TD]

[TD]RCtrl + 0[/TD]

[TD]RCtrl + 1[/TD]

[TD]20[/TD]

[TD]21[/TD]

[/TR]

[TR]

[TD]S/A[/TD]

[TD][/TD]

[TD]RCtrl + 2[/TD]

[TD]RCtrl + 3[/TD]

[TD]22[/TD]

[TD]23[/TD]

[/TR]

[TR]

[TD]F/C[/TD]

[TD][/TD]

[TD]RCtrl + 4[/TD]

[TD]RCtrl + 5[/TD]

[TD]24[/TD]

[TD]25[/TD]

[/TR]

[TR]

[TD]Radiator 1[/TD]

[TD][/TD]

[TD]RCtrl + 6[/TD]

[TD]RCtrl + 7[/TD]

[TD]26[/TD]

[TD]27[/TD]

[/TR]

[TR]

[TD]Radiator 2[/TD]

[TD][/TD]

[TD]RCtrl + 8[/TD]

[TD]RCtrl + 9[/TD]

[TD]28[/TD]

[TD]29[/TD]

[/TR]

[TR]

[TD]Bat1[/TD]

[TD][/TD]

[TD]RShift + 0[/TD]

[TD]RShift + 1[/TD]

[TD]30[/TD]

[TD]31[/TD]

[/TR]

[TR]

[TD]Bat2[/TD]

[TD][/TD]

[TD]RShift + 2[/TD]

[TD]RShift + 3[/TD]

[TD]32[/TD]

[TD]33[/TD]

[/TR]

[TR]

[TD]LoGain[/TD]

[TD][/TD]

[TD]RShift + 4[/TD]

[TD]RShift + 5[/TD]

[TD]34[/TD]

[TD]35[/TD]

[/TR]

[TR]

[TD]HiGain[/TD]

[TD][/TD]

[TD]RShift + 6[/TD]

[TD]RShift + 7[/TD]

[TD]36[/TD]

[TD]37[/TD]

[/TR]

[TR]

[TD][/TD]

[TD][/TD]

[TD][/TD]

[TD][/TD]

[TD][/TD]

[TD][/TD]

[/TR]

[TR]

[TD]Engine & Chutes[/TD]

[TD][/TD]

[TD][/TD]

[TD][/TD]

[TD][/TD]

[TD][/TD]

[/TR]

[TR]

[TD]Aero on/off[/TD]

[TD][/TD]

[TD]RShift + 8[/TD]

[TD]RShift + 9[/TD]

[TD]38[/TD]

[TD]39[/TD]

[/TR]

[TR]

[TD]Aero rev[/TD]

[TD][/TD]

[TD]RCtrl + RShift + 0[/TD]

[TD]RCtrl + RShift + 1[/TD]

[TD]40[/TD]

[TD]41[/TD]

[/TR]

[TR]

[TD]Intake1 Toggle[/TD]

[TD][/TD]

[TD][/TD]

[TD][/TD]

[TD]9[/TD]

[TD][/TD]

[/TR]

[TR]

[TD]Intake2 Toggle[/TD]

[TD][/TD]

[TD][/TD]

[TD][/TD]

[TD]10[/TD]

[TD][/TD]

[/TR]

[TR]

[TD]Main on/off[/TD]

[TD][/TD]

[TD]RCtrl + RShift + 4[/TD]

[TD]RCtrl + RShift + 5[/TD]

[TD]46[/TD]

[TD]47[/TD]

[/TR]

[TR]

[TD]Main mode[/TD]

[TD][/TD]

[TD]RCtrl + RShift + 6[/TD]

[TD]RCtrl + RShift + 7[/TD]

[TD]48[/TD]

[TD]49[/TD]

[/TR]

[TR]

[TD]Sec. On/off[/TD]

[TD][/TD]

[TD]RCtrl + RShift + 8[/TD]

[TD]RCtrl + RShift + 9[/TD]

[TD]50[/TD]

[TD]51[/TD]

[/TR]

[TR]

[TD]Sec. Mode[/TD]

[TD][/TD]

[TD]RCtrl + G[/TD]

[TD]RCtrl + H[/TD]

[TD]52[/TD]

[TD]53[/TD]

[/TR]

[TR]

[TD]Drogue deploy[/TD]

[TD][/TD]

[TD]RCtrl + I[/TD]

[TD][/TD]

[TD]54[/TD]

[TD][/TD]

[/TR]

[TR]

[TD]Drogue cut[/TD]

[TD][/TD]

[TD]RCtrl + J[/TD]

[TD][/TD]

[TD]56[/TD]

[TD][/TD]

[/TR]

[TR]

[TD]Main chute deploy[/TD]

[TD][/TD]

[TD]RCtrl + K[/TD]

[TD][/TD]

[TD]58[/TD]

[TD][/TD]

[/TR]

[TR]

[TD]Main chute cut[/TD]

[TD][/TD]

[TD]RCtrl + L[/TD]

[TD][/TD]

[TD]60[/TD]

[TD][/TD]

[/TR]

[TR]

[TD][/TD]

[TD][/TD]

[TD][/TD]

[TD][/TD]

[TD][/TD]

[TD][/TD]

[/TR]

[TR]

[TD]Left hand control[/TD]

[TD][/TD]

[TD][/TD]

[TD][/TD]

[TD][/TD]

[TD][/TD]

[/TR]

[TR]

[TD]Ladder[/TD]

[TD][/TD]

[TD]RCtrl + N[/TD]

[TD]RCtrl + U[/TD]

[TD]62[/TD]

[TD]63[/TD]

[/TR]

[TR]

[TD]Docking Toggle[/TD]

[TD][/TD]

[TD][/TD]

[TD][/TD]

[TD]7[/TD]

[TD][/TD]

[/TR]

[TR]

[TD]Cargo Bay Toggle[/TD]

[TD][/TD]

[TD][/TD]

[TD][/TD]

[TD]8[/TD]

[TD][/TD]

[/TR]

[TR]

[TD]Airbrake[/TD]

[TD][/TD]

[TD]RCtrl + RShift + J[/TD]

[TD]RCtrl + RShift + K[/TD]

[TD]68[/TD]

[TD]69[/TD]

[/TR]

[TR]

[TD][/TD]

[TD][/TD]

[TD][/TD]

[TD][/TD]

[TD][/TD]

[TD][/TD]

[/TR]

[TR]

[TD]Mission Specific[/TD]

[TD][/TD]

[TD][/TD]

[TD][/TD]

[TD][/TD]

[TD][/TD]

[/TR]

[TR]

[TD]AG-01[/TD]

[TD][/TD]

[TD][/TD]

[TD][/TD]

[TD]1[/TD]

[TD][/TD]

[/TR]

[TR]

[TD]AG-02[/TD]

[TD][/TD]

[TD][/TD]

[TD][/TD]

[TD]2[/TD]

[TD][/TD]

[/TR]

[TR]

[TD]AG-03[/TD]

[TD][/TD]

[TD][/TD]

[TD][/TD]

[TD]3[/TD]

[TD][/TD]

[/TR]

[TR]

[TD]AG-04[/TD]

[TD][/TD]

[TD][/TD]

[TD][/TD]

[TD]4[/TD]

[TD][/TD]

[/TR]

[TR]

[TD]AG-11[/TD]

[TD][/TD]

[TD]RCtrl + RShift + 2[/TD]

[TD]RCtrl + RShift + 3[/TD]

[TD][/TD]

[TD][/TD]

[/TR]

[TR]

[TD]AG-12[/TD]

[TD][/TD]

[TD]RCtrl + RShift + N[/TD]

[TD]RCtrl + RShift + U[/TD]

[TD][/TD]

[TD][/TD]

[/TR]

[TR]

[TD]AG-13[/TD]

[TD][/TD]

[TD]RCtrl + RShift + G[/TD]

[TD]RCtrl + RShift + I[/TD]

[TD][/TD]

[TD][/TD]

[/TR]

[/TABLE]

Edited August 30, 2015 by Antipaten

[zitronen]

That looks pretty damn nice! I remember the author of AGE started to look at getting a way to for us to do that, haven't followed up on what happened.

[nicknack1234]

How is this going? I was pointed here by a KSP enthusiast. I have a bunch of knowledge in C# .NET4 and Arduino. I have a Windows 10 application front end i made running and issuing commands to an arduino successfully for a project. I am not familiar with KSP IO library but i will look in to it. If you guys can provide a basic list of requirements I can probably throw something together that will run on windows 10.

[Tokamak]

This mod is delightful. I've actually spent the past week constructing an arduino based controller to use with this mod, and I am having a blast. One weird thing is happening, however. I wonder if anyone has any idea what could be causing this: staging works, except for parachutes.

To be more specific, my control hardware has a "stage" button that calls the stage command. When I use that, it seems to work correctly. Decouplers decouple, engines ignite, et cetera... except for one parachutes. The icons on the screen move about as expected when a stage fires, but even a parachute that looks like it is enabled by the current stage will not deploy. I know it's not the craft design, because if I reach over to my keyboard and hit space... boom, the parachute stages.

I'm really scratching my head here... any thoughts?

Edited September 4, 2015 by Tokamak

[Freshmeat]

I know you probably have thought of it, but parachutes stay inside their cover until pressure is high enough. There is nothing special in their stage, so if staging works, it works. Have you tried staging parachutes at altitudes less than 5000m on Kerbin? Otherwise, I have no idea.

[zitronen]

How is this going? I was pointed here by a KSP enthusiast. I have a bunch of knowledge in C# .NET4 and Arduino. I have a Windows 10 application front end i made running and issuing commands to an arduino successfully for a project. I am not familiar with KSP IO library but i will look in to it. If you guys can provide a basic list of requirements I can probably throw something together that will run on windows 10.

If you are using system.io, then it's easy to get serial port working on any windows version, but we don't have it. Currently the problem seems to be receiving data from arduino, might be threading or event handler related. The main problem is I don't have win 10 and not really planning on upgrading any time soon. The code is on github, so you can try it yourself if you have time.

- - - Updated - - -

This mod is delightful. I've actually spent the past week constructing an arduino based controller to use with this mod, and I am having a blast. One weird thing is happening, however. I wonder if anyone has any idea what could be causing this: staging works, except for parachutes.

To be more specific, my control hardware has a "stage" button that calls the stage command. When I use that, it seems to work correctly. Decouplers decouple, engines ignite, et cetera... except for one parachutes. The icons on the screen move about as expected when a stage fires, but even a parachute that looks like it is enabled by the current stage will not deploy. I know it's not the craft design, because if I reach over to my keyboard and hit space... boom, the parachute stages.

I'm really scratching my head here... any thoughts?

Does it work if you press staging twice?

[Tokamak]

I know you probably have thought of it, but parachutes stay inside their cover until pressure is high enough. There is nothing special in their stage, so if staging works, it works. Have you tried staging parachutes at altitudes less than 5000m on Kerbin? Otherwise, I have no idea.

A reasonable thought, but I did check for that. My tests were between the launchpad and 1000m.

[zitronen]

A reasonable thought, but I did check for that. My tests were between the launchpad and 1000m.

I could not replicate this at all. Can you try it with KerbalX?

[Tokamak]

I could not replicate this at all. Can you try it with KerbalX?

I'm not quite sure what you mean.

Edit: OH, the stock rocket. I see. Sure, I will do that!

[Kerbal007]

it's easy to get serial port working on any windows version, but we don't have it. - - - Updated - - -

Zitronen can you elaborate please on what you mean when you state " we don't have it " ? I have Windows 10 installed along with Visual Studio 2015 Community and a copy of the code, if its straight forward enough I'd love to have a crack at getting this working but I am somewhat ignorant in understanding the issue entirely.

Cheers!

[bork_bork]

Hey folks - I'm using the mac version of the library and arduino code. I've been having quite a bit of trouble with the serial ports. I've been watching the number of good decoded packets, vs the number discarded. The number of discarded packets is 5x higher than the number decoded. It looks like I'm only getting about 1 good packet per second.

Using serial ports at 115200 on a ATMEGA 2560. Has anyone run into similar issue?

[stibbons]

That sounds very similar to my experience on OS X. But my Mac machine is a 2013 Air with the slowest CPU - I turn all of the graphics settings way down and the Kerbal X still lags sitting on the launch pad. I just assumed it was too slow to play and went back to the slightly longer development cycle on my gaming rig.

I did find that decreasing the serial port speed to 57600 helped with the dropped packet count some. Could be worth experimenting with the speed to see if that helps for you.

I think that your root problem is explained by this section of the cross-platform plugin's README:

Due to issues with .NET and Unity regarding Event callbacks, this version updates the Arduino via MonoBehavious->Update() which runs at about your screens refresh rate. Therefore please run your arduino at a hight speed like 115200 to avoid dragging down your system.

That means your arduino is being hammered with 60 packets a second, whereas the default config file in current versions of the plugin sends 5 packets a second. When I get some time this week I'll dive back in to the plugin code and see if I can add a multiplier to the callback so it only sends every x refreshes. But apart from that I'm not sure if there's much else that can be done. :/

[bork_bork]

Hi Stibbons - I played with the refresh value in the config.xml. By changing it down to 50hz (0.02), I've got a nice responsive system now. I think it was sending at over 100hz by default.

[stibbons]

Oh wait that's actually in the config file now? Nice. Thanks for the heads-up. I'll have to get Linux up and running on my gaming PC again and give it a try.

[bork_bork]

I'm considering rejiggering the serial packets to only send data that has changed, to see if I can get it up to 60HZ.