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

[richfiles]

@Mattew The issue was addressed several pages back. not sure where. Long story short, is a 256 byte packet (0-255) is 1/4 (Pro Mini) or 1/8 (Uno) the entire SRAM of some Arduinos. Doubling the packet would drop available memory significantly, and that memory also needs to be used for executing your code! The Mega is in a much better state, with 8 Kb of SRAM. I won't even bother to use anything less than the Mega at this point, but the code has been intended to maintain compatibility with as many Arduinos as possible, I think, which would include the Uno.

At least, I think that's what I got out of it, back then, when it was discussed.

[zitronen]

Update 0.18.3:

Changes:

• Compatibility with 1.2
  • Updates to .dll references
  • centerofmass thing used in roll pitch calculation
  • annoying removal of SAS.manualoverride

Download link:

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

 

Haven't done anything else yet, need to go to bed .

Please test and let me know anything wrong.

 

Edited October 12, 2016 by zitronen

[Freshmeat]

You're a hero. Don't you sleep?

[Sputnix]

17 hours ago, zitronen said:

Hmm.. can you not just save the delta V remaining at the start of the burn for your meter? @stibbons was working on the vector stuff.

We definitely are getting to the limit of what arduinos can handle. And to think when I started this I thought surely 255 bytes should be enough for everybody...

My long term plan is to make KSP send packets through UDP, and have a C# program that converts these to serial and sends the different packets to different COM ports. This way you can have multiple arduinos plugged in the same computer and it should also solve the windows 10 problem. Seems like a lot of work though, probably will take a while I get around to doing it.

So, I'm in the process of embarking on a v2 controller... (madness, I know... v1 isn't even completed fully! )

This version I was going to use a Due, with serial links to two Mega's to try offload some of the processing, and try leverage the Due's 84mhz processor.

Would the Due's open up more possibility, or would we still hit limits?
[I mean, we'll always hit a limit somewhere - but would targeting the Due be feasible]

I'm just going off the specs of the two:

DUE	Mega2560
Flash Memory 512 KB all available for the user applications SRAM 96 KB (two banks: 64KB and 32KB) Clock Speed 84 MHz	Flash Memory 256 KB of which 8 KB used by bootloader SRAM 8 KB EEPROM 4 KB Clock Speed 16 MHz

 

 

[Freshmeat]

i am still waiting for my Due to arrive, it should have been here by late September . I think converting everything to 3.3 V will be tedious, but I think the higher clockspeed will be worth it.

[Sputnix]

5 hours ago, zitronen said:

Update 0.18.3:

Changes:

• Compatibility with 1.2
  • Updates to .dll references
  • centerofmass thing used in roll pitch calculation
  • annoying removal of SAS.manualoverride

Please test and let me know anything wrong.

 

Doing tests; get comms before launch pad loads (blinky lights) but that's all. I haven't done an update to my code since 1.1; but I didn't think there was anything new introduced to the Arduino side of things;
[A quick check of the code supports this]

Log file stuff 

Spoiler

[WRN 19:38:01.803] [HighLogic]: =========================== Scene Change : From EDITOR to FLIGHT (Async) =====================
[LOG 19:38:01.957] [UIApp] OnDestroy: KSPedia
[LOG 19:38:01.965] [UIApp] OnDestroy: EngineersReport
[LOG 19:38:01.979] [PlanetariumCamera]: Focus: Kerbin
[LOG 19:38:01.980] [UIMasterController]: HideUI
[LOG 19:38:02.714] UICanvasPrefabSpawner FlightUI spawning Flight
[LOG 19:38:02.731] UICanvasPrefabSpawner FlightUI spawning VesselLabels
[WRN 19:38:02.732] [UiApp] Awake: ResourceDisplay
[LOG 19:38:02.736] [AddonLoader]: Instantiating addon 'AeroGUI' from assembly 'KSP'
[LOG 19:38:02.738] [AddonLoader]: Instantiating addon 'KSPSerialPort' from assembly 'KSPSerialIO'
[LOG 19:38:02.740] KSPSerialIO: Version 0.18.2
[LOG 19:38:02.740] KSPSerialIO: Getting serial ports...
[LOG 19:38:02.741] KSPSerialIO: Output packet size: 191/255
[LOG 19:38:02.743] KSPSerialIO: Found 3 serial ports
[LOG 19:38:02.743] KSPSerialIO: trying default port COM7
[LOG 19:38:06.771] KSPSerialIO: KSP Display not found
[LOG 19:38:06.775] KSPSerialIO: trying port \Device\Serial0 - COM1
[LOG 19:38:10.779] KSPSerialIO: KSP Display not found
[LOG 19:38:10.780] KSPSerialIO: trying port \Device\USBSER000 - COM7
[LOG 19:38:14.789] KSPSerialIO: found KSP Display at COM7
[LOG 19:38:14.790] [AddonLoader]: Instantiating addon 'KSPSerialIO' from assembly 'KSPSerialIO'
[LOG 19:38:14.795] [PlanetariumCamera]: Focus: Kerbin
[LOG 19:38:14.797] [UIMasterController]: HideUI
[LOG 19:38:14.899] ------------------- initializing flight mode... ------------------
[LOG 19:38:14.903] [MessageSystem] Save Messages
[LOG 19:38:14.904] Loading Depletion Nodes
[LOG 19:38:14.904] DepNodeCount:  0
[LOG 19:38:14.904] Loading Biome Nodes
[LOG 19:38:14.905] BiomeNodeCount:  0
[LOG 19:38:14.905] Loading Planet Nodes
[LOG 19:38:14.905] PlanetNodeCount:  0
[LOG 19:38:14.907] [ScenarioDestructibles]: Loading... 0 objects registered
[LOG 19:38:14.911] Loading ship from file: D:/Steam/steamapps/common/Kerbal Space Program/KSP_Data/../saves/KSP_Testing_SERIALIO/Ships/VAB/Auto-Saved Ship.craft
[LOG 19:38:14.957] Madness loaded!
[LOG 19:38:16.772] putting ship to ground: 2.354106
[LOG 19:38:16.775] [Madness]: Ready to Launch - waiting to start physics...
[LOG 19:38:16.783] Crewmember Jebediah Kerman assigned to Mk1 Command Pod, seat # 0 (crew seat index: 0)
[LOG 19:38:16.784] [FLIGHT GLOBALS]: Switching To Vessel Madness ---------------------- 
[LOG 19:38:16.785] setting new dominant body: Kerbin
FlightGlobals.mainBody: Kerbin
[LOG 19:38:16.787] Reference Frame: Rotating
[LOG 19:38:16.805] Vessel assembly complete!
[LOG 19:38:16.805] all systems started
[LOG 19:38:19.572] [AsteroidSpawner]: No new objects this time. (Odds are 1:2)
[LOG 19:38:19.591] KSPSerialIO: Handshake received - 314
[ERR 19:38:19.626] ADDON BINDER: Cannot resolve assembly: KSPUtil, Culture=neutral, PublicKeyToken=null

[ERR 19:38:19.627] ADDON BINDER: Cannot resolve assembly: KSPUtil, Culture=neutral, PublicKeyToken=null

[EXC 19:38:19.629] FileNotFoundException: Could not load file or assembly 'KSPUtil, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies.

 

[Mattew]

Isn't Due kind of overkill for such project?  If you dont use things like lcd's, monitors and such things required high compute power then Uno/Mega should be fine, right? I have Due here sitting and waitng for my lcd to come for other project. Never think of using it for KSPIo. Too much horsepower

[Sputnix]

56 minutes ago, Mattew said:

Isn't Due kind of overkill for such project?  If you dont use things like lcd's, monitors and such things required high compute power then Uno/Mega should be fine, right? I have Due here sitting and waitng for my lcd to come for other project. Never think of using it for KSPIo. Too much horsepower

You're right. It is. Unless you're doing a lot of mathematics and conversions

On v2, I am looking at using LCDs and trying to do a few other more tricky / clever things. So I figure the more power I can throw at it, the less issues. Right? RIGHT?!  

[Mattew]

Yeah true enought In past I did test 2,2" tft showing simple text and graphs fot fuel etc. and Mega handle it okay. Due is required for more fancy graphics or animation if we talk about lcd's.  I wish that we can handle big lcds in  smoth way. I have 15" panel from notebook here but 0.2 fps or less insn't good at all.

Oh damn you! I start thinking about getting Due insted of Mega for my final version too   

[zitronen]

@Sputnix Oh for **** ****** *****

I did the wrong link thing again. The link should be good now. Check you are getting the 18.3 zip not the 18.2 zip.

Edited October 12, 2016 by zitronen

[Sputnix]

17 hours ago, Freshmeat said:

You're a hero. Don't you sleep?

 

7 hours ago, zitronen said:

@Sputnix Oh for **** ****** *****

I did the wrong link thing again. The link should be good now. Check you are getting the 18.3 zip not the 18.2 zip.

I think we've discovered a pattern with @zitronen's sleep patterns  
There's an old saying: "Fool me once - shame on you; fool me two or three times - shame on me". 

Yeah, I was confused with the (2) after the file name in my downloads folder... but figured I must've accidentally clicked it twice 
It's all good

Anyway -- onto the testing:
x64 & x32 - working no problems. All the switches respond as needed, all outputs seem to be working fine. 

I have noticed that going to the pad, the landing gears are extended (active) by default (even though all switches are 'off').

When I unplug the controller, this seems to happen too; can anyone else confirm this before I post a bug to squad?
(Seems unrelated to KSPSerialIO)
 

[stibbons]

10 minutes ago, Sputnix said:

I have noticed that going to the pad, the landing gears are extended (active) by default (even though all switches are 'off').

When I unplug the controller, this seems to happen too; can anyone else confirm this before I post a bug to squad?
(Seems unrelated to KSPSerialIO)

I fired up a quick sandbox game in an unmodded 1.2 install on macOS an hour or so ago because I wanted to hear the new landing gear sound.

Can confirm that when I put gear on a craft they started out extended in the VAB, but when I retracted them there they were also retracted on launch.

[Sputnix]

8 minutes ago, stibbons said:

Can confirm that when I put gear on a craft they started out extended in the VAB, but when I retracted them there they were also retracted on launch.

I've just found it inconsistently happens when I place vehicle on launch from my list of saved vehicles. :/ 

so, editing the vehicle, and retracting gears seems to help (why the hell would I have set it to extend at launch?) 

Thanks @stibbons  

Edited October 12, 2016 by Sputnix
cos I'm being nooby :P

[Mattew]

I can confirm fully fumctionality too. At least for my controler. Also with CH340 module no issues. I  noticed way quicker KSPIo start when going to pad. We have somechanges in that matter or  it's KSP itself? 

Regarding Due/Mega discussion. At what point is realy worth to use a Due insted of more common Arduino board? I mean what kind of hardware and how much of it can be run by Mega and when it stop to be enough horsepower? 

[Sputnix]

5 hours ago, Mattew said:

Regarding Due/Mega discussion. At what point is realy worth to use a Due insted of more common Arduino board? I mean what kind of hardware and how much of it can be run by Mega and when it stop to be enough horsepower? 

I'm not aware of your background, so I'll answer this to try make sure all readers understand  

Each line of code is a series of instructions to be interpreted by the processor. 
Each cycle of the processor (clock-tick) allows for a certain amount of cycles. Hertz (Hz) = 1 cycle per second; 1 mega hertz (MHz) is a million cycles per second. 
Thus, the Mega has 16 million cycles per second, the Due 84 million.

I'm not sure of the specifics, but each instruction (line or lines of code) takes a certain amount of cycles to process; I know that 16 million cycles per second seems a lot (and it is) - when you start doing a lot of mathematical based functions, or 'casting' (changing the nature of the variables) it gets quite processor intensive. 
I remember doing stuff in my Computer Architecture class where we would manually do the 'processing' of a single part of an instruction set. There's a lot going on under the hood! 

On my controller I have a small LCD display, along with 6x 7-segment displays, along with the various other IO, and 'checking' to see if lights need to be lit, etc. Most of the power is going to displaying, and doing tricky things with the values to make them show up as I need to so that they're meaningful to me. I've hit choke points already where I've had to slow down the refresh rate (from .2 of a second, to .3) and also increase the baud rate of the serial packets because it just wasn't keeping up.

Now sure, I'll be the first to admit - my code is not lean. I'm not a computer scientist (though sometimes I wish I was! ), so I don't quite know the intricacies of the effects of using if loops instead of while loops, etc. So perhaps there is a way to get the code 'leaner' to make more efficient use of the Mega processor (and honestly - you have sparked an inquisitive interest in me to do so -- Thank you! ).

In everything I've read though, the more 'number crunching' you are doing (I suppose that goes also for casting / converting, etc) - the more clock speed you need. 

@zitronen was super smart with his example of the 'all in one' display with the dial. Because that only shows the information based on the selected screen. So all other maths can be 'hidden' and not processed unless on-screen (unless it is still doing it in the background...) 

So I suppose, at the end of the day, it depends what you're trying to achieve with the controller, and what you're pushing it to do. It's all fun and experimentation!
But I figure if I can get 5x the power, I might be able to do a few more cooler things - just opens up the opportunities  

Another way is to use more processors; some people are using multiple processors in their builds. So a single Mega (usually) is the 'gate keeper' shuttling instructions between the computer and then other arduinos (via serial connection), where the processing of the instructions is done on those devices. This means the mega is just pushing data packets to them, and then the sub-processors can do all the maths and creative trickery like visualising navigation balls (eh, @stibbons  ). 

Remember: a 600 mhz computer would run Windows 98 or Windows 2000 very nicely. It would struggle with anything newer (XP, passable; Vista / 7 / 10 - borderline). The stuff going on in the background has increased. 
Likewise, I think once we try to do more and more with our controllers, we start wanting  needing more power! 

In fact, what I'm looking at doing is a combination of both. Use a Due as the 'gatekeeper', do some of the LCD stuff on it, but then shuttle off instructions to sub processors (either a couple Mega's, or maybe Uno's - not sure yet). 

[richfiles]

And of course, you can't forget the issue of memory.
Even bumping from just an Uno to a Mega is a significant jump in SRAM, which leaves more room to actually work on your data.

[Mattew]

I probably got what do you think. Adding more stuff to control panel means adding more compute power to it as well. It probably mostly depends on what type of CP you are building.

And thinking of it we, have four styles of panels at moment

1. Apollo era - lots of buttons, switches, analog meters, almost none digital devices.

2. Early (1980) Shuttle -  its kind of Apollo style with some more lcds and digital tech.

3. 2000+ Shuttles, Soyuz, other active spaceships - modern looking, many lcds, fewer switches and analog devices.

4. Future, sci-fi style - probably CP with touch lcds and other fancy stuff and eye candy.

 

Here i found some very nice LCD screens from shuttle showing information of all kind. For inspiration

That thing about data packet size and sram. I belive that suggestion was there few post back, but good way how to make it would be like do Lite version (one 255 packet) and Full version having 2x255 packets or so, for ppl with fancy powerful hardware able to handle it (Dueeeeee ) Or maybe be able to chose data what you want send in packet. For instance, i dont use like 40% of incoming information in packet atm (useless to me) . Suggestions?

 

Edit: So I decided to use DUE as well. It will be more helpful here in KSPio CP then my other project. Lets call some kerbal engineers  here and get to work, maybe Bill Kerman will know. Bill, hey Bill, how we control that sweet 9" 800x600 touch lcd ??.....

Edited October 14, 2016 by Mattew
Typos, Adding info

[gremlinWrangler]

Hi, just to chip into the 'how much horse power' question have a work in progress panel based on the Teensy 32 bit Arduino offshoots. The current generation runs 180mhz and has a floating point unit, also natively supports USB interaction so bypasses the windows input problem by sending keypresses when I press buttons.

That gave me enough processing and RAM to have a colour LCD showing a rendered spherical navball. Made more fun by the fact that some of the pointing information for vectors wasn't available so had to process it out. My vector math was a touch rusty. So yes with more horsepower you can do more interesting things without having to spend ages optimising code.

Critical thing for anybody moving to 32 bit CPUS is that you need to add

struct __attribute__((__packed__)) VesselData

To your message structure definition in the Arduino code, otherwise all the bytes in the message get mixed together.

Edited October 15, 2016 by gremlinWrangler
Spelling

[stibbons]

1 hour ago, gremlinWrangler said:

That gave me enough processing and RAM to have a colour LCD showing a rendered spherical navball. Made more fun by the fact that some of the pointing information for vectors wasn't available so had to process it out. My vector math was a touch rusty. So yes with more horsepower you can do more interesting things without having to spend ages optimising code.

I'm doing the same thing, rendering a navball on a teensy 3.2 (to be upgraded to a 3.6 at some point). Have had a couple of attempts at getting the vector data out of KSP, but still haven't managed to decent Euler coords out. I'd be very interested to see how you managed it.

[gremlinWrangler]

Re getting vector information for display I'm cheating:

    float currentLat = VData.Lat/180*PI;
    float currentLong = VData.Lon/180*PI;
    float NorthAngularChange = currentLat-oldLat;
    float eastAngularChange = currentLong-oldLong;

    float northSpeed = sinf(NorthAngularChange)*(VData.Alt+600000)/lastLatData*1000;
    float eastSpeed = sinf(eastAngularChange)*(VData.Alt+600000)/lastLatData*1000; 

Gets north and east speeds, and we already have the vertical speed so can place to/from vectors on the nav ball. This means it's dependent on the update rate and needing that 600k replaced when sphere of influence changes. What it should be doing is using the orbital elements but my math wasn't up to the job of converting that data into current vectors.

[Mattew]

Why not just then use raspberry pi or beaglebone if you need so much compute power? 1Ghz clock and tons of ram and storage space

[gremlinWrangler]

Re hardware choice, Pi et al is valid but if doing so I'd probably skip KSPIO and use telemechus via browser. Pi's and similar don't do real time interaction that well so since I wanted anlog gauges , 7 segment displays with lots of buttons and lights an Arduino got me where I needed with the programing skills I had. Someone with better python/java etc skills would make different choices for the same outcome.

On a related comment that may have already come up for people using DUEs or other native USB boards, it can make life a lot easier to prototype using a seperate FTDI cable running to a hardware serial port (normally Serial1) for KSPIO. That means the serial port KSP uses stays static while you reprogram your Arduino via USB, and also leaves the Arduino serial port free for debug information on what the board is up to.

[Sputnix]

On 10/15/2016 at 1:53 PM, gremlinWrangler said:

.... based on the Teensy 32 bit Arduino offshoots. The current generation runs 180mhz and has a floating point unit, also natively supports USB interaction so bypasses the windows input problem by sending keypresses when I press buttons.

 

@gremlinWrangler -- Is this the Teensy you are using? 

On 10/14/2016 at 9:43 AM, richfiles said:

And of course, you can't forget the issue of memory.
Even bumping from just an Uno to a Mega is a significant jump in SRAM, which leaves more room to actually work on your data.

Gosh -- How did I miss that important point with the various models 

Thanks @richfiles!  

---

Just to add to @gremlinWrangler re: hardware choice, - 

using a Pi (be it raspberry, orange, or some other derivative) or beaglebone adds not only the latency issue as gremlin mentioned, but also another level of complexity. You need an OS on those things, and then thru the OS interact with the Digital & Analogue I/O, SPI, etc. This then adds another layer of fault-finding if things don't work.

If you're wanting the best of all worlds, you would probably use an Arduino (or cluster of them) to deal with the 'timely' type stuff (speed, heights, navigation, controls, etc) and then also use a Pi (or equivalent) for more 'big picture' data and display of that data - where the 'latency' or reaction isn't so critical. I could see myself doing something like that with Telemachus - but I want to focus on v2 of the simpit / controller before dreaming too much about v3 
In fact, the Pi would be perfect for the drawing of maps / overlays, etc. because of the embedded graphics. 

It's still incredible that there are people drawing graphics using Arduino's - and then actually animating them! That stuff blows my mind, and I'm in awe of them! (you all know who you are ) 

Edited October 16, 2016 by Sputnix

[gremlinWrangler]

@Sputnix - yes that's the Teensy that I used to drive things. The T3.2 is much more mature for all the other bits and piece's you'd use in a control panel but was looking for a project to stretch it's legs, hence trying to do the needlessly complex spherical render. Would be far more sensible to do what generations of aircraft HUD designers have done for displaying heading/pitch/roll and run separate heading and pitch lines across a rectangular display and keep all the math simple.

Where's the fun in sensible though, this is a game about exploding rockets!

[Mattew]

20 hours ago, gremlinWrangler said:

Where's the fun in sensible though, this is a game about exploding rockets!

Yeah totaly. I should take my head of clouds and go back to ground, that means stop thinking about 17" touch lcds and fancy stuff and be more realistic with leds and analog meters.  I think we are not here to build precise spaceship simulator   I stick to DUE as best what i can achive to get it work one day.  To all of you who can do 3D navballs and such stuff that is realy cool work, very nice   

 

Edit: Question for navball experts. How do you get data where ship points relative to any nav node? I know we have pitch/yaw/roll  data of ship. I am asking bcs i got idea about very simplified linear "navball" (for us non experts ) that could tell you if you point to desired navpoint or not

Edited October 17, 2016 by Mattew
Adding stuff, no need fo double post