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

[Benji]

What happens:

A ship on the launch pad. The LEDs initialize. Getting a handshake. Being connected for about 0.25 seconds. After that the green LED turns off.

The plugin tells me: Starting serial port COM4.

 

I use an Arduino Mega2560 R3.

And a Poti on analog0. The value that is set, when a connection seems so be active, stays and can't be overwritten with keyboard controls.

 

___________________

RX is blinking...

Edited February 7, 2016 by Benji
Performed the simple LED Test.

[zitronen]

You need to post the debug log, and tell me which version of the plugin and arduino code you are using.

[Benji]

6 hours ago, zitronen said:

You need to post the debug log, and tell me which version of the plugin and arduino code you are using.

I thought I downloaded 0.17.4, the latest version, but the log notifies 0.17.3 . Downloaded from kerbalstuff.

 

Log and all the infos:

https://www.dropbox.com/sh/m3zwmryesrm00i1/AABp2YdyyxD7y0O7p5_9NIJ9a?dl=0

 

 

Thanks a lot.

[zitronen]

Uh looks like you are using demo 13? You need demo 12 if you are using 17.3, see the first post. Demo 13 is for 17.4 - 17.6 If you want to use the latest plugin versions

[Benji]

On 7.2.2016 at 4:45 PM, zitronen said:

6 hours ago, zitronen said:

Uh looks like you are using demo 13? You need demo 12 if you are using 17.3, see the first post. Demo 13 is for 17.4 - 17.6 If you want to use the latest plugin versions

You need to post the debug log, and tell me which version of the plugin and arduino code you are using.

 

Thanks, found 17.6 - Connection is established on Scene Change but the arduino doesn't seem to receive data. After whatever IDLETIMER I define, status switches back to not connected. Sometimes in midflight the connection is reestablished, but breaks up again after IDLETIMER.

The log in the same spot:

 

https://www.dropbox.com/sh/m3zwmryesrm00i1/AABp2YdyyxD7y0O7p5_9NIJ9a?dl=0

 

(Tried Demo12 with 17.3 => similar results)

[zitronen]

That's weird. Also it seems like you craft explodes 1 second after launch?

If you are not using any other mods and is running the demo arduino code the only thing I can think of is trying to increase the serial receive buffer in HardwareSerial.h in your arduino install. Maybe try different baud rates too.

[Benji]

3 hours ago, zitronen said:

That's weird. Also it seems like you craft explodes 1 second after launch?

If you are not using any other mods and is running the demo arduino code the only thing I can think of is trying to increase the serial receive buffer in HardwareSerial.h in your arduino install. Maybe try different baud rates too.

No. I just staged all the boosters and let the shuttle glide for a time.

I will try some combinations.

[Benji]

On 9.2.2016 at 7:24 PM, Benji said:

I will try some combinations.

Sad times. Whatever combinations I try, the "stuttering" remains. I'll update to Win10, hoping for some magic.

[zitronen]

Have you tried increasing the serial buffer?

Also people using win 10 have reported the plugin does not work for some reason, we have not figured out why yet.

[Benji]

Ya, I tried the serial buffer. The stutttering was more like a stuttering. More frequent. But remained, for whatever values I tried.

I'm aware of the Win10 issue, but since it didn't work so far, I hardly care, just wait and see what the future brings. Perhaps some Win10 support some day.

Thanks for your help and for the lovely mod (in theory).

[zitronen]

OK... When you say it's stuttering, what is stuttering? The LEDs? Can you describe exactly what happens when the connections starts? What happens to the green, tx, and rx LEDs?

I don't know how good you are at writing code, but you can add some debug stuff in the arduino code to see what is happening.

 

Edit: which arduino do you have? If you have a cheap one you might be having the #ftdigate problem maybe??

Edited February 14, 2016 by zitronen

[Benji]

That's what happens:

1. Scene change to Launch Pad

2. Handshake, Connected

3. Physical calculations start

4. Not Connected (RX blinks like hell)

5. After some time, sometimes 10 seconds, sometimes 25 seconds Connected again. But for the <idletimer> only.

Then 4. again, 5., 4., ...

 

With higher buffers the "not connected"-times are a bit shorter.

I'm using the original Arduino Mega 2560 R3. I have two of them and a few unos, for some other little projects. Also tried the other 2560, but it gives the same result.

 

Perhaps I will try some debugging. I studied informatics for about 3 or 4 semesters, but I try to stay away from night long coding, etc... I liked the theoretical aspects but got bored by the actual programming. That's why I quite. So, I'm not sure how much energy I want to invest, sorry.

[zitronen]

When you say not connected, how do you know? Do you have the LEDs connected to pins 11 12 13? What do they do?

rx blinking is correct, it should blink like 4-5 time a second, it means KSP is sending data and arduino is getting it. tx light should be blinking very fast so it looks like it's on solid.

[Benji]

I have a LCDisplay to display some information. The boolean Connected is one of them.

TX isn't blinking at all. If I want to display flight data, like VData.VOrbit, it's just showing the value at which the game was when the boolean Conected = true.

RX blinking 4-5 times a second sounds about right.

[zitronen]

Well it's probably a problem with your LCD code slowing things down. This is why you MUST test with the default code with the LEDs first. It's impossible to debug if you don't post your code.

[Benji]

There's the code: https://www.dropbox.com/sh/m3zwmryesrm00i1/AABp2YdyyxD7y0O7p5_9NIJ9a?dl=0

The LCD is very simple to code, but as always the logic behind is very likely to be complicated and slow.

I don't have any timing issues with other projects, but I'm not sending this much data there and back.

[zitronen]

Oh you are using a graphic LCD, no wonder it can't keep up. Try commenting out

    myGLCD.setColor(0, 255, 0);
    myGLCD.print("     CONNECTED", 478, 98, 90);


    myGLCD.printNumF(VData.Alt, 2, 200, 100);
    myGLCD.printNumF(VData.VOrbit, 2, 200, 130);

And just have it turn on and off an LED instead.

You can try to reduce the work load by reducing the refresh rate in the plugin config file in plugindata folder. Change "refresh" to 1.0 second instead of 0.08. You can also try to find a faster GLCD library, but I don't know which is best.

[Mattew]

Seem like lots of ppl having trouble with conection and random disconects. I had same problems, but I figured out what was wrong. At first time I take Mega + GLCD, put it all togather write some code, all good until actual game start. Plugin had problems to connect, sometime it did, sometimes only few handshakes and nothing. Sometimes I got random disconnects and recconects between Arduino and KSP, like controls went out in middle of ascend, then was okay minute later. Tx blink, RX off with random blinks and so on. Tried different ports, buffer setting, serial speeds, no luck. After some time i figured out problem. It was "The Code". As Zitronen said, your code probably is too slow and arduino and kps get "desynchonized" and missmatch pakets of data.  Graphic LCD, LCD, TFT displays and so on,  is too much time consuming. Solution: Get rid of your LCDs or change code. It realy depends on where you put your code in original demo code. I recomend start by 3 leds, test it, then add display, test it. that is how i made it work. Now I have 4x20 LCD + LEDS + 6 Nixie Tubes driven by Atmega328 comunicate by serial with Mega. All works nice and well. Working on actual controls now.

Hope it helps somebody  

[zitronen]

^^ Yes.

What happens is if your LCD code takes too long, the serial code does not have enough time to read the incoming packets, the serial packets fill up the serial buffer waiting to be read. When the buffer is full (which doesn't take very long), all new packets have no where to go. If you really want to use GLCDs, you can try reducing the rate data is sent, see if you can find a faster library, or use another arduino as the "dedicated graphics card".

[mtpatane]

Hello!

Mechanical engineer here. I have a pretty awesome idea for a design of a control panel that I'm working in Autodesk Fusion 360 I'm in the process of teaching myself how to work and arduino and breadboard some some switches and LEDs.

 

the code though is foreign to me so I was so happy to stumble across this mod.  Only problem is that I only have a windows 10 computer.

any chance to root-cause the Windows 10 problem here? I'd love to bring my design to life!

Thanks! 

 

[zitronen]

Cool, I'm mech eng as well. The problem is the windows 10 version cannot receive any data from the arduino. Unity does not have a serial port library, we are using an external library that is incomplete and very old. There the latest version of the plugin (0.17.6) has a config setting to only send data to arduino, so you can try that, and use an arduino based USB HID for control and switches.

The main problem with windows 10 is I don't even have it to test things, and currently not planning to. I might look into getting data out through UDP and use an external program for UDP to serial.

[Keith Young]

Can you share your panel design? I'm about to start working on my own as well.

[mtpatane]

4 hours ago, zitronen said:

Cool, I'm mech eng as well. The problem is the windows 10 version cannot receive any data from the arduino. Unity does not have a serial port library, we are using an external library that is incomplete and very old. There the latest version of the plugin (0.17.6) has a config setting to only send data to arduino, so you can try that, and use an arduino based USB HID for control and switches.

The main problem with windows 10 is I don't even have it to test things, and currently not planning to. I might look into getting data out through UDP and use an external program for UDP to serial.

Awesome. Ok. So I think I have a plan then. 

So the from KSP to Arduino connection still works?

If I can use the old version to receive data from the game then I'll use that with 1 arduino to run displays, status LEDs etc. 

then using another 32bit based arduino I'll run the keyboard and mouse control library. Where I'll basically have a large switchboard actuated keyboard. 

I'm thinking of using a few of the analog ports for two, two axis joysticks, of which I'll break the plane into 8 slices to actuate wasd, and their associated 2 button combinations, and then one for RCS and maybe a 1 axis stick for roll  

use a 10 position rotary switch and series resistors with notes to make an analog port measure the voltage and hit the key based on which action group I have picked in the rotary switch 

1 axis spring "return to zero" switch for throttle up and down  

then a bunch of regular switches for the rest of the toggles

am I missing anything?

 

[richfiles]

On February 21, 2016 at 7:16 PM, zitronen said:

What happens is if your LCD code takes too long, the serial code does not have enough time to read the incoming packets, the serial packets fill up the serial buffer waiting to be read. When the buffer is full (which doesn't take very long), all new packets have no where to go. If you really want to use GLCDs, you can try reducing the rate data is sent, see if you can find a faster library, or use another arduino as the "dedicated graphics card".

I am incredibly new to programming on anything beyond a Commodore!  As such, I have already been planning to simplify my code, by splitting tasks to dedicated Arduinos. I plan to have a Mega serve as my primary I/O unit. It'll send necessary data via serial to other Arduinos, as well as monitor the toggles and the joysticks, and directly communicate that data back to the USB port to the computer. Basically, it'll only do things it can send quickly over serial, or do rapid reads or writes. No significant processing of any kind will happen on board, save for states and communication. I may also have it handle my analog meters, as I only need to set PWM values as "analog" outs.

My FDAI (navball) and my LED displays will each have their own arduino dedicated to rendering the necessary outputs. Since the LED segment display drivers need you to break down numbers into each separate digit (how annoying), I'll have another arduino (probably a Pro Mini) handle that, and maybe an annunciator panel. Some of the Simple on/off LED enunciators may get handled by the main Arduino Mega. The FDAI will have its own dedicated Mega or possibly a Teensy 3.1 (not sure if the smaller Arduinos will have the memory, and I still don't know if the Mega is even fast enough to do all the trigonometry). I have to generate 9 attenuation values and polarity states to control 9 analog switches, and 9 multiplying DACs, based on angular deviation from 0° at both 120° and 240° from the yaw, pitch and roll angles of the vessel. It'll likely be a lookup table of values. Those states and values will shape a reference 400 Hz sine wave to emulate the functionality of a synchro, of which I need to emulate three, to drive my FDAI hardware.

I am already looking at no less than three microcontrollers on my build. I may use a tiny 3.5 inch diagonal color CRT with a Raspberry Pi, someday, to generate some manner of cosmetic display. Maybe have little "GIF" like animations of KSC staff "communicating" with the vessel, IVA views, that sort of thing. The only thing it might actually DO, control wise, would be to emulate a keyboard and press whatever hot key I have set for Chatterer, so i set "coms sounds" when it "does" things. It won't actually "do" anything but look nifty. Waiting to snag one of those Raspberry Pi Zero units, since they are dirt cheap and you can connect a composite low res NTSC monitor to them. 

[zitronen]

All of those things are possible, and people have done it. My advice is to start simple first, before planning out super complicated systems.