[1.2.1][alpha/WIP] Kerbal Processing Unit — part models needed!

[soundnfury]

KPU (Kerbal Processing Unit) is an automation mod, somewhat like kOS, but the intention is to give it a tech tree progression for career mode. As well as more capable processors, you'll unlock the various sensors you need to obtain different inputs to your programs.

The automation language is fairly spartan, with a resemblance to FORTH.

KPU is mainly aimed at RemoteTech users who want to be able to land probes on distant airless bodies like Tylo, in a more realistic way than trial-and-error-and-hit-F9-to-try-again.

It's currently a work in progress; most of the actual automation functionality is there, with enough inputs and outputs wired up to support many useful programs. However, because I am Not An Artist, I've just copied existing models for the parts I've added; PM me if you want to help.

Source code

... is on GitHub at https://github.com/ec429/kpu_mod

Screenshot

KPU driving my rover "Spirit-1" across Duna.

Download

For KSP 1.2.1

http://jttlov.no-ip.org/tar/kpu-alpha11.zip

Edited November 12, 2016 by soundnfury
alpha11 released

[soundnfury]

alpha1 released - adds a bunch of new inputs, mainly from the Kerbin Navigational System parts, several new outputs, and a few fixes/improvements.

Download link in the OP.

An example of a program made possible by this version is the following automatic launch to LKO:

IF OR < orbApoapsis 72000 AND > longitude + orbPeriapsisLongitude 176~ < orbPeriapsis 70500 THEN @throttle.incr 400
ON < vesselTmr 0.1 DO @stage.set true
ON < altitude 1000 DO @orient.set , 90 84
ON > altitude 1000 DO @orient.set srfPrograde
ON > altitude 30000 DO @orient.set orbPrograde
IF AND > orbApoapsis 72000 OR < longitude + orbPeriapsisLongitude 176~ > orbPeriapsis 70500 THEN @throttle.decr 400
ON > altitude 70000 DO ; @solarPanels.set true @rtAntennas.set true

With a suitable vessel on the launchpad, running the above program will fly it all the way up to an orbit clear of Kerbin's atmosphere with no user input!

Requires the KNS or LORAN part for the inputs, and a KE-7 KPU.

Edited July 5, 2015 by soundnfury

[soundnfury]

alpha2 released - adds inputs and outputs for rovers, latches (single-bit registers for stateful code) and error trapping (so you can put your spacecraft into a 'safe mode' if anything goes wrong).

Updated download link in the OP.

[soundnfury]

alpha3 released - adds hibernation (because that Kelliot KE-7 really does draw a lot of electricCharge) and timers.

Updated download link in the OP.

[YauS]

I think the syntax is hardly to understand. Could you give me an introduction?

[SnowWhite]

What kind of models do you need? I can help you with it.

[soundnfury]

YauS said:

I think the syntax is hardly to understand.

Yes. Yes it is.

Quote

Could you give me an introduction?

I'll try.

Ok so there's two layers of the syntax, statement and expression. The statement has one of three forms:

ON expression DO expression
IF expression THEN expression
ON expression HIBERNATE expression

(There's also a fourth form, the comment - any line starting with # is a comment.)

ON/DO means "whenever the first expression becomes true (i.e. on a positive edge), execute the second expression".

IF/THEN means "as long as the first expression is true, keep doing the second expression".

ON/HIBERNATE means "on a positive edge of the first expression, put the processor into hibernation until the second expression becomes true".

The expressions are a bit more complicated; they're based on 'Prefix Notation'. Conventional syntax is what's called 'Infix Notation', where the operator goes in between its two operands. The downside of this is that it requires operator precedence rules and brackets to disambiguate the syntax tree. Prefix Notation is much simpler to parse: the operator goes first, followed by the operands. So instead of "1 + 2", we write "+ 1 2"; instead of "(1 + 2) * 3" we write "* + 1 2 3".

Parsing relies on the knowledge of how many operands each operator takes, and is essentially stack-based. So to parse "* + 1 2 3", we read from the left with an initially empty stack. We first encounter a *, it's an operator so we put it on the stack. Now we come to +, another operator so we push that to the stack too. Next is a 1, that's the first operand to the +, and we push it. At this point our stack holds * + 1. Now we encounter a 2, and we have enough operands to evaluate, + 1 2 becomes 1+2=3, our stack is * 3. Lastly we read a 3, we can evaluate * 3 3 as 9.

(In practice that's not how the implementation does it, it stores the abstract syntax tree for various reasons. But it's a useful mental model.)

As well as the usual arithmetic operators and numeric literals, we have comparison operators — "< 1 2" is true while "> 1 2" is false — and identifiers, which name inputs (like srfHeight), outputs (like wheelMotors), and also the boolean constants "true" and "false". The logical operators AND and OR short-circuit, i.e. the second operand will only be evaluated if needed. So in "AND false true", the "true" will never be evaluated because anything ANDed with false is false.

The handling of output actions is another place where things get a little weird, as we have four more operators: at (@), semi (;), comma (,) and dot (.). At and dot are used together, to construct an action: "@identifier.method value" means "run method on identifier with argument value". So for instance "@throttle.set 100" means "set the throttle to 100%".

Semi is used to concatenate multiple actions; because it's a prefix operator it looks a bit weird. If you have n actions, you will need to prefix them with n-1 semis. (Formally, it takes two expressions, evaluates both of them, and returns a value of void type.)

Comma is somewhat similar, concatenating multiple values into a list. This is currently only needed for orienting to a fixed heading/pitch, e.g. "@orient.set , 90 84" which means "point the rocket 6° eastwards of vertical".

One last weirdness is the built-in angle type. Some input values (such as srfHeading or orbPeriapsisLongitude) have type 'angle' rather than 'double', as does any numeric literal ending in ~ (chosen because it's easier to type than °). Arithmetic on these is performed modulo 360, and the < and > operators work according to the shortest path, so for example 0° is less than 90° but greater than 270°. These can be coerced to 'double' by arithmetic with a 'double' type, so "+ 0 90~" is 90 rather than 90~.

For an example, here is a line from my rover program:

IF < - srfHeading 30~ 180 THEN @wheelSteering.set * 5 + 0 - srfHeading 30~

Translated into pseudocode, this reads:

IF (srfHeading - 30°) < 180 THEN set wheelSteering to 5 * (srfHeading - 30°)

except that the addition of 0 to (srfHeading - 30°) converts it to a double.

Hopefully that's at least somewhat clear...

Edited March 18, 2016 by soundnfury
Fix up Unicode borkage from the forum migration

[soundnfury]

What kind of models do you need? I can help you with it.

The list of parts desired is in https://raw.githubusercontent.com/ec429/kpu_mod/master/roadmap; the most urgent ones are probably those that already have part cfgs:

• Kelliot 4040: I'm thinking something like a circuit board with some chips and LEDs on it. Bonus points if you can make them flash in random-seeming patterns.
  
• Kelliot KE-7: probably something rather like the ER-7500 model I'm using currently: old-timey computer bits like tapes, blinkenlights, relays, valves (tubes), maybe even some core memory.
  
• PB FS-RA: maybe a little radar dish rotating on a spindle.
  
• Kybernetics KNS: some sort of radio aerial. Maybe a yagi just for the sheer incongruity of it.
  
• KI "Loran": like the KNS only more so. Perhaps a stacked yagi.
  

For more information on star trackers and stellar compasses, see yarchive; in fact the whole category is a treasure trove of space-related information.

[Overjay]

this actually looks promising, subscribed for moar

[soundnfury]

alpha4 released - adds integration with my new kappa-ray mod - now radiation can cause your kpu to glitch! If you don't want that, download the -nokappa version.

Updated download link in the OP.

[soundnfury]

alpha5 released - adds a bunch of new sensor parts, agencies and flags for the manufacturers (I particularly like the Kerbal Instruments logo), fixes sunDegrees handling (for PIR sensors), implements resolution for customHP[R] Orientation sensors, alters throttle handling to allow RemoteTech to run maneuvers while the KPU is running…

Updated download link in the OP.

[soundnfury]

alpha6 released - bug fixes, new parts (still no models ), and now built against KSP 1.0.4!

(Main reason for release is fixes & updates to kappa-ray.)

[LORDPrometheus]

alpha6 released - bug fixes, new parts (still no models ), and now built against KSP 1.0.4!

(Main reason for release is fixes & updates to kappa-ray.)

What sort of models are you looking for like descrive what you want and give me size parameters and I can probably get something put together before long

[soundnfury]

What sort of models are you looking for like descrive what you want and give me size parameters and I can probably get something put together before long

See my earlier post for some good parts to start with.

Size-wise, most of the sensors want to be on the same sort of scale as stock science parts like the seismometer and gravioli box (hence why I've chosen those parts for a lot of the placeholders). The processors should be slightly bigger; again, the placeholder parts are the right order of magnitude, except that the LITHP-M probably wants to be a bit bigger, like the KE-7 is. Everything (except the Inertial Platform) wants to be surface-attach, like the placeholders are.

For some of the parts that aren't mentioned in my earlier post:

• 8080 KPU: like the 4040 but with more components and a blue PCB.
  
• Mk1 Eyeball: a ball-shaped camera.
  
• "Spot" PIR: a camera with a hooded lens.
  
• The various star trackers / stellar compasses: small cameras on pivots / gimbals, maybe clusters of these to point in different directions. Ideally animated to pivot around jerkily as they 'sight' on different stars.
  
• Inertial Platform: actually it really should look quite similar to reaction wheels. Probably just re-texture it a bit to distinguish it?
  

But these are really just suggestions; I don't have strong ideas or opinions on what the parts should look like. You might prefer just to read the part descriptions and interpret them creatively. (I don't know what a typical modelling workflow is like, or how precise the requirements need to be.)

[soundnfury]

alpha7 released - adds a 'library' where you can save programs & re-use them on other probes. It displays the 'system requirements' (processor capabilities, IMEM, inputs used) of each program, colour-coded to indicate whether the current vessel supports it.

Saved programs are local to a savegame. There are two explanations for this:

(i) the practical reason. It's much easier to implement this way as I can just save everything in a Scenario node

(ii) the in-universe justification. The accumulated collection of debugged and tested programs is part of your Space Program's technological base; other Space Programs shouldn't be allowed to steal it!

Updated download link in the OP.

[soundnfury]

alpha8 released - minor bugfixes and rebuilt against KSP 1.0.5.

Updated download link in the OP.

[soundnfury]

alpha9 released - ported to KSP 1.1.x, improved the Library's determination of used inputs, other small fixes.

Updated download link in the OP.

[soundnfury]

alpha10 released - ported to KSP 1.2.1, ripped out kappa-ray integration, and improved my build setup a little bit.

[Deimos Rast]

1 hour ago, soundnfury said:

alpha10 released - ported to KSP 1.2.1, ripped out kappa-ray integration, and improved my build setup a little bit.

latest MM is 2.7.3 btw.

Is all the documentation in the readme (which is quite a readme by the way!)?

[soundnfury]

alpha11 released - adds support for IPIs (Inter-Processor Interrupts) allowing multiple KPU processors on a vessel to work together.

12 hours ago, Deimos Rast said:

Is all the documentation in the readme (which is quite a readme by the way!)?

Yeah, the readme should cover everything.  There's also a bit of a language tutorial upthread, for those not fluent in BNF syntax descriptions.