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

[cm2227]

This time I have a serious suggestion for improvement, which imho should find its way to your main release. You know I've been working on setups where more than one arduino is involved, which requires one unit to handle the serial communication with KSPSerialIO and the distribution to the other Arduinos. What puzzles me is that you developed a cool architecture with the three packet types, but then give the vessel data and the control packet the same id. For exchange of information it would be easier to have the id byte distinguish between CPacket and VData.

[NeoMorph]

Regarding Arduino performance, have you guys heard of the new Arduino Zero? Totally geeking out here... (does the Homer Simpson Douuuuuuuuugghnuts sound... but saying "Zeeeeeeeeeeeeeero" instead).

http://arduino.cc/en/Main/ArduinoBoardZero

I've been looking at using a Chipkit Max32 which is a Arduino based form factor (see below) which runs on a Pic SPU instead of an Atmel. But now I'm thinking of waiting until the Zero comes out.

So what am I doing that is taking so much space? My darn DSKY/AGC, that's what! I really need to see if I can pare my code down.

[zitronen]

This time I have a serious suggestion for improvement, which imho should find its way to your main release. You know I've been working on setups where more than one arduino is involved, which requires one unit to handle the serial communication with KSPSerialIO and the distribution to the other Arduinos. What puzzles me is that you developed a cool architecture with the three packet types, but then give the vessel data and the control packet the same id. For exchange of information it would be easier to have the id byte distinguish between CPacket and VData.

All right, this weekend I will look into:

1. Improving handshake, so it will actually check the returned packet and not be fooled by a loop back device

2. Change the packet IDs, I think the packets sent from the plugin will have ID starting from 1 and packets sent to the plugin will have ID starting from 101

These will mostly benefit people trying to connect multiple boards.

Regarding Arduino performance, have you guys heard of the new Arduino Zero? Totally geeking out here... (does the Homer Simpson Douuuuuuuuugghnuts sound... but saying "Zeeeeeeeeeeeeeero" instead).

http://arduino.cc/en/uploads/Main/Arduino_Zero_front450.png

http://arduino.cc/en/Main/ArduinoBoardZero

I've been looking at using a Chipkit Max32 which is a Arduino based form factor (see below) which runs on a Pic SPU instead of an Atmel. But now I'm thinking of waiting until the Zero comes out.

https://digilentinc.com/Data/Products/CHIPKIT-MAX32/chipKIT-Max32-obl-500.jpg

So what am I doing that is taking so much space? My darn DSKY/AGC, that's what! I really need to see if I can pare my code down.

I've have had enough with these stupid names on my f*** arduino!

[cm2227]

All right, this weekend I will look into:

1. Improving handshake, so it will actually check the returned packet and not be fooled by a loop back device

2. Change the packet IDs, I think the packets sent from the plugin will have ID starting from 1 and packets sent to the plugin will have ID starting from 101

These will mostly benefit people trying to connect multiple boards.

Sounds great!

I've have had enough with these stupid names on my f*** arduino!

I just read this in Samuel L. Jackson voice.

[zitronen]

Not so weekly "Weekly" update 11

Changed:

1. Improving handshake, so it will actually check the returned packet code (Byte 1 = 3, Byte 2 = 1, Byte 3 = 4)

2. Change the packet IDs, packets sent from the plugin will have ID starting from 1 (Vessel data) and packets sent to the plugin will have ID starting from 101 (Control Packet)

In the future, I may add options in the settings file so you can change the IDs to what you want, but I don't see any need for now...

No need to update if you are not having issues or not trying to connect multiple displays.

Plugin:

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

Arduino Code

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

[Mulbin]

Wow, just checking in to the forums (new baby so not much free time at the moment!), progress is looking awesome! Will hopefully have a go with the new version soon...

[lmarr28]

Can anyone help me map a latching button/switch to the 'Map' function? I'm assuming this is available since it's called out in the comments of the ControlPacket struct (see below: byte Mode) in KSPIODemo6. However, I can't find a reference to "Mode" anywhere else - unless I'm just missing it...

struct ControlPacket {
  byte id;
  byte MainControls;                  //SAS RCS Lights Gear Brakes Precision Abort Stage 
  byte Mode;                          //0 = stage, 1 = docking, 2 = map
  unsigned int ControlGroup;          //control groups 1-10 in 2 bytes
  byte AdditionalControlByte1;        //other stuff
  byte AdditionalControlByte2;
};

[zitronen]

Unfortunately switch to map is not implemented yet...

[lmarr28]

Unfortunately switch to map is not implemented yet...

No worries. Thanks for all of your hard work on this plugin! I love it!

[Diazo]

Okay.

Way back when I started my Action Groups Extended mod, one of the goals was to interface with this to allow sim pits with lots and lots of switches.

I have AGX stable at this point and I am at a point where I'm ready to look at integrating with this mod.

The problem is I don't have an arduino myself to test and I have no clue how one works.

Looking at the plugin source code, it looks like the control groups are a 16 bit integer of which 10 bits are used, one for each control group. This integer is then sent every update from the arduino to the PC and if the integer changes, that triggers that control to action.

Using this method on my AGX mod would require 16 of these integers to support the full 250 groups (16 integers times 16 bits is 256 bits total). The current total packet control size is 21 bytes, so extending the current method to 16 integers for the control groups would take a control packet to 51 bytes. I don't know serial communications at all, would this be a problem?

If this method is possible, it would be straightforward for me to put together a pull request for your review, there are actually not that many changes to the code on the plug-in end. However, I have no clue what this would entail on the arduino's physical end to get it to recognize more then the ten groups is currently does.

And this is assuming one arduino can do this. For that many groups would we be looking at multiple arduinos? (Looking at the website, it looks like it's typically 14 or 15 digital inputs per board?)

That brings me to my question about an alternate method. Rather then the state of each control group being sent each update, is it possible to send a packet on state change? So when group 43 it sends a data packet of {bool} Activate/Deactivate and {ushort} ActionGroup Number?

Thoughts from people who have actually used the arduino on this?

D.

[Freshmeat]

Problem: I would like to use the fuel per stage to stay in map view during ascent. However, it does not work on rockets with asperagus staging, as the game reports fuel available to any active engine. When your outer rockets burn out you will not see this in the fuel gauge.

Workaround: I plan to check for change in acceleration occuring without change in thrust. This will give some problems with RCS, but better than nothing.

Request: Is it possible to check for active engines not producing thrust?

[zitronen]

Okay.

Way back when I started my Action Groups Extended mod, one of the goals was to interface with this to allow sim pits with lots and lots of switches.

I have AGX stable at this point and I am at a point where I'm ready to look at integrating with this mod.

The problem is I don't have an arduino myself to test and I have no clue how one works.

Looking at the plugin source code, it looks like the control groups are a 16 bit integer of which 10 bits are used, one for each control group. This integer is then sent every update from the arduino to the PC and if the integer changes, that triggers that control to action.

Using this method on my AGX mod would require 16 of these integers to support the full 250 groups (16 integers times 16 bits is 256 bits total). The current total packet control size is 21 bytes, so extending the current method to 16 integers for the control groups would take a control packet to 51 bytes. I don't know serial communications at all, would this be a problem?

If this method is possible, it would be straightforward for me to put together a pull request for your review, there are actually not that many changes to the code on the plug-in end. However, I have no clue what this would entail on the arduino's physical end to get it to recognize more then the ten groups is currently does.

And this is assuming one arduino can do this. For that many groups would we be looking at multiple arduinos? (Looking at the website, it looks like it's typically 14 or 15 digital inputs per board?)

That brings me to my question about an alternate method. Rather then the state of each control group being sent each update, is it possible to send a packet on state change? So when group 43 it sends a data packet of {bool} Activate/Deactivate and {ushort} ActionGroup Number?

Thoughts from people who have actually used the arduino on this?

D.

The Mega has many more inputs, and you can use io expander chips that will give you basically unlimited number of inputs.

I think realistically no one will need physical 250 control switch/buttons! That would be nuts, imagine drilling 250 holes, soldering all the wires and testing they all work! I think 64 should be more than enough for anybody . Either way 51 bytes is not a problem at all. 51 bytes will only take ~10mS to send at 38400 BAUD, and that can easily be tripled to 115200. Since the arduino can't do 64 bit stuff, it will be best to use a couple 32bit uint variables in the control packet.

Problem: I would like to use the fuel per stage to stay in map view during ascent. However, it does not work on rockets with asperagus staging, as the game reports fuel available to any active engine. When your outer rockets burn out you will not see this in the fuel gauge.

Workaround: I plan to check for change in acceleration occuring without change in thrust. This will give some problems with RCS, but better than nothing.

Request: Is it possible to check for active engines not producing thrust?

Hmm... assuming it's possible (I donno, the engine list thing I stole from KOS), would you want a number representing the number of active engines out of fuel?

[Diazo]

The Mega has many more inputs, and you can use io expander chips that will give you basically unlimited number of inputs.

I think realistically no one will need physical 250 control switch/buttons! That would be nuts, imagine drilling 250 holes, soldering all the wires and testing they all work! I think 64 should be more than enough for anybody . Either way 51 bytes is not a problem at all. 51 bytes will only take ~10mS to send at 38400 BAUD, and that can easily be tripled to 115200. Since the arduino can't do 64 bit stuff, it will be best to use a couple 32bit uint variables in the control packet.

Alright, if 51byte messages are not a problem, I'll go with 8 uint's for the control stuff.

One thing I am going to do is because I have so many groups, I'm going to provide 2 styles of control:

Groups 1-125 ( 4 uints): Control as currently exists, send KSP GroupActivate on state change to 1 and GroupDeactivate on state change to 0.

Groups 126-250 (4 units): Activate control only. Send KSP GroupActivate on state change to 1 but do nothing on state change to 0. This is to support things like a pushbutton or a toggle switch.

Pushbutton: Send GroupActivate on pressing the button (state change to 1) but send nothing on button release (state change to 0)

Toggle Switch: Send GroupActivate(Group126) on flipping the switch up, send GroupActivate(Group127) on flipping the switch down.

I'll pull a github fork on the weekend so you can see exactly how I'm thinking to implement this. The arduino end is still a question mark though. I'll download the software and see if I can make something work without actually having an arduino to connect.

D.

Edited June 20, 2014 by Diazo
Math Failure

[Freshmeat]

Hmm... assuming it's possible (I donno, the engine list thing I stole from KOS), would you want a number representing the number of active engines out of fuel?

Thanks for the reply. I just need to know if any engine is out of fuel, but others might appreciate the number.

After some testing, I have designed the circuits and the actual physical design is taking form. I have no access to print boards, so nails, wire and chipboard it is. Will show pictures when I have something to show.

[KvickFlygarn87]

Would it be possible for me to see the source of that LCD? I'm quite clueless as to how I would print stuff to the arduino

[zitronen]

My LCD code is a huge mess, I would suggest you look at the tutorial here: http://arduino.cc/en/Tutorial/LiquidCrystal

[KvickFlygarn87]

My LCD code is a huge mess, I would suggest you look at the tutorial here: http://arduino.cc/en/Tutorial/LiquidCrystal

But how do I get data from KSP?

[Diazo]

But how do I get data from KSP?

That's where the communication module on the first page comes in.

Souce code for Arduino 4: Input Axes

In your Arduino program, you will have to combine the two so that a variable is set from KSP via the serial communications and then display that variable on the LCD.

So for altitude, find that variable in the KSPIODemo6 program and then append the LCD code with a

lcd.print(AltitudeFromKsp);

I hope that will be enough to get you started, I don't have an arduino myself to test and be anymore detailed with.

D.

[KvickFlygarn87]

That's where the communication module on the first page comes in.

Souce code for Arduino 4: Input Axes

In your Arduino program, you will have to combine the two so that a variable is set from KSP via the serial communications and then display that variable on the LCD.

So for altitude, find that variable in the KSPIODemo6 program and then append the LCD code with a

lcd.print(AltitudeFromKsp);

I hope that will be enough to get you started, I don't have an arduino myself to test and be anymore detailed with.

D.

Thanks a lot, Diazo!

[Freshmeat]

I will not go into space today........

My build was going along fairly nicely, and most of the coding was done when I discovered a fatal hardware weakness:

To increase my amount of switches, I ran groups of four through different resistors in parallel, reading the results on the analog pins. However, when I throw a switch, the increase in drawn current is enough to disturb the reading on the other pins. As it stands, most of the basic functions will work without fail, but the advanced ones disturb one another. While this is pretty kerbal, I would like my stuff to work every time. I guess it is time to look into pin extender chips.

Thought: Will it help to scale the resistors up? The ones I am using is in the 100-1k range, and could be changed by one or two orders of magnitude once I get new ones.

Edited June 28, 2014 by Freshmeat

[Diazo]

The other analog pins are seeing their readings change when you toggle one of the 4 switches on the first pin?

That sounds odd, what's the setup you have? (Mainly, what's the part number of the analog pins sensor? Or board they came mounted on.)

D.

[zitronen]

I will not go into space today........

My build was going along fairly nicely, and most of the coding was done when I discovered a fatal hardware weakness:

To increase my amount of switches, I ran groups of four through different resistors in parallel, reading the results on the analog pins. However, when I throw a switch, the increase in drawn current is enough to disturb the reading on the other pins. As it stands, most of the basic functions will work without fail, but the advanced ones disturb one another. While this is pretty kerbal, I would like my stuff to work every time. I guess it is time to look into pin extender chips.

Thought: Will it help to scale the resistors up? The ones I am using is in the 100-1k range, and could be changed by one or two orders of magnitude once I get new ones.

Huh? Did you wire it up correctly? Can you show the schematics? I can't see how a 1k resister will change the power supply voltage by much... I am doing some thing similar, I'm using 1k - 8.2k resistors. You may also need to check for switch bounce and wait a bit for the voltage to stabilise.

[Freshmeat]

It is not the 1k resistor, it is having a bunch of them in parallel. I had 3 circuits going as low as 330 ohm each in parallel -> 100 ohm effective resistance I ought to have seen that one from a mile away.

I changed the resistors this morning, going from 100-670 ohm to 3300-15000 ohm, and added a 330 ohm more between the leds drawn directly from +5V. Now the resistance behaves properly, and I can continue debugging my software.

Edited June 29, 2014 by Freshmeat

[zitronen]

All right that makes more sense.

[Freshmeat]

So, I made progress:

http://forum.kerbalspaceprogram.com/threads/84672-My-homebuild-controller-for-KSP-%28Picture-heavy%29?p=1242766#post1242766

Thanks for all the help, I'll come running back when I have money to spend on a display unit.