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

[stibbons]

It does not. The way this plugin receives data uses serial event handlers that only seem to function properly in win32.

I've got a KSPSerialIO fork that replaces the serial handling, and does work on Linux (and MacOS). I haven't been maintaining it much recently, and it's one or two releases out of date. Can get a new build uploaded if there's interest, though.

[stibbons]

On 26/02/2017 at 10:12 PM, stibbons said:

Can get a new build uploaded if there's interest, though.

 

Sorry for the delay, but I've just updated my cross-platform fork for the latest plugin / KSP release. Note that I've built it and tested that the demo sketch in KSPIODemo16 successfully handshakes on my Mac. Haven't done any further testing than that, but also have no reason to believe the rest won't work.

 

If you're interested in trying out KSPSerialIO on MacOS or Linux, you can get it from SpaceDock: https://spacedock.info/mod/850/KSP Serial IO (cross platform)

(ping @Denko666, who was interested in this last week)

Edited March 4, 2017 by stibbons

[c4ooo]

So, i have finally learned how to dock, with the power of locked screen mode. Since i am currently away from my hardware and cant test, could someone tell me how RCS behaves with the plugin? Is it relative to the orientation of the craft (like locked screen mode) or is it relative to the surface of kerbin? (Like all other screen modes). I think having a switch to toggle between absolute and relative RCS mode would be useful, could i accomplish relative RCS mode with something like:

rcs_x' = rcs_x*cos roll - rcs_y*sin(roll) 
rcs_y' = rcs_x*sin roll + rcs_y*cos(roll) 

or am i misunderstanding how this works?

[stibbons]

2 hours ago, c4ooo said:

 Is it relative to the orientation of the craft (like locked screen mode) or is it relative to the surface of kerbin? (Like all other screen modes).

The plugin doesn't make any changes to how RCS inputs are interpreted. RCS 'up' always translates to craft up. RCS 'foward' always translates to craft prograde. This is regardless of the camera mode. I've never known RCS function to change with the camera view, either with this plugin or without. 

The only benefit you should be getting from the fixed view is that your craft stays in the same place relative to the camera, so the RCS axes stay fixed from your perspective. 

 

2 hours ago, c4ooo said:

could i accomplish relative RCS mode with something like:

rcs_x' = rcs_x*cos roll - rcs_y*sin(roll) 
rcs_y' = rcs_x*sin roll + rcs_y*cos(roll) 

or am i misunderstanding how this works?

This will get you some of the way towards RCS being relative to the centre of mass you're orbiting. But you also need to account for the Z axis. Sorry, it's way too early here for me to get my head around the maths. 

Edited March 5, 2017 by stibbons

[c4ooo]

Huh, you're right, camera mode doesn't affect how RCS works. (It is *always* relative to the craft).

What's confusing though, is that sometimes I/K move the target_prograde vector up/down (respectively) and othertimes down/up (respectively)  (when facing target vecotr).

Edited March 5, 2017 by c4ooo

[zitronen]

Are you sure you are looking at target prograde and not target retrograde?

[c4ooo]

 

On 3/6/2017 at 4:14 PM, zitronen said:

Are you sure you are looking at target prograde and not target retrograde?

Heh, that must be it 

[stibbons]

This evening I spent some time testing KSPSerialIO with some of my growing collection of microcontrollers on my Windows 10 install. There's been reports that it functions properly on 3rd-party Arduino compatible boards that use the ch340g chip for the serial interface, so I thought it'd be worth confirming that and seeing what else I have that would be compatible.

The setup I'm using:

• Windows 10 Home (fully up to date)
• KSP 1.2.2, no other mods installed. I tested both 32 and 64 bit binaries.
• KSPSerialIO 0.18.6.
• The KSPIODemo16 test sketch @zitronen wrote.

To test, I just ran the game and loaded the Kerbal X sitting on the launch pad. Confirmed that the game reported it had opened the appropriate serial port on screen, and the KSP.log file logged that it had sent and received handshake packets. I didn't attach any other hardware to my microcontrollers. But the handshaking demonstrates successful serial comms in both directions - I'd be very surprised if any of the other code is affected here.

So far I can report:

• A Teensy 3.2 works properly. Flashed it with the newest release of the Teensyduino package, only thing to worry about is ensuring the "USB Type" in the Tools menu is set to "Serial". This ensures the Teensy is set up with the USB Serial descriptor. I'd never used this board on my Windows box before, so it came up as an unknown device and I let Windows 10 download and install its own drivers.
• An Arduino Pro Mini (specifically, the 5V/16MHz board from SparkFun), with an FTDI cable. This setup also worked fine. My cable is specifically an FTL-232R-5V, but any FT232-based device should be fine (and probably any of the FTDI serial chips, but don't blame me if that's wrong). Again, I plugged it in and let Windows 10 download and install its preferred drivers.

I don't yet have a CH340G serial breakout, but will be able to test that some time this week. The next time I set this up I'll also plug in a Leonardo-compatible board and see if it has any success.

(Do not expect any of these to work with my cross-platform KSPSerialIO fork on Windows yet, though. Also, weirdly, the Teensy didn't work for me on OSX at all, but both of these did run with my fork on Linux.)

[zitronen]

Huh... you can receive the controls packet as well? Maybe fake some button or axis movement in the sketch just to be sure. But I guess if it receives the handshake then it should work. 

Does this mean the problem is limited to the uno's with their atmega based USB thingie?

 

[happytor]

Hello

I just found this plugin and I would love to use it but I am very new to arduino in general and Im not sure how to use this at all. Are there tutorials written anywhere? Thanks for making this plugin... looks very interesting

 

edit: I cant get my arduino to do anything, I load up the plugin on KSP and the arduino and the LEDs do not light up like it said they would in the tiny tutorial. Is there any other documentation??

Edited March 22, 2017 by happytor

[stibbons]

10 hours ago, happytor said:

edit: I cant get my arduino to do anything, I load up the plugin on KSP and the arduino and the LEDs do not light up like it said they would in the tiny tutorial. Is there any other documentation??

Could you give some more details about your setup? What operating system are you using? What sort of Arduino? Which version of the plugin and demo sketch? Does the plugin log anything interesting in the KSP debug log? What does the plugin log to the screen when you first load the flight scene? 

Sorry, but to the best of my knowledge there's no decent docs for using this plugin apart from what you can gather from this thread. But I'd love to be proven wrong! 

[zitronen]

Someone mentioned making a video tutorial. Can't remember who or if it happened. If someone want to make one I'll put it on the first page.

[Sputnix]

16 hours ago, zitronen said:

Someone mentioned making a video tutorial. Can't remember who or if it happened. If someone want to make one I'll put it on the first page.

Yeah... that would be me :'( 

Unfortunately, right when I was about to start the video series (I have about 3 or 4 planned) I had to move; so everything got packed up -- and I'm in the process of moving again, so now everything is in storage.

Might be another couple months till I get to it. I'll start working on some of the documentation though. Will send you a PM @zitronen once I have some stuff to share  

[zitronen]

Cool thanks for that!

[happytor]

On 3/22/2017 at 6:51 AM, stibbons said:

Could you give some more details about your setup? What operating system are you using? What sort of Arduino? Which version of the plugin and demo sketch? Does the plugin log anything interesting in the KSP debug log? What does the plugin log to the screen when you first load the flight scene? 

Sorry, but to the best of my knowledge there's no decent docs for using this plugin apart from what you can gather from this thread. But I'd love to be proven wrong! 

Hey thanks for the reply. I'm on windows 10 so that might be the issue. Im trying to read old comments and see what helped other peoples builds working. I've got a Teensy 3.6 which is a HID Arduino device. I'm using the latest plugin downloaded through CKAN with the latest Arduino sketch (13 I think). When I load up a ship I get the message that its connected to my COM port on my arduino and that the IO is awake. If I turn the handshake ON my green LED lights up for a second and then turns off. If I turn handshake OFF, no LEDs light up ever. That's all I have been able to accomplish so far. Has anyone else been able to fix this problem? I just want to get some data out of the game and onto an OLED screen

 

EDIT: MY log file:

 

[LOG 16:01:35.342] KSPSerialIO: Version 0.18.3
[LOG 16:01:35.342] KSPSerialIO: Getting serial ports...
[LOG 16:01:35.342] KSPSerialIO: Output packet size: 191/255
[LOG 16:01:35.344] KSPSerialIO: Found 2 serial ports
[LOG 16:01:35.344] KSPSerialIO: trying default port COM8
[LOG 16:01:35.354] KSPSerialIO: Handshake disabled, using COM8

 

Sometimes it will randomly say:

[LOG 16:01:57.738] KSPSerialIO: Port closed

Edited March 26, 2017 by happytor

[zitronen]

If you are using a teensy, you will need to add struct __attribute__((__packed__)), because it is 32bit. @stibbons is the person you need to ask.

[happytor]

Im glad that you know what was wrong, I was about to lose my mind  I only understand enough arduino code to do basic I/O so I'm not sure where to put that line of code. If I add it to the first line of KSPIODemo13 tab it returns an error

 

KSPIODemo13:61: error: expected identifier before 'unsigned'
 unsigned long deadtime, deadtimeOld, controlTime, controlTimeOld;

 ^

KSPIODemo13:61: error: invalid type in declaration before ',' token
 unsigned long deadtime, deadtimeOld, controlTime, controlTimeOld;

                       ^

expected identifier before 'unsigned'

 

Any ideas? 

[stibbons]

1 hour ago, happytor said:

 

Im glad that you know what was wrong, I was about to lose my mind  I only understand enough arduino code to do basic I/O so I'm not sure where to put that line of code.

 

The KSPIODemo13 tab defines three structs, VesselData, HandShakePacket and ControlPacket. Each one of those is of the form

struct HandShakePacket
{
  // Lots of different fields in here
};

By default, the build environment for the Teensy boards treats structs slightly differently than for the 8 bit CPUs in other Arduino boards. To tell the compiler to create the structs the same way, you need to add the "packed" attribute. Do this by modifying all three structs like this:

struct HandShakePacket
{
	// Lots of different fields in here
} __attribute__ ((packed));

 

That should help ensure that the Teensy encodes data how the plugin expects it, and vice-versa.

[JONYghost]

Hello, 

I am planning on controlling the pitch, yaw and roll of a vessel using a gyro connected to Arduino which gives those 3 values (processed) via serial port. (Throttle and more are also planned but not urgent). Is there a way this mod could allow me to control my vessel in such way?

[Mad_Scientist]

4 hours ago, JONYghost said:

Hello, 

I am planning on controlling the pitch, yaw and roll of a vessel using a gyro connected to Arduino which gives those 3 values (processed) via serial port. (Throttle and more are also planned but not urgent). Is there a way this mod could allow me to control my vessel in such way?

Hi,

I guess in this case gyro is used as normal potentiometer, so I don't see why it won't work with this library. If you quickly look into KSPIODemo 13 (link on the first page), library sends ControlPacket, which has values for pitch, yaw and roll (-1000 -> 1000). So, all you need to do is to modify file output.ino in the method controls() for reading input and then sending it back to the game.

 

[JONYghost]

18 minutes ago, Mad_Scientist said:

Hi,

I guess in this case gyro is used as normal potentiometer, so I don't see why it won't work with this library. If you quickly look into KSPIODemo 13 (link on the first page), library sends ControlPacket, which has values for pitch, yaw and roll (-1000 -> 1000). So, all you need to do is to modify file output.ino in the method controls() for reading input and then sending it back to the game.

 

Thanks for the suggestion, I'll try it out

[happytor]

On 3/26/2017 at 8:43 PM, stibbons said:

The KSPIODemo13 tab defines three structs, VesselData, HandShakePacket and ControlPacket. Each one of those is of the form

struct HandShakePacket
{
  // Lots of different fields in here
};

By default, the build environment for the Teensy boards treats structs slightly differently than for the 8 bit CPUs in other Arduino boards. To tell the compiler to create the structs the same way, you need to add the "packed" attribute. Do this by modifying all three structs like this:

struct HandShakePacket
{
	// Lots of different fields in here
} __attribute__ ((packed));

 

That should help ensure that the Teensy encodes data how the plugin expects it, and vice-versa.

Just wanted to personally thank you. I'm in high-school and I just started learning how to use arduinos with this plugin and I would have never figured out how to fix it haha. Really appreciate the help from both you and zitronen Off-topic but are you German Zitronen? Im learning German and I noticed your name was German for lemons haha

[zitronen]

Cool, I think you are the only one using a teensy 3.6, let us know how it works.

I'm not German. I needed a user name when I lived in Austria many years ago, and had a bottle of zitronensaft on my table...

[gremlinWrangler]

Other than the structs thing have had no hassles with my Teensy 3.6 on early 2017 version of the library. @happytor if you have a 3.3. volt FTDI USB<->serial adaptor editing can be a lot less painful if you point KSP io at the adapter where it can happily stream serial data and leave you with the Teensy USB to program and debug.  Also if trying to do use the floating point unit don't forget to use the floating point unit commands (sqrtf for example), otherwise it assumes you wanted double and does them the long way.

[stibbons]

11 minutes ago, gremlinWrangler said:

if you have a 3.3. volt FTDI USB<->serial adaptor editing can be a lot less painful if you point KSP io at the adapter where it can happily stream serial data and leave you with the Teensy USB to program and debug.

Hey, mind if I ask which FTDI adaptor you're using, and on what operating system you're running KSP? I've been hacking on the actual serial interface bits a fair bit, and would like to get more info on which combinations of hardware and OS are known good.