Little suggestion: its own "python class" for Laser Range Sensor?

[DJuego]

Hi again, @QuirkyCort!

This issue is strongly related to this closed issue (#40).

Today I noticed that in python there is no laser sensor. I propose to add it for the same reasons as the laser programming block. Of course there is no default laser sensor for Lego (ev3dev2.sensor.lego). It would be a "virtual" sensor, I think (ev3dev2.sensor.virtual).

ultrasonic_sensor_in3 = UltrasonicSensor(INPUT_3) # Laser Range Sensor

to

laser_sensor_in3 = LaserSensor(INPUT_3)

DJuego

[DJuego]

Relates question:

Let's imagine that instead of using the block interface, we use only the Python programming interface. How can we declare a laser sensor? Laser sensor behavior is different from ultrasonic sensor. :open_mouth: The simulated laser sensor uses a ray of zero width.

DJuego

[QuirkyCort]

The code for the laser sensor is actually a near identical copy of the ultrasonic. Both works by ray casting, and they primarily differs in that the laser cast only a single ray while the ultrasonic casts multiple rays.

I've added an alias, so this will work now...

laser_sensor_in3 = LaserRangeSensor(INPUT_3)

Since this is just as alias, using UltrasonicSensor will still work, and the auto-generated code continues to generate that. The main reason for using UltrasonicSensor for the laser sensor is because the interface is identical, and to make the code compatible with a real robot using an ultrasonic as a replacement.

May make sense to eventually separate them out. I'm not sure how many people uses the generated code on a real EV3; maybe none.

[QuirkyCort]

The code for the laser sensor is actually a near identical copy of the ultrasonic. Both works by ray casting, and they primarily differs in that the laser cast only a single ray while the ultrasonic casts multiple rays.

I've added an alias, so this will work now...

laser_sensor_in3 = LaserRangeSensor(INPUT_3)

Since this is just as alias, using UltrasonicSensor will still work, and the auto-generated code continues to generate that. The main reason for using UltrasonicSensor for the laser sensor is because the interface is identical, and to make the code compatible with a real robot using an ultrasonic as a replacement.

May make sense to eventually separate them out. I'm not sure how many people uses the generated code on a real EV3; maybe none.

[DJuego]

Thank you for the alias, @QuirkyCort! And, above all, thank you very much for being there.

Yes. I knew those details about the difference between laser and ultrasound.

I believe that even though the particular implementation you have done for Gears is very similar they are actually very different sensors (in the real world). As you yourself say the laser emits only one beam, and the ultrasound emits several (19 by default according to the wiki) projecting them in a fan. Therefore the laser will only detect obstacles that are exactly in front of it while the ultrasound will alert of the presence of objects that are not necessarily right in front of it (!). Of course, this may be desirable or undesirable depending on the situation. The fact is that they are different behaviors. They are not interchangeable.

But let's leave this aside.

Sadly, we have a disagreement. :kissing_closed_eyes:I think the code should generate the code corresponding to the sensor used. That should always be the expected behavior. It should not try to amend the programmer.

For example; when you use the GPS sensor (a sensor that does not exist in the real EV3, but that Gears supports. Amazing!) the corresponding code is generated. When the user tries to run the code on the real robot it will give an error. That is the expected behavior: you are trying to use a sensor that does not exist in the robot.

In fact, GPS is called "virtual" in the internal code. ("from ev3dev2.sensor.virtual import *")

Why is the laser sensor going to be different? The laser sensor is also a "virtual" sensor. And no. It is not the ultrasonic sensor.

If he/she wanted to use ultrasound, then let him/her choose ultrasound explicitly. And if he/she doesn't want to do it, let him/her not do it. Why camouflage it? Getting it wrong is part of learning. In my opinion an error message is the expected result of a programmer error. At least of this particular error.

Or maybe it wasn't a mistake after all, and that particular EV3 robot does have a laser sensor (!). :open_mouth: In any case, that is expected of the code generator is that it generates the code faithfully... not that it tries to outsmart the programmer.

In conclusion, I propose that the code generator produces the corresponding code for the corresponding sensor. No more. No less. :blush:

DJuego

[QuirkyCort]

Fair enough. I've changed it so that the auto-generated code now uses the LaserRangeSensor alias.

[DJuego]

Thank you for being patient with my arguments! :kissing_heart: Sorry for my English! I'm forced to use translators and I'm afraid I'm not always "understandable". :disappointed: I will try not to abuse any more of your time and energy for a while. I will just make one more suggestion for your consideration if it is feasible. Gears is an amazing tool!!

If you wish you can close this thread. :-)

DJuego