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

[CommanderMAM]

7 minutes ago, zitronen said:

Update 0.19.3b:

Changes:

• Ok so not sure when this happened, but it seems you no longer have to disable SAS to update vessel controls, so the annoy issue of having to disable SAS to move an axis is gone (the whole business with SASTol no longer an issue, it now doesn't do anything). Now the axis control behaves like normal joystick input. I didn't do anything apart from remove the check and doing some testing. Please let me know if this is actually fixed, that would be great! Thanks to @c4ooo for letting me know.
• Also recompiled against 1.10.1

Plugin download link:

https://sites.google.com/site/zitronfiles/KSPSerialIO_019_3b.zip

Arduino code dowload (same as before):

https://sites.google.com/site/zitronfiles/KSPIODemo17.zip

Is the download link supposed to only contain the config file? Seems identical to the one I have already...

[zitronen]

1 minute ago, CommanderMAM said:

Is the download link supposed to only contain the config file? Seems identical to the one I have already...

Oops, try it now.

[CommanderMAM]

Initial tests seem to confirm it is indeed working. Thanks for fixing this zitronen!

Edited November 8, 2020 by CommanderMAM

[gt3073b]

Thank you all for your help and for the great plugin. I haven't played enough to know if I would miss that orbital data, it sounds like I won't. Thanks again!

[geeksmithing]

Please forgive my ignorance here (new KSPSerialIO user as of today).... I am just trying out this plugin with a single button toggling SAS on and off to learn how stuff works, and the throttle is stuck at 20% before I hit anything on the keyboard, and all throttle controls are unresponsive if I have the arduino plugged in.  If I restart the game/save file without it, throttle works great.   To my knowledge I have not messed with the throttle controls (or any arduino code for that matter) at all.  What did I do wrong to cause this?   Thanks a ton!

 

[zitronen]

16 hours ago, geeksmithing said:

Please forgive my ignorance here (new KSPSerialIO user as of today).... I am just trying out this plugin with a single button toggling SAS on and off to learn how stuff works, and the throttle is stuck at 20% before I hit anything on the keyboard, and all throttle controls are unresponsive if I have the arduino plugged in.  If I restart the game/save file without it, throttle works great.   To my knowledge I have not messed with the throttle controls (or any arduino code for that matter) at all.  What did I do wrong to cause this?   Thanks a ton!

 

Hi if you are using the demo code and not using the throttle on the arduino, you need to change the settings.cfg file to disable it (see first post for options).

 

[filipWithTelescope]

Awesome. Allways dreamed about this. I wish i knew how to use it

[nenico87]

Hello, is there any way to "emulate" game for arduino? like sending strings thru serial monitor and receiving it, you know, for testing things so you don't need to relaunch game and try it ingame after update to controller? 

[Jimbofarrar]

6 hours ago, nenico87 said:

Hello, is there any way to "emulate" game for arduino? like sending strings thru serial monitor and receiving it, you know, for testing things so you don't need to relaunch game and try it ingame after update to controller? 

Hello you can try this

 

[CommanderMAM]

I seem to be having an issue where the controller is taking a very long time to connect to the game once the flight has started. This started once I wired an LCD to my controller and started coding it. I'm not sure if it is a coding problem, an issue with the plugin, or possibly something to do with crossed wires, but after removing the LCD code the issue persists, and I am in the process of rewiring part of my controller but so far it hasn't fixed anything. Is there some way I can upload my code other than pasting it in a post? It is mostly based off of the KSPDemo_17 code but there is a lot of additions for various other functions scattered about.

[zitronen]

On 4/1/2021 at 4:44 PM, CommanderMAM said:

I seem to be having an issue where the controller is taking a very long time to connect to the game once the flight has started. This started once I wired an LCD to my controller and started coding it. I'm not sure if it is a coding problem, an issue with the plugin, or possibly something to do with crossed wires, but after removing the LCD code the issue persists, and I am in the process of rewiring part of my controller but so far it hasn't fixed anything. Is there some way I can upload my code other than pasting it in a post? It is mostly based off of the KSPDemo_17 code but there is a lot of additions for various other functions scattered about.

Hi, apologies for the late reply, do you still need help with this? Just to confirm that the default Demo17 code works ok?

[CommanderMAM]

On 4/26/2021 at 7:40 AM, zitronen said:

Hi, apologies for the late reply, do you still need help with this? Just to confirm that the default Demo17 code works ok?

The issue is still present with my old code, but with a modified version of the demo code that just has the SAS and RCS buttons (momentary push buttons) it seems to work.

[zitronen]

You don't have anything like "delay(xxx)" in your code right? You can post which you changed here, or put it in pastbin or something if you can't figure it out yourself.

[CommanderMAM]

3 minutes ago, zitronen said:

You don't have anything like "delay(xxx)" in your code right? You can post which you changed here, or put it in pastbin or something if you can't figure it out yourself.

did a ctrl F search and the only delay it came up with was the commented out part in the Handshake tab, which is present in both my code and the demo code

 

Could the LiquidCrystal_I2C or SoftwareSerial libraries cause this?

Edited April 27, 2021 by CommanderMAM

[zitronen]

LiquidCrystal possibly, SoftwareSerial can definitely cause problems. Do you need to use another serial port? I would recommend getting a board with 2 hardware serial ports rather than using softwareserial which is not only slow but also locks up the processor when it's working, which will lead to packet loss.

[CommanderMAM]

1 minute ago, zitronen said:

LiquidCrystal possibly, SoftwareSerial can definitely cause problems. Do you need to use another serial port? I would recommend getting a board with 2 hardware serial ports rather than using softwareserial which is not only slow but also locks up the processor when it's working, which will lead to packet loss.

Hmm, I'm using a Mega, so I'm not sure I need more serial ports. Those are SDA and SCL right?

[zitronen]

SDA SCL are for i2c, the mega has like 3 hardware serial ports, pin numbers are listed here: https://www.arduino.cc/en/reference/serial>

 

[CommanderMAM]

On 4/28/2021 at 12:09 PM, zitronen said:

SDA SCL are for i2c, the mega has like 3 hardware serial ports, pin numbers are listed here: https://www.arduino.cc/en/reference/serial>

 

Ok, been messing around here's what I've figured out.

1) My LCD uses i2c and is (a 20 by 4 character display) 

2) My code works as long as all the portions involving the LCD are commented out

3) This means that the issue involves these lines of code: 

Under void setup in the main page (for the demo, the one titled Demo17, for me its titled KerbalCode):

Serial.begin(9600); //LCD Connection
  lcd.init();
  lcd.backlight();

  
  //write to LCD
  lcd.clear();
  lcd.setCursor(0,0);
  lcd.print("KerbalController");
  lcd.setCursor(0,1);
  lcd.print("booting...");

 

Under void Indicators in the utilities tab:

 //MODE 0 : TakeOff Mode
 if(digitalRead(LCDPINA) == HIGH){
    //Mode 1 Takeoff Mode
    lcd.clear();
    //Vsurf
    lcd.setCursor(0,0);
    char bufferVsurf[17];
    String strVsurf = "Vsurf: ";
    strVsurf += String(VData.Vsurf, 0);
    strVsurf += " m/s";
    strVsurf.toCharArray(bufferVsurf,17);
    lcd.print(bufferVsurf);
    //Acceleration (G)
    lcd.setCursor(0,1);
    char bufferGee[17];
    String strGee = "G-Force: ";
    strGee += String(VData.G, 0);
    strGee += " G";
    strGee.toCharArray(bufferGee,17);
    lcd.print(bufferGee);
    //Altitude from Sea Level
    lcd.setCursor(0,2);
    char bufferAtl[17];
    String strAlt = "Alt:  ";
    strAlt += String(VData.Alt, 0);
    strAlt += " m";
    strAlt.toCharArray(bufferAtl,17);
    lcd.print(bufferAtl);
  }
  if(digitalRead(LCDPINA) == LOW){
    //MODE 2: Orbit Mode
    lcd.clear();
    //VOrbit
    lcd.setCursor(0,0);
    char bufferVOrbit[17];
    String strVOrbit = "VOrbit: ";
    strVOrbit += String(VData.VOrbit, 0);
    strVOrbit += " m/s";
    strVOrbit.toCharArray(bufferVOrbit,17);
    lcd.print(bufferVOrbit);
    //Altitude from Sea Level
    lcd.setCursor(0,1);
    char bufferAtl[17];
    String strAlt = "Alt:  ";
    strAlt += String(VData.Alt, 0);
    strAlt += " m";
    //Apoapsis
    lcd.setCursor(0,2);
    char bufferAP[17];
    String strApo = "AP: ";
    if (VData.AP < 10000 && VData.AP > -10000) {
      strApo += String(VData.AP,0);
      strApo += "m ";
    } else if ((VData.AP >= 10000 && VData.AP < 10000000) || (VData.AP <= -10000 && VData.AP > -10000000)) {
      strApo += String((VData.AP / 1000),0);
      strApo += "km ";
    } else if ((VData.AP >= 10000000 && VData.AP < 10000000000) || (VData.AP <= -10000000 && VData.AP > -10000000000)) {
      strApo += String((VData.AP / 1000000),0);
      strApo += "Mm ";
    } else {
      strApo += String((VData.AP / 1000000000),0);
      strApo += "Gm ";
    }
    strApo += String(VData.TAp); //time to apoapsis
    strApo += "s";
    strApo.toCharArray(bufferAP,17);
    lcd.print(bufferAP);
    //Periapsis
    lcd.setCursor(0,3);
    char bufferPE[17];
    String strPeri = "PE: ";
    if (VData.PE < 10000 && VData.PE > -10000) {
      strPeri += String(VData.PE,0);
      strPeri += "m ";
    } else if ((VData.PE >= 10000 && VData.PE < 10000000) || (VData.PE <= -10000 && VData.PE > -10000000)) {
      strPeri += String((VData.PE / 1000.0),0);
      strPeri += "km ";
    } else if ((VData.PE >= 10000000 && VData.PE < 10000000000) || (VData.PE <= -10000000 && VData.PE > -10000000000)) {
      strPeri += String((VData.PE / 1000000.0),0);
      strPeri += "Mm ";
    } else {
      strPeri += String((VData.PE / 1000000000.0),0);
      strPeri += "Gm ";
    }
    strPeri += String(VData.TPe); //time to periapsis
    strPeri += "s";
    strPeri.toCharArray(bufferPE,17);
    lcd.print(bufferPE);
  }

 

Only other code relating to the LCD is just some basic defining stuff in the main page and the output page, and works without being commented out.

Main page:

#include <LiquidCrystal_I2C.h>

LiquidCrystal_I2C lcd(0x27,20,4);  
// set the LCD address to 0x27 for a 20 chars and 4 line display

 

Under void controlsInit in the output page:

  pinMode(LCDPINA, INPUT);

 

Not sure what could be messing things up, maybe something with the Serial connection? Any help or insight would be greatly appreciated.

Edited May 5, 2021 by CommanderMAM

[zitronen]

Any reason why you are using 9600 for serial, not faster? Default should be 38400, but use fastest speed your board supports.

lcd.clear() might be slow, if you are overwriting the display you could get rid of it. Otherwise I don't know? Have you tried just printing a simple line and see if that works?

Edited May 7, 2021 by zitronen

[CommanderMAM]

59 minutes ago, zitronen said:

Any reason why you are using 9600 for serial, not faster? Default should be 38400, but use fastest speed your board supports.

lcd.clear() might be slow, if you are overwriting the display you could get rid of it. Otherwise I don't know? Have you tried just printing a simple line and see if that works?

It prints the "Kerbal Controller booting..." message just fine, but the board doesn't communicate with the game. TX light isn't flashing like it's supposed to, and controls are unresponsive. Could the LCD's serial channel and the one communicating with the game be interfering with each other?

[zitronen]

Huh? Your LCD is is i2c based, it shouldn't use serial?

[CommanderMAM]

40 minutes ago, zitronen said:

Huh? Your LCD is is i2c based, it shouldn't use serial?

SDA stands for serial data pin, and SCL is serial clock pin, right? The couple of tutorials I used to first set this up about a year ago all started with a Serial begin command. Even if I don't have the command (say if its commented out), the issue still persists.

[zitronen]

Serial port (TTL or RS232) and i2c are not the same thing, https://www.robotshop.com/community/forum/t/serial-vs-i2c-communication/12316

Serial port (over USB) is used by the Arduino to communicate with KSP

[Freshmeat]

LCD original implementation is slow as molasses. It might time the connection out? I used a different implementation which is significantly faster, and yet I only update every 250 ms to avoid loosing connection.

[sec3]

@CommanderMAM  

1.)

don´t run the  .clear  everytime...   only once at

void setup ()

to clear the display use subvoids and " " (spaces) and overwrite at the cursor position. 
no problems running i2c/ FastLED. 

for example:

 void LiquidFuel()
      {
      lcd.print("L%"); 
      lcd.print((VData.LiquidFuel/VData.LiquidFuelTot*100),0);
      }

lcd.setCursor(0,0);
   LiquidFuel();
    lcd.print("   ");

or with the sprintf function to combine text and digits ... 

you calculate and print as you need.  it works great for missionTimer and so on in realtime. 

 

2.) increase the buffer (handshaketime) and bauds, if it doesn´t startup. 

myUsage: NewLiquidCrystal_i2c  lib   as  freshmeat told. 

 

Edited June 9, 2021 by sec3