[WIP, Plugin, Parts] (2014-10-16) LaserDist 0.5 for KSP 0.9, Alpha

[erendrake]

As I understand multiple laser sensors are being detected by kOS. What I have in mind for my project is the following:

Laser1 measures a distance < 0.2 meter - kOS activates action group 1 - Laser1 measures distance > 0.2 meter - kOS deactivates action group 1.

Can kOS run multiple of these processes at once? For example 8 lasers with 8 action groups all at different times?

For this one, I would need 7 lasers.

It should have no issue, the biggest trouble you would have is figuring out which laser goes with each action. The next version of kOS has a few pretty awesome tools that steven wrote to make querying parts easier.

[Dunbaratu]

As I understand multiple laser sensors are being detected by kOS. What I have in mind for my project is the following:

Laser1 measures a distance < 0.2 meter - kOS activates action group 1 - Laser1 measures distance > 0.2 meter - kOS deactivates action group 1.

Can kOS run multiple of these processes at once? For example 8 lasers with 8 action groups all at different times?

It should be able to. You can address individual part modules on individual parts (or you will in 0.15, I mean). The difficulty is in identifiying which one is which when you have a very symmetrical design like this.

But the even bigger problem with using laserdist for what you're doing is that I hit a wall trying to diagnose the behavior of unity's raycast when it comes to detecting hits on parts of the same vessel. It seems to have some very nasty buggy timing issues where depending on what order Unity chooses to update different parts of the KSP system in, it sometimes performs the raycast when not all the parts are in the expected location. (They don't all move to the new position in one lock step. One part at a time, it moves each part to its new location for the next frame. Depending on the order it did that in, the laser ends up being out of sync with the other parts of the vessel *some* of the time and thus missing them. It's a real mess and the advice from the user community runs directly contrary to the documentation from Unity itself, so I'm having to do lots of experiments to work out what's the right answer.)

The effect of all of this is that I may have to release a lesser version of laserdist that only works on terrain and not ship parts as a first go of it. It's also exacerbated by the fact that the problem seems to depend on your computer's speed. It's a timing issue which means if I ever to get it working I don't feel confident that I *really* fixed it for everybody.

So for the time being I put laserdist on hold for a week or two while I work on kOS more. I want to release laserdist simultaneously with the 0.15 release of kOS, and the problems in kOS are, frankly, easier to deal with because they don't involve performing experiments to learn what a hidden undocumented black box of highly timing-sensitive code is doing.

[Azimech]

Hmmm ... I'm almost wondering if two special parts touching each other would be a better way to go, for me. I don't suppose kOS has any collision detection?

[Guest]

Separate window for rangefinder readout is great idea. Also RPM integration would be nice. I understand this mod is intended for automated probe cores, but Kerbals want to use it too.

[Dunbaratu]

I may come back to this to look at the raycast-to-ship-parts problem. The main reason I haven't is that kOS needs my attention first. Given what little I've understood, I think that I need to move my ray cast check from Update to LateUpdate, despite the fact that Unity's documents show it happening in Update. I noticed a little hint in the docs for LateUpdate() that you use it to deal with the camera because of objects that might have moved during Update() calls.... and that got me very suspicious, because I thought objects moved during FixedUpdate's rather than during Updates. But if they move during Updates, then that means putting the call in update or fixed update will BOTH be the wrong place for it. I need a guarantee that the game has stopped updating object positions for the frame before I call the ray cast. if I'm calling it when updates may be half done, that's why I sometimes miss objects.

I thought that object positions only update during FixedUpdate, but that one-off comment in the Unity docs hints at them being updated potentially within Update()'s as well.

[togfox]

Not sure if this will work with 0.90. Has anyone tried it? And how does kOS access the 'distance' reading once activated. There are a lot of comments like "when kOS is updated ..." etc so, just trying to work out what's possible and what's not. Thx.

[Dunbaratu]

Not sure if this will work with 0.90. Has anyone tried it? And how does kOS access the 'distance' reading once activated. There are a lot of comments like "when kOS is updated ..." etc so, just trying to work out what's possible and what's not. Thx.

Getting a list of all laserdist modules on the ship (there should be one such module per laserdist part):

set distModules to ship:modulesnamed("laserdistmodule").

For one such module (the zero-th one), turning it on, off (and making the laser visible):

// Turning it on:
distModules[0]:SETFIELD("ENABLED", true).
distModules[0]:SETFIELD("VISIBLE", true).

// Turning it off:
distModules[0]:SETFIELD("ENABLED", false).
distModules[0]:SETFIELD("VISIBLE", false).

Getting the reading (only works when enabled = true):

set metersDistance to distModules[0]:GETFIELD("DISTANCE").

kOS supports pretty much any module now in this way, provided the module gives the users a visible reading on the rightclick menu of the part. The names above ("ENABLED","VISIBLE", and "DISTANCE") are taken directly from the user interface GUI labels used on the right click menu.

A more in depth explanation of how to get a kOS script to interact with other modules, using its generic partmodule system, is here: http://ksp-kos.github.io/KOS_DOC/general/parts_and_partmodules.html

[drtedastro]

Hello to all.

I really miss this mod and was wondering if anyone has been able to make it work with 0.90 ???

I have tried, but no distances are given and the beam seems to flake out sometimes.

If anyone knows what needs done, I will give it a shot.

This simple little mod was great and I used it on lots of my craft for various reasons...

Hope someone has some ideas / answers and or methods to get it working again.

Thanks...

[Dunbaratu]

Hello to all.

I really miss this mod and was wondering if anyone has been able to make it work with 0.90 ???

uhm... it does work in 0.90 - at least as well as it never did in the past.

Meaning - you can shoot the laser at terrain and it works fine, but to shoot it at parts of vessels it randomly shoots right through

them half the time. I fought and fought and fought and could not get it to fix that problem. It has something to do with the timings of when the game engine moves the pieces "in its head" before showing the move - sometimes it has moved some but not all the parts of the ship to the XYZ coords they'll have next time, at the moment the laser does its raycast calculation.

Most of the advice on how to fix it from Unity programmers didn't understand that as a mod writer, I'm not in a position to get to decide when the ship parts get moved. That's in SQUAD's control and I can't do anything about it. (Most of the advice was about how to sync up when my laser part moves versus when the rest of the objects move - which I have zero control over.) Some advice said raycast belongs in physics update, other advice says no it belongs in normal update (where animation frames happen). I've tried both. No help. It slightly changes WHEN the problem occurs, but not WHETHER it occurs.

What I really need to fix it, I think, is a callback that I can be guaranteed Unity will only call *in between* all the objects trying to move themselves to their new positions, not something that gets called intermingled *during* all the callbacks when all the other objects in the game are choosing to move themselves. If some objects are moving themselves during fixedupdate, and others are moving themselves during update (which seems to be the case as far as I can tell), then neither putting the check in update NOR in fixedupdate will actually work.

I need it called *between* updates, while every object in the universe is now frozen at whatever state it was in the last time all the positioning settled down and got synced up - at least that's what I *think* is wrong. I don't know of a callback that does that. There seems to be one that gets called just after all the other updates, called lateupdate, but I think what I need is a similar one called latefixedupdate, but that doesn't seem to exist.

At any rate trying again and again to just randomly guess what the heck unity and KSP were doing, without the ability to find out or run a debugger and therefore only getting info from debug dump printouts (which, since it's a timing issue I can't tell if they're changing the behaviour merely by existing in the first place), I sort of gave up for a while.

The code is currently in a bit of a messy state because of all my abortive attempts to try different things to get evidence on what was going on. It doesn't currently look much like my original design, or how I'd prefer it to look. I started doing some really wonky things with it that probably are utterly irrelevant to the problem - like trying to remember a previous result from the last update and buffer it to spit out if asked the value, and catch when the value suddenly gets a lot bigger , and demanding that it must stay bigger for several updates before the code will "believe" it. (I was trying to "fix" it by saying as long as at least ONE raycast got a hit recently, it will use that instead of the intermittent misses. That reduced the likelyhood of the problem but it still cropped up - it wasn't a real solution and it just left the code all cluttered with nonsense.)

I think the real solution is to figure out when the heck I can trigger the callback where it reliably won't be happening in the midst of the parts moving.

If you want to take a stab at fixing it, go right ahead.

I may come back to it after KSP 1.0 is out, just to see if it got any easier to deal with.

The primary reason I left it was that I also work on kOS, and LaserDist was sucking all my time away from things in kOS that I actually knew how implement properly without having to guess randomly with trial and error. I figured working on kOS was a better use of my time than sinking hours into a project with nothing to show for it.

Edited April 20, 2015 by Steven Mading

[Drew Kerman]

uhm... it does work in 0.90

Yes, but if you leave any mention of 0.25 in the title of a mod thread people will just assume it doesn't work in 0.90, and will then inquire about a 0.90 version without bothering to see if it actually does work in 0.90

[Dunbaratu]

Yes, but if you leave any mention of 0.25 in the title of a mod thread people will just assume it doesn't work in 0.90, and will then inquire about a 0.90 version without bothering to see if it actually does work in 0.90

I hadn't realized I left the title unchanged.

- - - Updated - - -

@ drtedastro :

Okay just to be certain I made sure to push the version I'd been using privately to github, and made a release zip of the version compiled against KSP 0.9. It should be usable for you.

[Drew Kerman]

I should also apologize to drtedastro because I didn't realize your quote of his post omitted the fact that he did try to see if it worked. With 1.0 around the corner there's been a recent spate of people coming back to the forums and asking about mods that haven't been listed as 0.90 compatible but actually are

[ganinian]

this is the most awesomestest thing i've ever seen

[FleshJeb]

Bumping this thread to check 1.x compatibility.

I'm a surveyor in real life, and I'm planning on making some surveying equipment in KSP. This is perfect. I'm going to mount the laser on the side (or inside!) of some HullCam VDS telescopes.

[lazaruz76]

I would also like to know if this is 1.x compatible, cause it think I just found my new aiming device for the freshly released winches in KAS. (I doubled the line length so this would be a big help in space with the harpoon)

[Guest]

Looks like it works in 1.0.4, although it not respect Remote Tech's "Out of control" condition.

I made a test rig, but forgot to add antenna, so it was sitting hopelessly on the pad, shining laser at the VAB, until chief janitor knocked it over with the broom.

What I wish to have is small sub-mod, that adds window with readout and "prev" "next" "on/off" buttons, accessible from blizzy's toolbar.

Edited July 29, 2015 by Guest

[Stuntaneous]

You could use kOS to check whether or not the craft is controllable, I imagine.

[Stuntaneous]

Yeah, it isn't straight forward but it's just an option. That mod sounds interesting. It'd be good to know which one you're thinking of.

Somewhat related, you can also interact with kOS over Telnet these days. And, there's the Telemachus mod that exposes a lot of in-game info for use outside.

[Cairol]

Hm. Would love to see this updated. I saw that cool video here and immediately had a couple of ideas for using this.

[Dunbaratu]

I just pushed an update for this to curse, spacedock, github, and ckan.  I'll call this official, and move further discussion over to a new thread in the main mods forum (not the "under development" forum here).

 

Any further discussion should go here into the new thread:

 

Edited June 13, 2016 by Steven Mading

[drtedastro]

just wanted to say thanks for update(s).

Also, would there be any way to display the laser distance as a small text display without having to use rmb?

 

just a thought.

Cheers.

[MAFman]

On 7/15/2014 at 3:20 AM, Steven Mading said:

LaserDist

[WIP, Plugin, Parts] (2014-10-16) LaserDist 0.5 for KSP 0.9, Alpha

Releases:

* https://github.com/Dunbaratu/LaserDist/releases

ZIP Download (See release page above):

* https://github.com/Dunbaratu/LaserDist/releases/download/v0.4/LaserDist.zip

Source Code Hosting site:

* https://github.com/Dunbaratu/LaserDist

License:

* GPL v3

Copyright © 2014 Steven Mading (aka Dunbaratu on Github)

[email protected]

This is a very small plugin. It makes a KSP Part that

measures straight line distances by laser.

The "Beamer 100x Disto-o-meter" Part aims a laser in a line

and then measures the distance in meters to the first object

the laser hits. The result is displayed in the right-click

menu for the part.

The laser can work over long distances - here it's measuring the

distance from a Kerbin orbit vessel to the Mun:

And even at those very long distances, the lasers can measure

rather small differences in distace, within reason (it has

an accuracy of 2 meters at this extreme range, to keep the

game from bogging down too much). In the screenshot below,

notice how the two lasers are returning different numbers for

their distance to the terrain very far away:

The direction of the laser is whichever way the laser gun is

pointed when you mounted it on the craft, as demonstrated here:

The electric draw for the laser is substantial. Each laser consumes

1 electric charge every 3 seconds that it's on.

Why does this Mod exist?

The intended purpose of this part is to be used in conjunction with

scripted autopilots like [kOS](https://github.com/KSP-KOS/KOS/releases), to

provide a way to for you to write scripted pilot software that can

see the distance to the ground (or anything else like a ship) along

the laser line. The reason this can be useful is so you can detect

things like terrain slope and mountains in the way. The default

radar altimiter in KSP only shows you the distance directly under

the craft.

In a nutshell, the purpose is to solve this problem shown in this picture:

This mod can let you read the distance along the blue line in the diagram.

Why isn't it inside kOS then?

There is more than one KSP mod project for the purpose of letting

users write scripted autopilots. Another such project currently under

development is Jebnix

My goal is to make this part script-engine-agnostic so it works with

any such mod. I've been working in kOS mostly, but I didn't want this

part to be kOS-specific because there's no particular reason it has

to be.

Information for other modders trying to use the part:

As long as the scripting autopilot is designed to be able to query

and/or set KSPFields on parts, it should be able to read the value of

the distance, and turn the laser on and off, as follows:

 

• KSPField: 'Distance' is a float - the number of meters being shown in the display. It's -1 if there is currently no hit.
• KSPField: 'HitName' is a string - the name of the object being hit.
• KSPField: 'Activated' is a bool - true if the measuring device is on.
• KSPField: 'DrawLaser' is a bool (called "Visible" in the GUI) - true if the laser should be drawn when it's activated or false if it should be (realistically) invisible because, hey, it's coherent light and it's not supposed to be seen from the side.
• KSPField: 'CPUGreedyPercent' is a float (called "CPU hog" in the GUI) ranging from 0.0 to 20.0. It's how much of a single physics tick of time this mod will allow itself to consume during a single Update. If it hasn't gotten a good enough answer within that much time, it will wait until the next update to continue the calculation.
• KSPField: 'UpdateAge' is an integer - It's how many Unity Updates (animation frames, basically) it's been since the value you are seeing was calculated. Becuase of the logic of CPUGreedyPercent (see above) sometimes the value being displayed is stale by a few update ticks and shouldn't be trusted until the next time that UpdateAge becomes zero again. If you're in a situation where this mod needs to spend more than 1 update of time to get to a good answer for the distance, you'll see this value spinning a bit, quickly going 0,1,2,3,0,1,2,3,0,1,2,3...etc. When you see that, only when it hit the zeros was the distance value perfectly correct at THAT moment.
  Note: The higher that CPUGreedyPercent ("CPU hog") is, the less likely it is that UpdateAge will ever be nonzero, but the bigger hit your framerate might take.

 

How to Mount it.

. The Beamer 100x Dist-o-Meter is located in the "Electronics" tech node of the career tech tree. It's a 300-point node on the tree so you might not have it yet in a new fresh career game.

The Laser can be mounted anywhere as a surface-mount item. Take care to

note the orientation of the laser emiiter. (KSP lets you fine-tune

the rotation of a part by using the SHIFT key while you hit the WASDQE

keys.)

The Laser will bounce back and give you a distance measurement when

it encounters ANY object, including parts of your own craft. So

take care to mount it somewhere where the laser beam will have a clear

line of sight without obstruction.

To ensure a good mounting point, you can use "tweakables" to enable the

laser and make it show up in the VAB to look and see if you have it aimed

well.

Lightspeed

Note that if you use it to measure the distance to a far away body (i.e.

like aiming it at Duna from Kerbin), the mod does take into account

lightspeed. You have to hold the laser on an object steady and unchanged

for the entire duration of time it takes for lightspeed delay to

bounce the signal back or you won't get a measurement, so using it at that

great distance will be very hard.

FUTURE EXPANSION PLANS (i.e. the reason this is a WIP)

 

• Max distance isn't enforced yet: It's part of a future plan
  to have different variants of the part that work better the
  higher up the tech tree you go. For now, despite what it says,
  the range is actually infinite.
• Other sorts of sensors?: Now that the numerical approximation behind
  making a "fake raycast" that finds intersections with the planet terrain
  from far away and from any angle is implemented, this opens up the
  chance that other sorts of long range beam sensors could be made.
  For example a "biome detector" that returns the name of the biome
  where the hit occurred is a possibility, as is a "density at a distance"
  measurement which might tell you the atmospheric pressure or density
  at the ground level where the hit occurred. (Maybe because of something
  that the laser detects about interference with the air? It's a bit
  hard to justify realistically how that would work, but it's definitely
  possible with the software. Just not sure if it's possible in the
  real world, or whether real-world sanity is really the intent
  of this mod or not.

 

How do I use it from my script then?

Very Soon Now the dev team of kOS (of which I'm part) plans to

have a release that lets you read the fields of any part's KSPFields

(The stuff you see in the rightclick popup user interface panels), and

manipulate any part's widgets on the rightclick menus (the buttons,

the sliders, etc).

The plan from the beginning was to make LaserDist be a good test case

of this feature that may actually be useful in its own right.

But that's not released just yet. So at the moment this is only

usable as a manual piloting aid where you leave the part menu open

and look at it by eye as you fly.

Part modeling help?

I am aware that the artwork on the model isn't pretty. I'm a

programmer, not a graphic artist, and I don't have experience

with things like Maya and Blender. In fact I just made the model

by slapping together some stretched Cube and Cylnder objects in

Unity itself, without the aid of a modeling program. The model

is good enough to work with, but I'd be happy to have someone

better at art redesign the model. I included the model in

the github directory if you want to have a look.

Is it possible or feasible to use this as a crude LIDAR syste for, example, SLAM / navigation?

[Dunbaratu]

2 hours ago, MAFman said:

Is it possible or feasible to use this as a crude LIDAR syste for, example, SLAM / navigation?

Yes.  In fact that's its main purpose.

 

[MAFman]

4 hours ago, Steven Mading said:

Yes.  In fact that's its main purpose.

 

WOOHOO!! XD

So, would I need infernal robotics to make lidar units that I've seen on robots such as the Neato?

[Dunbaratu]

I don't know what the Neato is.
 

But if you're asking if you can aim the laser in different directions at different times, there are multiple lasers it comes with, and the higher ones are capable of having you "bend" the laser as it emits from the end of the gun within a certain degree arc.  If you want more bend than that, then you'd have to mount it on a moving arm, yes.