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

[bork_bork]

Marzubus - thanks for putting together this port. I put it on my Mega2560 with a MacBookPro. I am noticing very slow refresh to my arduino and auto-detect is not working. If I set no-detect I get data to the arduino.

This is with serial running at 115200, which should be more than sufficient. Is there a method to debug the Serial Port detect handshake?

EDIT: After reading through a few previous posts, I may be hitting the 32bit struct padding issue. Has anyone else already solved that and can share code?

/bork

Hey Folks!

I have released the 0.17.1 version of the Mac / Linux / Win Port of KSPSerialIO.

Changelog:

* major cleanup and rebase

* merge with 0.17.1 upstream code

* fixed time-warp issue by migrating from MonoBehavior::Update() to MonoBehavior::FixedUpdate()

Edited March 2, 2015 by bork_bork

[marzubus]

The detection is a problem. since 0.17 for some reason. I need to figure out a solution for that. Are you using a mega or DUE or why do you ask about the 32 bit padding?

I did another build without fixedUpdate(), since I traced my warping issue to another issue. here is a patched dll: https://www.dropbox.com/s/ms985yh9qjo00zv/KSPSerialIO.dll?dl=0, can u try that? Maybe fixedUpdate was a bad idea.

Also be sure that whatever you have in your arduino's main loop is NOT taking long to execute. Are you just running the KSPSerialIO Demo 10? or have you added more to the main loop?

I was experimenting with updating OLED's from the main loop, but the 50ms delay to update the OLED made my arduino lag behind and disconnect.

Try just the Demo10 code and see if it lags on simple stuff like SAS LED and so on. Make sure to test it for at least a launch to orbit, since the lag can sneak up on you.

Edited March 2, 2015 by marzubus

[bork_bork]

I am running a driver for 7 segment displays based on the MAX7219 (MaxMatrix library). I have tested that in a tight loop and get sub 10ms update times, so I don't expect that to be a problem, but I can try disabling it and see if that improves the update rate. I'll also wire up only the simple LED for SAS and see how that goes.

Also be sure that whatever you have in your arduino's main loop is NOT taking long to execute. Are you just running the KSPSerialIO Demo 10? or have you added more to the main loop?

Try just the Demo10 code and see if it lags on simple stuff like SAS LED and so on. Make sure to test it for at least a launch to orbit, since the lag can sneak up on you.

[marzubus]

sub 10 should be OK, also remember that my port of KSP Serial IO syncs with the serial device on every frame render, so if you are doing something like 120FPS that could be the problem too.

In you config have you also set refresh? refresh should always be 1.0, if its left out of config it will default to 1.0

You can just use the SASLED = 13 to use the onboard one.

And are you on a DUE or a MEGA?

EDIT: I have fixed autodetect!!!! Wheres a party hat kerbal when you need one...

Link

Edited March 3, 2015 by marzubus

[T.A.P.O.R.]

Hi zitronen

I'm not sure if I got a corrupted DL, but I can't get the basic SAS & RCS to work in KSPIODemo10 (even from a fresh zip extract).

KSPIODemo9 works just fine though.

This is on a UNO R3

I'll test on my Leonardo when I get back from work.

[marzubus]

I had to patch my port to fix a issue with control packets . I thought it was a issue with my fork but maybe it's from upstream . See https://github.com/unixunion/KSPSerialIO/commit/a52b6be76dae893845e7776b5b857916645ea79c

Edit: comparing to upstream, it doesn't Seem to be a issue in Zitron's code. Can u test with the cross platform port because I know that works.

Edited March 3, 2015 by marzubus

[stibbons]

This evening I've uninstalled my local build of the old 0.16.1 plugin and switched to zitronen's 0.17.1. Added the new bits to my packet structs, and everything's running smoothly with my controller.

When I get some time over the weekend I'm keen to update my controller to read the new ActionGroups field in VesselData.

[zitronen]

Hi zitronen

I'm not sure if I got a corrupted DL, but I can't get the basic SAS & RCS to work in KSPIODemo10 (even from a fresh zip extract).

KSPIODemo9 works just fine though.

This is on a UNO R3

I'll test on my Leonardo when I get back from work.

Can you make sure you are running the latest version (0.17.1): http://forum.kerbalspaceprogram.com/threads/66393-Hardware-Plugin-Arduino-based-physical-display-serial-port-io-tutorial-%2817-Dec%29?p=1708617&viewfull=1#post1708617

[Nuke]

Be careful if you are going 32bit: http://forum.kerbalspaceprogram.com/threads/66393-Hardware-Plugin-Arduino-based-physical-display-serial-port-io-tutorial-%2817-Dec%29?p=1544333&viewfull=1#post1544333

It's still not clear if the code will run properly without massive changes due to struct padding.

its probibly an endianness thing. avr is big endian, intel is little endian, and arm is both. confused? you should be. ive read articles that say its dumb to worry about endianness but they are usually for coders writing only for one platform. when you shove bits down a serial line between two dissimilar architectures and expect to use the same code at both ends to convert a stream of bytes into a structure and vise versa, you are going to have problems. i usually make a union between a byte array and a structure, then use it as a class member, then add a member function to perform byteswaps on a member by member basis. then you can use the same code at both ends, calling byteswap() at one end if the endiannes is different (obviously at the end with the faster cpu). i usually have the server query the client about its endianness at the start of a session so it knows whether or not it needs to perform a byteswap.

that is of course assuming you are moving structures and not text. if you are using an at command set, then you really dont need to worry about endianness at all, but really that is going to be a slow down on 8 bit micros without a lot of memory. i did one once to configure an r/c receiver i built. i had to use every scrap of flash and some of the eeprom to store strings. it was rather tedius. i eventually replaced it with a bytecode interpreter.

Edited March 4, 2015 by Nuke

[zitronen]

its probibly an endianness thing. avr is big endian, intel is little endian, and arm is both. confused?.

It's not an endian issue, it's to do with how the compiler pads the structures for 32bit and 8bit: http://vcfaq.mvps.org/lang/11.htm

Once that's fixed (harbingerx81 had to rewrite the receive function to manually correct things) everything worked. There maybe ways around it that doesn't involve painstaking rewrites every time the struct changes, but nothing has been tested so far.

[bork_bork]

So, I did a bit more testing. I am getting massive checksum fails on packets. Only 1 out of hundreds of packets passes checksum. That explains why the display felt very 'laggy'. Now to debug why I am getting so many checksum failures. This is with KSPDemo9 running at 115200. I was unable to get KSPDemo10 to read anything from the serial port yet.

I am running an ATMega2560.

/bork

[zitronen]

So, I did a bit more testing. I am getting massive checksum fails on packets. Only 1 out of hundreds of packets passes checksum. That explains why the display felt very 'laggy'. Now to debug why I am getting so many checksum failures. This is with KSPDemo9 running at 115200. I was unable to get KSPDemo10 to read anything from the serial port yet.

I am running an ATMega2560.

/bork

Are you sending too many packets? What is your refresh rate in the config file? And can you make sure you are running the latest version (0.17.1) of the plugin?

[stibbons]

You might want to also try it with a slower speed, and worst case try with a different USB cable. I've had several arduinos arrive with cables bad enough that I couldn't talk to the board at all.

[bork_bork]

So - the answer to the checksum fails was buffer overruns. The 20ms taken to drive the display was too much. I have re-written the display driver and got it down to 3ms. No more buffer overruns and no more checksum fails! Thanks everyone for the help!

A great debugging tip to anyone out there seeing similar: Put a check at the top of KSPBoardReceiveData to see if available bytes is > 62 and light up pin 13 to show the error.

[bork_bork]

Is it possible to read the state of SAS / Brakes, etc? I would like to display current state and have button for toggle, rather than a switch. In the current code I only see inputs for SAS, etc.

[Freshmeat]

Is it possible to read the state of SAS / Brakes, etc? I would like to display current state and have button for toggle, rather than a switch. In the current code I only see inputs for SAS, etc.

As of version 17, it is. The information is in

VData.ActionGroups

It is 16 bits containing status of following actions: SAS, RCS, Light, Gear, Brakes, Abort, Custom01 - 10, Where Custom refers to action group 1-10 of the vessel.

[T.A.P.O.R.]

Can you make sure you are running the latest version (0.17.1): http://forum.kerbalspaceprogram.com/threads/66393-Hardware-Plugin-Arduino-based-physical-display-serial-port-io-tutorial-%2817-Dec%29?p=1708617&viewfull=1#post1708617

I re-downloaded KSPIODemo10 & 0.17.1 and all seems to be working.

With some PM help from AmeliaEatyaHeart I managed to get my 7 Seg LED Displays and my controls working!

Here's the fix:

Tab: KSPIODemo10

#include <LedControl.h>    

        #define    LEDClkPin   4
        #define    LEDChipSel  3  
        #define    LEDDatain   2
        //these pins were set up for an Arduino Uno, adjust as appropriate.

        LedControl lc=LedControl(LEDDatain,LEDClkPin,LEDChipSel,2);//1==num of 8x8pixel arrays in line. can be up to 8.

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

[B] LedControl lc=LedControl(LEDDatain,LEDClkPin,LEDChipSel,2); //number of displays is the last variable, will be 1-8.
 blankLEDscreens(); //initialise screen, and show display number examples.[/B]

  initLEDS();
  InitTxPackets();
  controlsInit();

  LEDSAllOff();  
}

void loop()
{  
  input();
  output();
}

Tab: Utilities

void Indicators() 
{  
[B]printNumLED(0, (long)(VData.AP), 'A', 3);//will display apoapsis, with the decimal point separating km and m.
printNumLED(1, (long)(VData.RAlt), 'B', 3);//will display Radar Alt in same format.[/B]

  caution = 0;
  warning = 0;

  caution += VData.G > GCAUTION;
  warning += VData.G > GWARN;
  caution += VData.LiquidFuelS/VData.LiquidFuelTotS*100 < FUELCAUTION;
  warning += VData.LiquidFuelS/VData.LiquidFuelTotS*100 < FUELWARN;

  if (caution != 0)
    digitalWrite(YLED,HIGH);
  else
    digitalWrite(YLED,LOW);

  if (warning != 0)
    digitalWrite(RLED,HIGH);
  else
    digitalWrite(RLED,LOW);

  digitalWrite(SASLED,ControlStatus(AGSAS));
  digitalWrite(RCSLED,ControlStatus(AGRCS));
  digitalWrite(CG1LED,ControlStatus(AGCustom01));

}

Don't forget to include AmeliaEatYaheart's LedControlFunctions tab from this sketch.

Edited March 5, 2015 by T.A.P.O.R.

[bork_bork]

Very nice, thanks guys!

[cm2227]

Hello Zitronen,

do you think it is possible to add a way of enabling or disabling control of inputs with a control packet?

<bool name="ThrottleEnable">0</bool>
<bool name="PitchEnable">0</bool>
<bool name="RollEnable">0</bool>
<bool name="YawEnable">0</bool>
<bool name="TXEnable">0</bool>
<bool name="TYEnable">0</bool>
<bool name="TZEnable">0</bool>

You could use one of the additional control bytes bit wise.

I think it would be a huge advantage for autopilot-style applications, to be able to explicitly switch control from the pilot to the arduino and back by software.

[marzubus]

Is it not enough to use modes 2 or 3 so if the value is ZERO it is ignored?

// Throttle and axis controls have the following settings:

// 0: The internal value (supplied by KSP) is always used.

// 1: The external value (read from serial packet) is always used.

// 2: If the internal value is not zero use it, otherwise use the external value.

// 3: If the external value is not zero use it, otherwise use the internal value.

Or what would be the use-case / user-story here?

Hello Zitronen,

do you think it is possible to add a way of enabling or disabling control of inputs with a control packet?

<bool name="ThrottleEnable">0</bool>
<bool name="PitchEnable">0</bool>
<bool name="RollEnable">0</bool>
<bool name="YawEnable">0</bool>
<bool name="TXEnable">0</bool>
<bool name="TYEnable">0</bool>
<bool name="TZEnable">0</bool>

You could use one of the additional control bytes bit wise.

I think it would be a huge advantage for autopilot-style applications, to be able to explicitly switch control from the pilot to the arduino and back by software.

[cm2227]

Well, that's a little embarrassing. I missed out on the update introducing the control modes. So to say, my problem is already solved! Thanks for pointing that out. Now back to soldering...

[zitronen]

All right looks like 0.17.1 is working for most people, I will update the first post soon.

Edit: ok done.

Edited March 9, 2015 by zitronen

[marzubus]

Hej Zitronen,

I have a kerbalstuff page for the Mac/Linux port now.

zitronen said:

All right looks like 0.17.1 is working for most people, I will update the first post soon.

Edit: ok done.

Edited May 19, 2021 by Snark
Link to defunct website removed by moderator

[zitronen]

Done, thanks.

[Darkblade48]

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

//pins for input

#define SASPIN 8

#define RCSPIN 9

#define CG1PIN 10

#define THROTTLEPIN 0

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

//Input enums

#define SAS 7

#define RCS 6

#define LIGHTS 5

#define GEAR 4

#define BRAKES 3

#define PRECISION 2

#define ABORT 1

#define STAGE 0

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...)