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

[Sputnix]

what about 1.0.4?

Done some heavy testing today. Working 100% with the current steam release (1.0.4.861).

public float RAlt; //15 radar altitude (m)

public float Alt; //16 altitude above sea level (m)

As an aside, can someone explain to me the difference between these two?

[i'm guessing one works beyond the confines of Kerbin, and the other doesn't? ]

[stibbons]

Nope. Alt is your current altitude above sea level. Ralt is radar altitude - your height above ground level.

If you've just landed on the peak of a mountain that's 3000m high, Alt will read 3000 and Ralt will read 0.

Edited July 1, 2015 by stibbons

[zitronen]

SOINumber is just what SOI you're in now, isn't it? I'd like to set a flag when I'm on a trajectory that intercepts something else. So you'd be able to fly a Mun mission by:

* Achieve LKO.

* Wait until the Mun comes over the horizon.

* Start burning prograde.

* Wait until light on board turns on, indicating orbit now intercepts Mun.

* Stop burning.

* Wait until SOINumber indicates you're now in Mun's SOI.

* Burn to set periapsis.

* Wait until you're at PE.

* Burn retrograde to circularise.

Well I guess the best way would be if I can output existence of the next patch in patched conics and its PE and AP.

Done some heavy testing today. Working 100% with the current steam release (1.0.4.861).

Nice thanks.

[stibbons]

Well I guess the best way would be if I can output existence of the next patch in patched conics and its PE and AP.

I hadn't thought as far ahead as updating the plugin yet.

But yeah, looking at the Orbit class, it seems like walking the list of patches is an easy enough problem to solve. Would it be enough to just get the next patch, or is there value in looking further ahead? Watching how patches transition would let you make educated guesses as to what's happening, and pull off stunts like showing Duna AP while still burning in Kerbin's orbit on a transfer.

[Sputnix]

Nope. Alt is your current altitude above sea level. Ralt is radar altitude - your height above ground level.

If you've just landed on the peak of a mountain that's 3000m high, Alt will read 3000 and Ralt will read 0.

That makes sense; That would also mean the in-game altimeter (at least, default) is based on Alt.

Thank you for the clarification

[Sputnix]

So I've worked out how to get the VData to output to my TFT/LCD (using dtostrf).

I've got most of the TFT/LCD running in the 'utilities' tab (seemed to be the best place; TAPOR also found that this was the best place for the 7-segment displays, and I followed suit with my own, and also found that the TFT/LCD code worked best from there). The only code that isn't there is the 'start up' text, which resides in the setup function.

Question: Has anyone found a way to slow the refresh rate / cycle? I can't seem to work out how best to do this so that it can actually become readable [you can see the associated video to see what I mean].

I'm using the Mega, with proper hardware SPI being used; and I used this guide + associated code [ https://www.arduino.cc/en/Guide/TFT#toc10 ] to get my head around outputting data on the TFT / LCD.

I'm also using the inbuilt TFT library (which apparently extends the adafruit ones).

[zitronen]

Question: Has anyone found a way to slow the refresh rate / cycle? I can't seem to work out how best to do this so that it can actually become readable [you can see the associated video to see what I mean].

You can change the rate data is sent through the plugin in the .cfg file, but that will slow down all the data. You can try adding some code that only updates the display after every 2 or 3 packets?

byte k = 0;

...

if (k == 1){
dostuff();
k=0;
}
else {
k++;
}

[Sputnix]

You can change the rate data is sent through the plugin in the .cfg file, but that will slow down all the data. You can try adding some code that only updates the display after every 2 or 3 packets?

byte k = 0;

...

if (k == 1){
dostuff();
k=0;
}
else {
k++;
}

Thanks for the prompt reply, and suggestion

I'll give that a try!

I had originally tried using delay(int) but there were issues with that (apart from stopping the whole program), it also seemed to work for three cycles and then stopped displaying any data (no idea what's going on there). I suspect your suggestion of ignoring every other packet is likely to be a winner.

UPDATE:

Zitronen, you rock!

That works beautifully.

I modified the code a bit more too; so that the existing displayed data is 'covered up' by a black rectangle instead.

I plan on further modifying it so that if the respective fuel isn't in use (or has run out), there isn't a constant refresh / update 'flash'.

Sample video of it working; From left to right -- Update every 1 cycle (K = 1), 3 cycles (K = 3) and 2 cycles (K=2):

Edited July 5, 2015 by Sputnix

[stibbons]

Hey zitronen, any chance you could update the github repository? Looks like the last version there is 0.17.1.

[zitronen]

Hey zitronen, any chance you could update the github repository? Looks like the last version there is 0.17.1.

Oh oops, should be good now.

[stibbons]

Thanks.

I had a play with a couple of ideas for retrieving the next relevant patch, and came up with something that should work well in most scenarios. It adds FarSOI, FarAp and FarPe to the VesselData packet, and shows details of an intercept with the next moon or planet, or your solar orbit if you're on an escape trajectory. It's late here so I've only properly tested it on Mun intercepts, escape orbits and a Duna intercept. Will play around with it some more the next few days before I stick it in a PR.

[Cbrollin]

Hello everybody,

First off I would like to say that this is an awesome plugin, and has helped me so much. Thanks zitronen and all who have contributed!!

I am in the process of building a controller/display (why else would I need this plugin). I have a couple of illuminated buttons that I wanted to display info from the game. As in the staging button will reflect the staging light that blinks in game. Also, I wanted a map mode button which would light up when in the Map. I know that map view hasnt been implemented yet.

So I took it upon myself to get into the code and mess around a bit. I have edited the plugin to receive info from the Staging and MapView classes. The stage button blinks when on the ground, is solid when flying and there is another stage left, and is unlit when there are no stages left. I put in 2 new variables into VesselData to reflect TotalStage and CurrentStage.

I also got Map View to work mostly. It is still a little buggy. You can enter and exit Map View by calling MapView.EnterMapView() or MapView.ExitMapView(). The only issue I am having is if you enter Map mode using the game interface (using the mouse), and try to exit using the button, it doesnt work. Otherwise the button will enter and exit Map mode fine.

I am pretty new to forums in general, but I can try to post the snippits of code that I added.

[Sputnix]

I have edited the plugin to receive info from the Staging and MapView classes. The stage button blinks when on the ground, is solid when flying and there is another stage left, and is unlit when there are no stages left. I put in 2 new variables into VesselData to reflect TotalStage and CurrentStage.

I am pretty new to forums in general, but I can try to post the snippits of code that I added.

Hey that's awesome! Great work!

I actually requested this recently from Zitronen (I want to disable the staging when there are no more stages, and only have the Abort active in the first and final stages).

If you could share the code, that'd be awesome

[or possibly send it directly to Zitronen via a PM - to save some time implementing it]

Since 1.0.4 we've had to become much more careful about when to deploy our parachutes.

Handily squad put a readout in the parachute sub menu telling you if its safe to deploy or not. . . problem is its buried in that submenu

I'd like a mod to take that readout and make it far more visible. The way I currently do it is is to right click a parachute and keep that menu open throughout the whole decent which is messy and and a PIA.

Surely it shouldn't be too difficult to take the readout from whatever variable is giving safe, risky, unsafe and convert it into a traffic light signal for each chute.

I guess ideally I'd display it next to the relevant chute in the staging set up down the left hand side but I'm guessing that would be tricky.

Alternatively just a window containing a readout on the "safe status" of each stage containing parachutes.

Zitronen-- I just became away of the above feature;

Any chance we could get that as Boolean output?

Sounds like a useful tool to put a visual indicator to (Red / Green LED anyone? )

Thank you

Edited July 7, 2015 by Sputnix

[zitronen]

Yeah nice work! If you can share the staging code (I was not sure where to get the total number of stages) that would be great. Once you can get the map view stuff working properly we can add that as well.

We should have a look at (vote?) what to add next. There is limited space left in the packet, so we don't want to go too crazy.

I'm pretty sure the parachute thing is based on indicated air speed or Mach, which are already in the packet. Anyone want to do some experiments?

[faeryty]

Just wanted to add my thanks to zitronen for this plugin. It's given me the motivation to actually learn some electronics and experiment with the arduino. I'm just getting started but I had a play around got an altimeter working on 7segment LEDs quite straightforwardly. Next will be apopasis and periapsis, and then something more adventurous. I may also get around to learning C# and experiment with breaking modding KSP too, because I don't want to come running and bugging you every time I want something that's not implemented in the plugin yet and if I can help contribute then great.

But that's a way off yet I expect and so I'll respond to your call for a vote for what to add in next! I add my vote to the people wanting TWR or the values needed to calculate it for ourselves. Also if I'm reading the first post right, you don't currently output deltaV remaining or deltaV for the current stage. They could come in handy too, though I don't have any direct plans to use them and without looking into what the game exposes I imagine they could be a pain to calculate. I suppose outputting dry mass total would be sufficent for stage deltaV and would help with TWR but would still leave you looping through all engines, and total deltaV would also involve looping through all parts.

tl;dr: great mod. thanks for the work. TWR next please.

[Cbrollin]

Yeah nice work! If you can share the staging code (I was not sure where to get the total number of stages) that would be great. Once you can get the map view stuff working properly we can add that as well.

Thanks. I am going to try to look at switching between docking and staging also, since I would like that to be implemented in my controller. Also, I dont know much about the serial side, but I did assume that there was some maximum packet size. Is there some hard limit on how many variables we will be able to put in VesselData? Just wondering so I can maybe consolidate some of the variables I created.

Ok. My code is below.

added to VesselData

public int CurrentStage; //51 Cbrollins code here - Current stage, total stage and map status
public int TotalStage; //52
public int MapStatus; //53

I used the public byte Mode to transmit the state for the map button

added to struct VesselControls

public Boolean MapMode; //Cbrollin - used in Map code later on. We may be able to use an int and convert the correct bit to a boolean

added to private void VesselControls()

VControls.MapMode = BitMathByte(CPacket.Mode, 2); //Cbrollin - I added this to convert the correct byte in Mode to a boolean. There is corresponding code in the arduino portion as well

added to void Update - #region outputs

KSPSerialPort.VData.CurrentStage = (int)Staging.CurrentStage; // Cbrollin - here is where we get the info from the staging class
KSPSerialPort.VData.TotalStage = (int)Staging.StageCount;

KSPSerialPort.VData.MapStatus = (int)Convert.ToInt32(MapView.MapIsEnabled); //Cbrollin - Getting info on Map status from MapView class

added to void Update - #region inputs

//Cbrollin - Implementing changing to Map View using MapView class - this should be compatible with Zitronens Mode usage for stage, docking, map, etc


if (KSPSerialPort.VControls.MapMode != KSPSerialPort.VControlsOld.MapMode && KSPSerialPort.VData.MapStatus == 0)
{
MapView.EnterMapView();
KSPSerialPort.VControlsOld.MapMode = KSPSerialPort.VControls.MapMode;
}
else if (KSPSerialPort.VControls.MapMode != KSPSerialPort.VControlsOld.MapMode && KSPSerialPort.VData.MapStatus == 1) //Checking both Mode status and Map status so the ExitMapView isnt called constantly
{
MapView.ExitMapView();
KSPSerialPort.VControlsOld.MapMode = KSPSerialPort.VControls.MapMode;
}

Then I had to add corresponding code in the arduino code, variables and whatnot.

This is added to output - void controls, with some debouncing because I have a momentary switch. Also for regular arduino, it should just be digitalRead(MAPPIN). The mcp is because I am using an IO expander.

readingMap = mcp.digitalRead(MAPPIN);

if (readingMap == LOW && previousMap == HIGH && millis() - time > debounce)
{
if (VData.MapStatus == 1)
Mode(MAP, LOW);
else
Mode(MAP, HIGH);
}
previousMap = readingMap;

Then I had to add another section to output

void Mode(byte n, boolean s)
{
if (s)
CPacket.Mode |= (1 << n); // forces nth bit of x to be 1. all other bits left alone.
else
CPacket.Mode &= ~(1 << n); // forces nth bit of x to be 0. all other bits left alone.
}

That is all that I have really changed so far.

Edited July 11, 2015 by Cbrollin

[richfiles]

Zitronen-- I just became away [**aware?**] of the above feature;

Any chance we could get that as Boolean output?

Sounds like a useful tool to put a visual indicator to (Red / Green LED anyone?)

Yeah, i was thinking about the safe to deploy parachute status, and was thinking about how I have lots of lights on my future DSKY that need to actually do something!

[Sputnix]

Yeah nice work! If you can share the staging code (I was not sure where to get the total number of stages) that would be great. Once you can get the map view stuff working properly we can add that as well.

We should have a look at (vote?) what to add next. There is limited space left in the packet, so we don't want to go too crazy.

I'm pretty sure the parachute thing is based on indicated air speed or Mach, which are already in the packet. Anyone want to do some experiments?

Haha.. You're probably very right there. I really need to think about this stuff a bit more. I'll try work out what the formula is

I've just finished wiring up my Console. I'm just putting it together - right this second - so I'll configure all the inputs / outputs, make sure they're working, and start working on this stuff

As an aside - Zitronen, can you please explain the purpose of the 'ControlStatus' function / Action Group Status IDs?

I'm trying to work out how to use them / why they exist. Thanks

Richfiles: Yeah, that was a slight typo there

I'll create a thread for code snippets / tabs so that others can re-use once I've come up with stuff

Edited July 8, 2015 by Sputnix

[Freshmeat]

Wow, things are on a roll here.

@Sputnix: Gratulations. I am up to my ear in solder right now.

@zitronen: Would it be possible to add the pitch and heading of prograde to the packet? I can think of some uses in ascent/decent assists. Also, there was talk about adding SAS modes to the cpacket. Did that project stall?

[zitronen]

Ok so we are using 189 out of 255 bytes in the packet, so 66 bytes left. It's not a disaster if we run out of bytes, since we can just add another packet. However, since RAM is very limited on the AVR chips (255 bytes is a large chunk of RAM!), I would still avoid using too much.

So currently we have requests for:

TWR: This has been discussed before, too difficult for me to do. I would have to looping through all the parts, find all the active engines, checking their max thrust and thrust vector (imagine two engine facing each other, TWR would be 0). Too much work. Plus you can calculate TWR (at least in space) by firing your engine for a bit and look at acceleration, you can script this in your arduino code.

DeltaV: same as above

DeltaV remaining: unfortunately the information is not available in the manoeuvre node object, I have no idea where to get it from.

Current stage: will add as byte, so 255 stages max (surely enough for everybody?)

Total stages: will add as byte, so 255 stages max, I didn't know it's as simple as Staging.StageCount! Thanks Cbrollin

Prograde + retrograde pitch and heading: will add as 4 floats (16 bytes), if I can figure out where to find the data.

PE, AP, and SOI name for next orbit patch: 2 floats, 1 byte (9 bytes total) can be added if people want it, could be useful for crazy people like stibbons

Map view: will experiment with this some more, will only add it if it's working completely. It's hard enough getting hardware working, I'd like to avoid glitchy stuff.

SAS modes: not stalled, just completely forgot about them will have a look at it again.

For the guys looking for a safe to deploy parachute thingie, I suspect it's base on indicated air speed, which is already included. I think you only need to check for IAS < 250 or something.

[stibbons]

(I'm also crazy enough to be completely happy maintaining my own fork with bits nobody else wants )

Prograde + retrograde pitch and heading: will add as 4 floats (16 bytes), if I can figure out where to find the data.

You're already using Orbit.GetVel for orbital velocity. Pitch and heading are just the x and y components of that vector, aren't they?

I suspect only sending prograde would cut down on packet size, retrograde can be calculated by flipping the heading. The extra space would be better used sending orbit normal and radial vectors.

[zitronen]

You're already using Orbit.GetVel for orbital velocity. Pitch and heading are just the x and y components of that vector, aren't they?

If only it was that easy... all the orbital vectors are based on the non-rotating inertial reference frame, just figuring out which way is actually up will require some quaternion math... also you will probably want surface velocity for when you are in atmo, so I will need to send both... I had to steal some code from mechjeb just to calculate roll pitch yaw.

You point about retrograde is really good though, I didn't think of that.

I mean people complain about KSP this and that, but man making a game is hard enough in normal Euclidean space, let alone this shifting reference frame system with all the floating point problems!

[stibbons]

Yeah, I read the attitude code from mechjeb this morning and cried a little bit. I had no idea reference frames were so complicated though, goes to show how much of a plugin n00b I am.

[kungfufishstick]

Over the past couple of days I have been looking over the thread. This is really awesome work from start to current.

I am very new to this all and was curious if the tutorials on the first page are the only tutorials available. I would like to work on my own control panel but am having trouble wrapping my head around the coding portion.

If no extra tutorials are available, would someone like PM with me to help me along?

Currently the two main things I want to do are staging and throttle control. As of right now I only have the parts supplied with the Arduino starter kit (so push buttons and 10 K potentiometers).

[stibbons]

Almost everybody who's building projects using this plugin are publishing build logs and source code. You should also have a look through the custom hardware repository thread, and look for [Hardware] tagged threads in the Fan Works forum for examples.