Distance sensor (Release)

The distance sensor prototyped here (Practical use case: Distance sensor (PoC)) is about to be released in version 2606 EAP.

The concept stays the same. It calculates the dot product of the sensor's normal vector and the minimal distance vector from the part to the sensor. The dot product is then used to check if the part is located in front of the sensor and if the part lays within the sensor's field of view.

If both conditions are met the minimal distance to the part is returned and a Boolean output is set to true, indicating a detected part.

The logic is not that straight-forward to understand and write so we've encapsulated it in a OOTB function block ("PART_DISTANCE_SENSOR"). It is a script that you can find in the SCL vault along with the vector math functions. When you need such a sensor, you just declare a variable of this type. Then you call the FB in your script, providing the inputs and outputs. We also provide a template that you can just load in the SCL editor. That's it :)

Here is how it looks:

FUNCTION_BLOCK "MAIN"
VERSION:1.0
VAR_INPUT
	part : TX_OBJECT;			// pick a part as default value
	range : LREAL := 350;		// range in (mm)
	fov : LREAL := 90;		// field of view (deg)
END_VAR
VAR_OUTPUT
	partDetected : BOOL;		// part detected
	distance : LREAL;			// distance to part (mm)
END_VAR
VAR
	sensor : "PART_DISTANCE_SENSOR";	// sensor instance
END_VAR
BEGIN
	
	// call the sensor
	#sensor(PART:=#part.NAME, 
		AXIS:=2, 			// detection axis (0=X,1=Y,2=Z)
		FOV:=#fov, 
		RANGE:=#range, 
		DISTANCE=>#distance, 
		OUT=>#partDetected);

END_FUNCTION_BLOCK

Paste this in the SCL editor, pick a part, wire the signals and you are done. (In case you want to detect any part, just remove the PART argument.)

The AXIS argument sets the detection axis of the sensor. It detects parts in its positive direction. The field of view is a cone around the detection axis that points at the sensor. The range can be imagined as the height of that cone. You can change the detection axis during simulation. This is not typical for sensors but is yet possible. Part, field of view and range can also be changed.

Now let's mention some of the limitations:

1. Minimal distance - when the part is very close (distance = 0) to the sensor it may be reported as not detected. This is a side effect of the dot product. In this case the normal vector and the minimal distance vector usually become perpendicular and we cannot really judge about the direction. e.g. we cannot really tell if the part is in front of the sensor or not. To overcome this limitation ensure that the part never hits the sensor. This is also true in reality.

2. Performance - calculating the minimal distance is not cheap. So when you have many such sensors you may notice a performance degradation because of it.

3. Geometry is mandatory - both the sensor and the part should have geometries assigned. Minimal distance calculation is not possible otherwise.

4. For now we cannot visualize the sensor's range and field of view.

What has changed since the PoC?

1. We've introduced a built-in function (GET_ABS_LOC_AXIS) that returns a normalized vector representing one of the axis of an absolute location. Previously we were calculating the normal vector of a plane (still possible today) which was somewhat artificially introduced for the sake of the PoC. It was also slower.

2. The sensor logic was optimized a bit to avoid all the calculations when the part is not in range.

The scripts in the SCL vault are pretty simple despite the complexity. You can use them as examples when developing your own logic or when promoting the script. Some of them can also be reused in other use-cases.

Enjoy!