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

[zitronen]

On 24/04/2016 at 9:18 AM, KingLuxor said:

 

@zitronen

Did some testing on windows 10 because I was bored.

I purchased two Unos that use the WCH340 chip, they both work perfectly. Reading over the entire thread I saw a mention of using a proxy app to receive UDP from KSP and relay that out the serial port using System.IO.Ports. I gave that a shot, but again it fails with the Uno using the Atmel 8u2, but works great with the WCH340 chips.

The WCH340 chips keep on working as long as I keep the UDP listening, but the ATmel chip always hangs up on the serial port methods before reaching an AP of 500m, so it doesn't fail right away, but I can't make it work.

Wait do you mean you have written a KSP-> UDP plugin and an external program to do UDP -> serial? I think I should try to get some of these WCH340 things.

[Guiterro]

2 hours ago, zitronen said:

Oh excrements not again, sorry! It's annoying since they changed the forum code, I used to just change the text, but now have to remember replace the whole link. Should be fixed now.

 

Oh yeah and loveing auto censoring excrements lovely persons.

No big deal at all

I think for providing such an excellent Mod you got a few fails for free. 

[KingLuxor]

2 hours ago, zitronen said:

Wait do you mean you have written a KSP-> UDP plugin and an external program to do UDP -> serial? I think I should try to get some of these WCH340 things.

@zitronen

Yes, that's exactly what I did. Very crude and to the point just to see if it would work.

The UNO with the WCH340 > http://www.amazon.com/HiLetgo-Board-ATmega328P-CH340-Arduino/dp/B01AR7YJ3O?ie=UTF8&psc=1&redirect=true&ref_=oh_aui_detailpage_o05_s02

The Mega with the WCH340 > http://www.amazon.com/OSOYOO-ATmega2560-16AU-CH340G-Arduino-Learner/dp/B00SFICZUM?ie=UTF8&psc=1&redirect=true&ref_=oh_aui_detailpage_o04_s02

[Sputnix]

18 hours ago, zitronen said:

Oh excrements not again, sorry! It's annoying since they changed the forum code, I used to just change the text, but now have to remember replace the whole link. Should be fixed now.

 

Oh yeah and loveing auto censoring excrements lovely persons.

So much excrements... 

[zitronen]

On 25/04/2016 at 8:11 PM, KingLuxor said:

@zitronen

Yes, that's exactly what I did. Very crude and to the point just to see if it would work.

The UNO with the WCH340 > http://www.amazon.com/HiLetgo-Board-ATmega328P-CH340-Arduino/dp/B01AR7YJ3O?ie=UTF8&psc=1&redirect=true&ref_=oh_aui_detailpage_o05_s02

The Mega with the WCH340 > http://www.amazon.com/OSOYOO-ATmega2560-16AU-CH340G-Arduino-Learner/dp/B00SFICZUM?ie=UTF8&psc=1&redirect=true&ref_=oh_aui_detailpage_o04_s02

OK Thanks. But I just realised I still need windows 10 to do the tests, and I kind of don't want windows 10. If someone else is stuck with windows 10 I'll tell them to try those.

[Mattew]

Couple of question that came to my mind. I read several post about possibility of implementing MechJeb comands and interacting with MJ using KspIO, but it seem no one was able to achive it. Or atleast on devent level. So any news on this "topic" or still hard to do / impossible?  On other hand i start thinking about arduino based autopilot for some actions (ascend guidence for example) but I run in problem of nodes. I mean, we dont have any info on where ships points relative to node right? Something I start call "NDD"  (Node Differential Data) which will tell you if you point to node (manuver node, prograde, etc.) or how far you point away of node. Also on matter of autopilot for node manuvers I miss data on Delta-V burned already, basicly mean I dont know how much of burn ship already did. Can we have such data or its not possible at all? And someone have any sort of auto action on their control panel?

[zitronen]

I'm not working on it. You might need to ask @cm2227 how hard/easy it is. @Sputnix is working on adding the orbital vectors, so at some point you will be able to write a thing that points the ship to the right direction. There is enough information in the packet that It is already possible to make a autopilot for atmospheric flight.

Edited May 9, 2016 by zitronen

[Sputnix]

20 hours ago, zitronen said:

@Sputnix is working on adding the orbital vectors, so at some point you will be able to write a thing that points the ship to the right direction. There is enough information in the packet that It is already possible to make a autopilot for atmospheric flight.

Normally I don't mind challenges being assigned to me... but I'm afraid I'm not sure where to begin with something like this
I believe it's @stibbons that's doing (and accomplished - to some degree) this feat of awesomeness 

[zitronen]

Hey both of your names start with 'S', close enough!

[Mattew]

So atm we dont have any easy method to interact with nodes. I see that airplane autopilot is doable, we have surface vetors, surface speed, alt so on. Sadly I am rocket guy  But I see that autoascend is doable too, but with manual orbital inserection tho. I would like to help on this matter but I dont even know how basic IO plugin works. its so beyond me  I ll check other work

 

[stibbons]

On 5/8/2016 at 2:41 AM, Mattew said:

I mean, we dont have any info on where ships points relative to node right? Something I start call "NDD"  (Node Differential Data) which will tell you if you point to node (manuver node, prograde, etc.) or how far you point away of node.

There's a couple of ways to approach this data. I think what you're asking for is the simpler way, getting relative relative pitch and yaw from your current heading to the given node. You can then plug that in to an autopilot or whatever fairly simply and have it orient the vessel appropriately. I've been able to start generating that data, and have a branch of the KSPSerialIO code that outputs it for surface and orbital prograde, orbital normal and radial, as well as maneuver and target nodes. I'm pretty sure they're all accurate too.  

The more complicated way, that I'm more interested in, is generating Euler angles for the various nodes. They're required to be able to orient the nodes properly on all three axes simultaneously, for rendering them on a navball or similar. I'm still not familiar enough with doing things in Unity to be able to successfully generate those (and the fact that I'm currently on holiday travelling doesn't help  ).

Ideally I'd like to be able to configure the plugin to choose which data to send. But no promises on timeline right now, sorry.

On 5/8/2016 at 2:41 AM, Mattew said:

Also on matter of autopilot for node manuvers I miss data on Delta-V burned already, basicly mean I dont know how much of burn ship already did.

Pretty sure it's just not possible to get that data from the game. You'd have to calculate it yourself by remembering initial delta-v when you place a node, and then subtracting current delta-v from that.

[Mattew]

18 hours ago, stibbons said:

 I think what you're asking for is the simpler way, getting relative relative pitch and yaw from your current heading to the given node.

Yes, this is exactly what ll help. With  that info you can easly manuver ship to that node   But its beyond my skill to get that info and i think I ll left honor to you, since your work is very impresive as it is now.  And hope you make your code someday public   Wish I can help tho  Those Euler angles, what is thaaat, i dont understand at all, dont lika math that match  

18 hours ago, stibbons said:

subtracting current delta-v from that.

um, we know curent delta-v of ship atm? Guess its your mod of code right since i dont see that info in packet  

also @zitronen , do you think that autopilot routines can slow down code/mCU that much so there will be possible desync and com drop between arudino and pc?

 

Edited May 11, 2016 by Mattew
additional question

[zitronen]

Sure it's possible that a complicated autopilot will use too much time, but a simple PID controller should be fairly fast. In any case, I would suggest you start with something simple that works before planning more advanced stuff.

[Mattew]

1 hour ago, zitronen said:

  suggest you start with something simple 

 I think my nixie tube speedometer with its own mCU for communication is beyond simple already and 3 LEDs arent fun anymore    Most hardware I got up and running, thinking about design of panel itself. That is why I am asking on auto routines stuff, since it ll need some kind of interface to operate and control (DSKY style maybe?) and that must be taken into account for design   

I asked about sync issues, bcs i had problems with it in past while running gLCD which took to much time. But good idea with PID, didnt think about that one. I ll look in that. Ty   

[KingLuxor]

I'm still in the process of building my controller. Reloading KSP multiple times to check/verify changes to the Arduino code was a bit tiresome.

I've hacked zitronen's code up a bit to the point that I have a "debugging" tool, which is almost fully functional.

It allows you to see/verify the incoming data from the Arduino, as well as send control values to the Arduino. Realizing that most people have customized this is some way, the project is open source.

I don't want to hijack this thread or flood it with input/comments, you can find my post about it here: 

 

[zitronen]

WOW, ok that's going on the first page!

[richfiles]

Has anyone used the SOI byte for modded games, such as games running Kopernicus, with add ons like Outer Planets Mod, etc? Is there a hard limit to 9 planets per sun and 9 moons per planet with the existing byte (decimal) format? How many suns are permitted? I think OPM also has a moon orbiting another moon, orbiting a planet, orbiting the sun... Is it even POSSIBLE to transmit those SoI locations over the packet in it's current incarnation, or am I missing something in how the packet is set up? OPM is actually my intended reward for when i finish my build, so full capacity to implement OPM is pretty important to me.

Can a modded install just bump the sun digit arbitrarily to represent planet/moon counts higher than 9, provided both halves of the software are configured to do this? 

Edited May 22, 2016 by richfiles

[Freshmeat]

@richfiles In theory it could be done, but it would be very painful to maintain. I do not know how OPM implements planets, but you could probably make something like 2xx, addressing up to five planets and moons. However, I think that to get a general method, you could calculate the mass of the current attrator using your orbital elements and then a lookup table. The idea floated around somewhere in the thread, including some problems and solutions.

[zitronen]

Well it's not difficult to add more SOI numbers if squad decides to have a planet/star DLC or something, the code is there for it. It's a simple look-up table, the reason for the star/planet/moon decimal system is just for human readability. We could just assign any value so 255 SOIs max with the byte. (Edit: 255 SOIs ought to be enough for anybody right? right? ) I won't be adding support for mod planets, but if you want to add your own it's pretty easy, just go to the GetSOINumber function.

 

        private byte GetSOINumber(string name)
        {
            byte SOI;

            switch (name.ToLower())
            {
                case "sun":
                    SOI = 100;
                    break;
                case "moho":
                    SOI = 110;
                    break;
                case "eve":
                    SOI = 120;
                    break;
                case "gilly":
                    SOI = 121;
                    break;
                case "kerbin":
                    SOI = 130;
                    break;
                case "mun":
                    SOI = 131;
                    break;
                case "minmus":
                    SOI = 132;
                    break;
                case "duna":
                    SOI = 140;
                    break;
                case "ike":
                    SOI = 141;
                    break;
                case "dres":
                    SOI = 150;
                    break;
                case "jool":
                    SOI = 160;
                    break;
                case "laythe":
                    SOI = 161;
                    break;
                case "vall":
                    SOI = 162;
                    break;
                case "tylo":
                    SOI = 163;
                    break;
                case "bop":
                    SOI = 164;
                    break;
                case "pol":
                    SOI = 165;
                    break;
                case "eeloo":
                    SOI = 170;
                    break;
                default:
                    SOI = 0;
                    break;
            }
            return SOI;
        }

 

Edited May 23, 2016 by zitronen

[richfiles]

Thanks! I figured it was likely an arbitrary representation, but i've been 99.7% invested in the hardware side, and dreading the software side of my controller project... I barely know a thing about C. Good to know one aspect of the customization looks fairly straight forward. It also made sense to ask. Why reinvent the wheel if someone else already figured out a solution! 

Edited May 23, 2016 by richfiles

[richfiles]

Does Delta V for next node show a live updated value for whatever projected delta-V expenditure a node will need, live as the node updates (as you edit). The reason I ask, is I need to be able to know both the live value (for both setting and burning), as well as the total Node Delta-V to represent a node that is set (not being edited). Is there any way to know that a maneuver node is "set" as opposed to being edited? I mean, I can guesstimate stuff my assuming the Delta V for next node value is assumed set if any warp or thrust factors are triggered, but that only works from a zero acceleration state. If I am burning and setting up a maneuver node as I burn (I realize this isn't very accurate, and that it results in the maneuver node being off till you readjust it again (after you stop burning), but it's certainly a thing that can be done. Also... I'm not sure if I saw an estimated burn time value being transmitted. I'd need that too.

What I'm aiming to do is to use a stepper and threaded rod assembly, plus a second smooth rod, to create a sliding carriage. No that carriage, will be a triangular green LED to serve as a pointer, and a green LED display to display delta-V and burn time, on the carriage. The carriage would have an Arduino Pro Mini mounted on the back, and would use a cable I have (LOTS of scrap from my old job) that was meant to carry power to a moving assembly.

Long story short, i want to recreate the burn display on the right of the navball in KSP, in actual hardware. To do that, I need:

Total delta-v (next node)
Remaining delta-v (next node)
Estimated Burn Time (Next Node)

Is it possible to get these numbers?
Thanks!

**EDIT**
What about a "Node Locked" bit? It wouldn't take very much data in the packet... FAR better than a whole extra float! Basically, Node locked would be low while adjusting a maneuver node, and would ho high when you are no longer adjusting. Whatever value node delta-v is at when Node Locked goes high, is the value to be copied into a Total Node Delta-V variable. Make sense? This makes it super easy to have the Arduino be able to update a percent of X value for displaying via an analog meter (or in my case, a servometric meter) for maneuver node burns.

Having the estimated burn time would also be awesome. We could do things like divide the number by 2 in the Arduino and feed it to an event alarm, display it, etc!
 

Edited May 26, 2016 by richfiles

[stibbons]

3 hours ago, richfiles said:

Total delta-v (next node)
Remaining delta-v (next node)
Estimated Burn Time (Next Node)

The game doesn't export anything relating to starting or "total" dV for a maneuver (that I could see, would love to be corrected). And I wasn't satisfied with any of the heuristics I could come up with in half an hour of pondering when this last came up a couple weeks ago.

Estimated burn time would have to be calculated plugin side, based on maneuver delta V and thrust available in the current stage. But it's not impossible.

3 hours ago, richfiles said:

Node locked would be low while adjusting a maneuver node, and would ho high when you are no longer adjusting

That's the thing: How do you tell when the node isn't being adjusted? The best I've come up with is a collection of naive assumptions working together. dV only increases via manipulation. If dV remains stable for n seconds, assume the node isn't being manipulated any more (I personally hate this one). Start doing complex and expensive measurements of the rate of change and make assumptions about maximum thrust / how finely people are able to tune nodes. Assume a dead zone around 0.

All of that feels so much more messy and error-prone than just putting a lock toggle on the side of the dV display.

[richfiles]

Bummer. I was really hoping whether a node was being edited or not could be exported. Same for the estimated burn time. 

I think that maybe a delta-V total reset button would be fair. A manual lock for setting the total delta-V to whatever the node delta-V is at at the moment. I'd be fine with a guesstimate function that looks at changes within a short window. If any value goes up, assume editing. If any value goes down... Ehh... That's touch, especially if you're close to the node you just set. Eeewwww! manual stuff!  It's okay though, I have a ton of unused keys that need jobs on my DSKY, and it's RIGHT NEXT to where this meter/display hybrid thingy™ will be!

Is there something special about the Estimated Burn time, or the game state that defines whether the game is editing a node... Are the so closed off that we have no access to them? Have we not found those variables? I'm just a little curious why we have access to some variables, at the plug-in end, but not others? What is it that defines that cutoff? Sorry! It's my newbishness to programming that leaves me not getting the whys and the hows behind this stuff. Obviously, I know the plugin doesn't transmit those pieces of data, but my curiosity is still there. Is this similar to the reason we don't have the ability to toggle the map or precision mode either?

[stibbons]

1 hour ago, richfiles said:

Is there something special about the Estimated Burn time, or the game state that defines whether the game is editing a node... Are the so closed off that we have no access to them?

I'm going by what is documented in the unofficial KSP API docs:

They have an automatically generated list of all of the public objects available, and user-provided documentation on how those objects work. The ManeuverNode class just plain doesn't export any information about estimated burn time. I even took a quick glance at the source for the BetterBurnTime mod, and it looks like the mod is doing exactly what I mentioned above; tracking engines in the current stage, adding up total thrust, and calculating burn time base on current dV.

As for defining a "node is being edited" state, still no idea. But, poking around the API a little more, I suppose one could in theory hook in to the OnGizmoUpdated callback on the Maneuver Gizmo, and record the current dV after updating as "total" for the node.

 

[zitronen]

What I always wondered is if there's a way to directly read the values from the UI.