Space Engineers

Space Engineers

Not enough ratings
Rotor-based Parallax Rangefinder [Obsolete!]
   
Award
Favorite
Favorited
Unfavorite
File Size
Posted
Updated
5.313 KB
23 Jul, 2015 @ 10:14am
16 Mar, 2017 @ 5:55pm
7 Change Notes ( view )

Subscribe to download
Rotor-based Parallax Rangefinder [Obsolete!]

Description
Note that camera raycasting pretty much makes this script obsolete. I'm sure raycast rangefinders are a dime a dozen. I won't bother releasing a standalone rangefinder, but I am beginning to incorporate raycasting into my other scripts (e.g. fire control systems, target trackers, etc.)


A script to implement a rotor-based parallax rangefinder[en.wikipedia.org].

Includes a PID controller for precise rotor movement as well as a method to compute the closest intersection of two lines.

Minimum hardware: 2 cameras, 2 remotes, 1 rotor, a programmable block, and a timer block.

If you'd rather not deal with rotors, or you can't make enough space between cameras to make this work effectively, there's also a Single Camera variant. However, it will need a reasonably maneuverable ship.

Setup
(There is a demo ship available to hopefully make all this more clear.)

The script assumes one camera is static and the other is mounted on a rotor.

Each camera should be mounted in front of their respective remotes. It doesn't have to be directly in front, but it should be in line with the "forward" sides of the remotes.

The cameras should be mounted as far away from each other as possible. And needless to say, they should initially be pointing in the same direction and at the same height. ;)

The static remote should be in a group named Static Reference

The remote on the rotor, along with the rotor itself, should be in a group named Rotor Reference

The rotor should have max torque (including braking torque).

Load the script into a programmable block. The timer block should be setup in one of 3 ways. The first two are recommended:
  1. Timer block should have "1 second loop" in its name and should only run the programmable block.
  2. Timer block should be in a group named RotorRangerClock and should only run the programmable block.
  3. None of the above. The timer block should run the programmable block and Trigger Now itself. Additionally, you should make sure the start/trigger the timer block before using any of the rotor commands below.
By default, the script will write the target coordinates to all text panels in the CM Target group. This can be easily modified/customized, see the UpdateTargetTextPanels() method.

Commands
The script accepts a number of commands as arguments.
  • left - Step the rotor left
  • right - Step the rotor right
  • reset - Reset the rotor to 0 degrees
  • factorup - Increase the step amount by a factor of 10. The default step amount is 1/10th of a degree.
  • factordown - Decrease the step amount by a factor of 10.
  • factorreset - Reset the step amount to 1/10th of a degree.
  • compute - Takes the line extending from the Static Reference remote and the line extending from the Rotor Reference remote and computes the closest intersection point (this would be the point that both cameras are centered on). It then writes the coordinates to all text panels in the CM Target group in the format "X;Y;Z"
Configurables

The reference groups, text panel target group, and text panel coordinate format can be edited at the top of the script. Additionally, if you're familiar with C#, you can edit the UpdateTargetTextPanels method to do whatever you want with the target coordinates (the Vector3D parameter).

The text panel coordinate format is meant to be easily parsed by a script. However, changing it to the following is also very useful:
const string RANGEFINDER_TARGET_FORMAT = "GPS:Whatever:{0}:{1}:{2}:";
This is the same format that Space Engineers uses when copying & pasting GPS coordinates. This will allow you to automatically add a temporary GPS position by simply editing or looking at the text panel's public text. (After doing so, it should show up as a light gray coordinate in your GPS list.)

Source

For the bleeding edge, as well as a more readable and modular version of the script, go see GitHub[github.com]. I usually only update the workshop version when things break or major features are added.
7 Comments
The August Ambassador 7 Oct, 2024 @ 10:42pm 
I am a new SE player and a little confused how to install this. Would you be willing to help me on a voice call? I don't really know how to use timers and remotes and programable blocks and I think i've gotten everything grouped and formatted correctly but nothing seems to be happening
Rusted Droid 1 Nov, 2022 @ 3:22am 
NOT Obsolete if you use principle of Coincidence rangefinder.
Actually cool design.
ZerothAngel  [author] 15 Mar, 2016 @ 7:37pm 
LCD worked.

It writes to the public text. I also noticed that "show text on screen" is "none" by default, so another thing to look out for. But if you edit the public text, you should see the coordinates there.
ZerothAngel  [author] 15 Mar, 2016 @ 7:30pm 
I tried it myself on planets but the ranges were all off too. Not sure why that would be. Maybe because of the ranges involved (10's to 100's of km), the camera zoom isn't enough to really focus on a single point? Who knows.

I'll give LCDs a try soon.
Dealman 15 Mar, 2016 @ 7:19pm 
Alright, I'll check it out - also do you know if there's a possibility to use this to get the range to planets/moons? I noticed it displayed some rather peculiar distances when trying to do so - otherwise it worked great.
ZerothAngel  [author] 15 Mar, 2016 @ 4:44pm 
Weird. I've never tested it with an LCD, actually. But from the point of view of scripts, LCDs are text panels, so it shouldn't really matter. So two things to try:
* Try a text panel instead
* Make sure ownership is the same between the prog block and LCD/text panel
Dealman 15 Mar, 2016 @ 12:37pm 
Just tried this and I can't get the LCD to work, it won't update with the text. I've tried both naming the LCD itself and group it in a group called CM Target - but it doesn't work.

It does however display the range and co-ordinates properly on the interface itself. Any ideas?