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

[Mulbin]

Unfortunately arduino only supports 8bit PWM, so you only get 255 steps.

Yes.. but I'm not getting 255 steps, I'm getting exactly 100 (I counted them) which is a very slow, noticable jump. Surely if you used a decimal it would force the arduino to use all 255 steps instead which would be much smoother. Also, a decimal point would be better for any digital fuel gauge, particularly on very small engined craft where a whole percent is actually quite a bit of DV.

[Mulbin]

My Uno arrived today and I can confirm the plugin works fine no matter how I launch - from the VAB or from the launchpad menu.

On the Mega it only works from the VAB.

[zitronen]

Yes.. but I'm not getting 255 steps, I'm getting exactly 100 (I counted them) which is a very slow, noticable jump. Surely if you used a decimal it would force the arduino to use all 255 steps instead which would be much smoother. Also, a decimal point would be better for any digital fuel gauge, particularly on very small engined craft where a whole percent is actually quite a bit of DV.

Oh duh "map()" only works for integers, try: analogWrite(PWMPin, round(fuelp*100/255))

My Uno arrived today and I can confirm the plugin works fine no matter how I launch - from the VAB or from the launchpad menu.

On the Mega it only works from the VAB.

Very weird. I will do more tests when I get my mega.

[Mulbin]

analogWrite(PWMPin, round(fuelp*100/255)) just throws up an error when I try to upload it. - error: 'Fuelp' was not declared in this scope

... so I tried using VData.Fuelp instead of just Fuelp... but that causes the gauge to act very strangely, with 100% fuel the guage only moves up to about 1/6 full...(as if it is only receiving less than 1 volt) and still ticks down in the same big steps as before.

EDIT - Obviously I'd still like to get the gauge to read 255 steps instead of 100 but I've decided to also fit a capacitor to smooth it out even more. I have two electrolytic capacitors... 1 is 1uf 100v, the other is 0.1 uf 63v. So I just wire it parallel to the gauge?... or do I need to give it a resistor as well? Still learning basic electronics lol and don't want to put anything on unless I'm sure its not going to fry

Thanks for the continued noob patience!

Edited February 5, 2014 by Mulbin

[zitronen]

Oh oops, try analogWrite(PWMPin, round(VData.Fuelp*255/100)).

Yeah just put the cap parallel to the meter should do it. The bigger the cap the smoother, but it will also make it lag a bit.

[NeoMorph]

OK... colour me VERY IMPRESSED. Where did you get the matrix display from?

I love making hardware cockpits and fell in love with the Arduino's simplicity. I've got so many arduino shields (chinese knock-offs) and boards and drivers and buttons and switches ready to build my setup. I've just got to sit down and finish the various bits. Some of my stuff comes out of real 60's aerospace cockpits... should make it look interesting.

I've been using Telemachus as the interface between KSP and my hardware. Works quite well with what I have breadboarded so far.

Nice to see you are using 7219's to drive the seven seg displays. I've used them for my Kerpollo DSKY... (although I've used the narrow bodied CNG version as I had bought a bulk order from China some time back as I use them in a lot of projects using Seven Seg displays).

Have you thought of making meters and such from a servo driver. You can make some nice analogue displays that way and a 16 meter system can be driven using one of these...

Edited February 5, 2014 by NeoMorph

[Mulbin]

Oh oops, try analogWrite(PWMPin, round(VData.Fuelp*255/100)).

Yeah just put the cap parallel to the meter should do it. The bigger the cap the smoother, but it will also make it lag a bit.

Great I'll give those a try.

Some of my stuff comes out of real 60's aerospace cockpits... should make it look interesting.

Sounds awesome! I'm basing my build on 1960s stuff, from Mercury, Gemini, Apollo.

http://forum.kerbalspaceprogram.com/threads/66742-Custom-hardware-control-switch-panel-simpit-WIP?p=920057#post920057

If you start a thread for your build let me know and I'll add it to my repository thread here! I asked the mods if we could have a sub forum but they said there isn't enough interest yet but would reconsider if the sub-hobby takes off.

http://forum.kerbalspaceprogram.com/threads/66763-Custom-hardware-simpit-repository-For-people-who-take-KSP-a-little-too-far?p=920499#post920499

EDIT - lol just realised that not only have we already spoken on my thread... but I've already linked your nav-ball project on the repository! Would be great to see your DSKY stuff! I'm planning my third panel to be a flight data panel based on the look of the apollo computer. It will show AP/PE etc... possibly later it will actually be programmable but one step at a time!

Edited February 5, 2014 by Mulbin

[Mulbin]

The new code is much better, thanks. It now ticks down in 255 segments. Adding a 1uf capacitor in parallel doesnt seem to have made it any smoother though.

But I'm on track now for my build for the dial panel and I can start buying up some nice retro gauges in preparation! I hope you make good progress on the UI you mentioned so I can add all the other resources I need to display

I might start looking ar 8 digit 7 segment displays too for my third panel (flight data)

[zitronen]

The next step is figure out the weird issue with arduino MEGAs, then look into user editable config file, then controlling KSP from arduino, after that I will add more features, so you might need to wait for a bit...

[zitronen]

Where did you get the matrix display from?

Nice to see you are using 7219's to drive the seven seg displays. I've used them for my Kerpollo DSKY... (although I've used the narrow bodied CNG version as I had bought a bulk order from China some time back as I use them in a lot of projects using Seven Seg displays).

It's just a standard 20x4 character display, you can get one on ebay or many websits for ~$10. I don't actually use MAX7219s since they are super expensive. I'm using AS1117, which is basically the same just much cheaper.

[NeoMorph]

It's just a standard 20x4 character display, you can get one on ebay or many websits for ~$10. I don't actually use MAX7219s since they are super expensive. I'm using AS1117, which is basically the same just much cheaper.

ROFL... I just found I have a couple of them in one of my parts boxes (I tend to buy stuff on ebay that sounds interesting and then forget about them... I'm most definitely a parts whore - I'll take anything).

Weird about those 7219's because according to your BOM you use two wide 7219 SOICs (U7 and U8). Maybe you forgot to update it. If you buy a batch of them from China they aren't that expensive tbh. Just a long lead time is all.

Mulbin, the reason I had stalled on my project was that I was saving up for a CNC so that I can cut my parts with more accuracy. I'll be getting a four axis 6040Z in the next couple of months and then I will be able to make everything from the engraved panels to the custom mountings for my nav ball innards (which were driving me bonkers last year due to being out of alignment slightly which caused friction drag at one part of the 3D rotation which led to drift after about 5 mins... not good).

[Mulbin]

engraved panels to the custom mountings

I like the sound of that... I will initially be creating transfer prints for my labels etc, but as a graphic designer I have a really good printing company I use who can print directly on to the composite board (which I am using for my project) for more permanent boards in the future. But now you have mentioned engraved panels I've realised I have access to my old college laser etcher / cutter so that might be another option.

[NeoMorph]

The reason I want to go with the engraved panels is that I love backlighting them. Nothing that makes a sim more fun than working it in a darkened room. There is a cheat way you can go if you can't afford backlighting though... My first cockpit I made used labels that were UV reactive and had a black light overhead. Was pretty much the way they did it back in the 30's and 40's iirc.

My ATR72 cockpit for example (panels that I bought from a Flight Sim parts supplier) used white semi-transparent acrylic which was first painted and then engraved. Light behind then comes through where the paint has been removed. I've got the idea of doing the spacecraft ones using clear acrylic and then spraying the panel black (two coats to block the light), then adding a white and then grey final layer. Then spraying the whole panel with liquid masking and then engraving it. The next step will be to add a think layer of white paint before removing the masking. That SHOULD leave the white lettering that will glow when a backlight is placed behind the panel.

But first I have got to get my CNC machine and learn how to use it properly... this is not a project that is going to be finished overnight.

[zitronen]

Um... I got my mega, and what do you know? It works perfectly fine! I don't even....

Unless people complain, I think I'll just leave this at that. So it seems for some people as long as you launch from VAB or SPH it works, it's annoying but I think I'll move on to add more features.

[zitronen]

Update 4: Added user settings! See first post.

[Donziboy2]

The new code is much better, thanks. It now ticks down in 255 segments. Adding a 1uf capacitor in parallel doesnt seem to have made it any smoother though.

But I'm on track now for my build for the dial panel and I can start buying up some nice retro gauges in preparation! I hope you make good progress on the UI you mentioned so I can add all the other resources I need to display

I might start looking ar 8 digit 7 segment displays too for my third panel (flight data)

The capacitor size really depends on the resistance of the gauge. If the resistance is high and the capacitance is low it will charge to fast making it jump between ticks and if the resistance is to low and the capacitance to high it may never settle in the right spot at all. You will most likely have to increase the size until your happy with its speed, keep in mind that the larger the cap you use the longer it will take to settle when you first power the gauge and it goes to 100%(full tank/battery).

[Mulbin]

The capacitor size really depends on the resistance of the gauge. If the resistance is high and the capacitance is low it will charge to fast making it jump between ticks and if the resistance is to low and the capacitance to high it may never settle in the right spot at all. You will most likely have to increase the size until your happy with its speed, keep in mind that the larger the cap you use the longer it will take to settle when you first power the gauge and it goes to 100%(full tank/battery).

Thanks thats really helpful, I'll probably pick up a grab back of mixed caps and have a play around.

Update 4: Added user settings! See first post.

!!!! wow, that was quick. what can we edit?

Um... I got my mega, and what do you know? It works perfectly fine! I don't even....

Unless people complain, I think I'll just leave this at that. So it seems for some people as long as you launch from VAB or SPH it works, it's annoying but I think I'll move on to add more features.

Although it would be great to track down the bug later, I agree... there is a work around so more important to get functionality up and the ability to add more data types / a user editor.

Edited February 8, 2014 by Mulbin

[AMirrodin]

Found a way to send commands from my arduino to the plugin. I made a new function to check if a button was pressed and if it was then it executed Serial.println(F("KSP;1")). I also had to put a new if statement in the plugin C# code to look for the message.

Arduino code snip:

void SendStage(){
  if(digitalRead(2) == HIGH){
    Serial.println(F("KSP;1"));
  }
}

Plugin code snip:

//This part is usually here
if (parsed[0] == "KSP")
{
   short messageID = (short)double.Parse(parsed[1]);
   if (messageID == 0)
   {
      DisplayFound = true;
   }
//Added code below
   if (messageID == 1)
   {
      Staging.ActivateNextStage();
   }                            
}

[zitronen]

That's fine, bear in mind that I will be overhauling the input code next week. Right now it's just a place holder. It will be much easier to use and will allow many inputs but will be completely different. If you guys can come up with a list of controls (RCS, SAS, etc.) you would like to have that would be helpful.

[katton]

That's fine, bear in mind that I will be overhauling the input code next week. Right now it's just a place holder. It will be much easier to use and will allow many inputs but will be completely different. If you guys can come up with a list of controls (RCS, SAS, etc.) you would like to have that would be helpful.

The ones that I had in mind were:

- Action groups 1-10 (+ Abort) (if you could have the plugin tell the arduino whether these had actions assigned to them, ie. whether they're empty or not it would be pretty neat)

For the following, it could either be a toggle-the-value type of command, or two dedicated commands for each (plus, if the plugin once again could report on the state of all of them, it would be helpful for indicators and the like)

- SAS on / off

- RCS on / off

- Precision mode on/off

- Lights on/off

- Gear on/off

- Brakes on/off

- Set throttle to X (also, once again, returning the current throttle to the arduino would be neat)

- Stage (of course)

- Time Warp (eventually, I assume that this one is going to be hard to program) (set to X multiplier command from arduino, and return to arduino current warp multiplier, whether it's physical or not, and perhaps the max multiplier, if possible)

- Rotation and Translation Commands - I'm not sure if this is the best way to do it, but eventually hooking up joysticks through the arduino would be neat. I don't know if the refresh rate would make it possible or not, but sending pitch, yaw, roll, and x, y z translation commands would be peachy.

[Mulbin]

Do controls need to go through the plugin? They are just keystrokes which KSP already understands without the plugin... why not just use keyboard.print?

Also why do you need to put the joystick through Arduino... joysticks already work.

Or am I missing something?

Anyway if there is actually a reason to send keystrokes though the plugin can I suggest a nice option would be to program it to allow for toggle switches as well as momentary switches? i.e. flipping a switch to the "on" or back to the "off" postion just sends a short "tap" on the control... otherwise it will be like holding a keyboard button down.

Below is what I mean by sending a "tap" rather than a constant "on" signal - although in this example it is sending a joypad button press rather than keyboard.

For me - as it is already quite simple to send commands to KSP without this plugin the much more important factor is to get more usful data coming out of the plugin to drive displays.

Edited February 10, 2014 by Mulbin

[Donziboy2]

Do controls need to go through the plugin? They are just keystrokes which KSP already understands without the plugin... why not just use keyboard.print?

I think katton was referring to custom Keyboards or control panels that would be controlled by the Arduino. Having a nice display and then an IBM keyboard on your desk kind of kills the immersion.

Also why do you need to put the joystick through Arduino... joysticks already work.

katton said nothing about a joystick, but making a custom joystick similar to in game ones would be pretty cool. Also not everyone has a joystick, maybe katton wants fine control of the throttle instead of the limited control you get with the keyboard.

Anyway if there is actually a reason to send keystrokes though the plugin can I suggest a nice option would be to program it to allow for toggle switches as well as momentary switches? i.e. flipping a switch to the "on" or back to the "off" postion just sends a short "tap" on the control... otherwise it will be like holding a keyboard button down.

Below is what I mean by sending a "tap" rather than a constant "on" signal - although in this example it is sending a joypad button press rather than keyboard.

http://www.desktopaviator.com/Products/Model_2120/2120B.gif

That is actually the best way to implement it, a few if statements would probably be all that is required.

For me - as it is already quite simple to send commands to KSP without this plugin the much more important factor is to get more usful data coming out of the plugin to drive displays.

I think hammering down what other data needs to be sent is important, I would like to know the actual limit to information that can be received in the 80ms default time frame given.

[Mulbin]

I think katton was referring to custom Keyboards or control panels that would be controlled by the Arduino. Having a nice display and then an IBM keyboard on your desk kind of kills the immersion.

Yes I know, I've built one... it doesn't need the plugin. You can just program the Arduino to send keystrokes... which KSP already understands, sending them via the plugin is redundant.

For example, program the Arduino so that when you press a button, it sends the signal for the "G" key... when you press the button/switch, the gear will lower (because KSP thinks you have pressed G on your keyboard)... no need for the plugin to get involved.

katton said nothing about a joystick

Thats exactly what he said..l'm just not sure what the point is as joysticks already work with ksp.

eventually hooking up joysticks through the arduino would be neat.

Again, I might have missed something but can't really see the what the bonus is of putting this data through zitronens plugin is rather than just sending straight to your computer as usual which works just fine. I can do all this without the plugin even installed... The genius of this plugin is that it gets data out of KSP, putting commands into the game is a standard feature of the game already.

Edited February 10, 2014 by Mulbin

[Mulbin]

To illustrate my point here is my current setup, neither the joystick or the switch board need to go through zitronens plugin as ksp already listens for joystick commands and keystrokes by default. Why have an RCS command on the plugin when your arduino can just send the signal "R" via the "keyboard.print" command...

...seriously though, I might have missed some advantage to pushing these commands through an extra plugin but I'm scratching my head as to what the point is.

[zitronen]

Do controls need to go through the plugin? They are just keystrokes which KSP already understands without the plugin... why not just use keyboard.print?

Also why do you need to put the joystick through Arduino... joysticks already work.

Or am I missing something?

Anyway if there is actually a reason to send keystrokes though the plugin can I suggest a nice option would be to program it to allow for toggle switches as well as momentary switches? i.e. flipping a switch to the "on" or back to the "off" postion just sends a short "tap" on the control... otherwise it will be like holding a keyboard button down.

Below is what I mean by sending a "tap" rather than a constant "on" signal - although in this example it is sending a joypad button press rather than keyboard.

http://www.desktopaviator.com/Products/Model_2120/2120B.gif

For me - as it is already quite simple to send commands to KSP without this plugin the much more important factor is to get more usful data coming out of the plugin to drive displays.

Ok the problem is say you have a switch that turns the lights on, but what if your lights are already on? If you flip the switch to on the lights will turn off. If you want to use use a separate device for control that's fine, it's what I do as well, but other people would like the ability to send commands to KSP, maybe for a guidance computer which will require input and output. I think that's reasonable and quite cool.

I think hammering down what other data needs to be sent is important, I would like to know the actual limit to information that can be received in the 80ms default time frame given.

The packet is currently limited to 255 bytes, we are using 69 bytes right now so still lots of space left, because we are using a relatively efficient binary format. If we ever run out of bytes it's easy to just make a new packet type. It takes less than 10ms to transmit 255 bytes at the default 38400 Baud. If that ever becomes an issue we can triple the Baud rate to 115200, which if I may quote the great Bill Gates "should be enough for anyone".

Edit: If you guys want to put together a list of data you want sent from KSP that would be nice too. I will start on that when I get basic inputs working.

Edited February 10, 2014 by zitronen