Scratch-vm: Lego Boost extension: Add support for distance-sensor

[apfeuti]

Expected Behavior

We should have a possibility to retrieve the distance-value from the Lego Boost vision-sensor.

Having a possibility to get the distance-sensor-value from the MoveHub, greatly improves the possibilities what can be done with Lego Boost and Scratch.
Eg:

• Stop a robot (or drive into another direction) before he hits a wall or some other obstacle -> we can write some Scratch-programs for autonomous navigation.

• Count objects passing (slowly) the distance-sensor

• etc

Actual Behavior

Currently there's no way to retrieve the distance-value.

[apfeuti]

Solution proposal

According to https://github.com/JorgePe/BOOSTreveng/blob/master/ColorDistanceSensor.md the color-sensor can be put into a "color and distance (0x08)" mode, where not only the color is reported but also the distance.

I've implemented it on my fork like this:
https://github.com/LLK/scratch-vm/compare/LLK:develop...apfeuti:feature/LegoBoost-support-distance

This adds two new blocks in the Lego Boost extension.
1) a reporter-block "distance"
2) a hat-block "when distance" with the less, greater and equal operators

[knandersen]

Hi @apfeuti, sorry we haven't gotten back to you earlier. We discussed putting in blocks for the distance-sensor while developing the extension, but decided not to. In the end we wanted the smallest block palette that enabled the widest range of projects, so it wasn't a technical issue, but rather a design decision.

Thanks for reaching out though, and for submitting the PR.

[apfeuti]

@knandersen Thanks for your explanation. I understand that Scratch should be as simple as possible. But it's anyway hard to understand: The Mindstorm- and WeDo-Extensions are supporting the distance-sensor. A lot of cool stuff, like self-driving, is not possible with Scratch and the Lego Boost - too bad.

[SunnyChen-T]

Can someone help on supporting distance sensor for lego boost? Or there is a political reason not to do so?

[GrahamSH-LLK]

Can someone help on supporting distance sensor for lego boost? Or there is a political reason not to do so?

A political reason????????????

[pawelbura]

@knandersen please take a look at @apfeuti answer - this is so true, there is no need to get rid of distance sensor as it give much more possibilities to Scratch

@apfeuti thanks for this PR, I'll try to build Scratch project locally to test it, but I agree that it should be possible out of the box in Scratch

[apfeuti]

You're welcome. Nice to see that other enthusiasts can use my distance-extension. I'm still hoping that the Scratch-Team will rethink their decision and support distance-sensor for Lego Boost in the near future - because it's so a fundamental feature for any robot.

[mikesk8]

I have recently got Boost and wanted to move beyond basic app programming and start using Scratch. However, a distance sensor is a core and fun feature. Without it we are loosing a lot from this Lego set. Would be amazing to get it!

[KaeroDot]

@knandersen: "we wanted the smallest block palette" That is a lousy explanation. The basic Scratch got more than 100 blocks. Number of atomic programming blocks in the Lego boost android software is 78. There is more than 100 other specialized blocks. The actual Lego boost for scratch got only 12 blocks. The possibility to change the light on the boost hub is implemented, albeit not so important for building robots. The distance sensor is very useful feature but is missing. @apfeuti made all the work. And yet your decision is to not add 2 blocks. It seems to me the only possible explanation to your decision is to intentionally harm the experience of programming Lego boost in Scratch.

[ericrosenbaum]

Hi @KaeroDot this is just a reminder to follow our community guidelines on Scratch repositories. Just like on the Scratch community, we care about making our repos constructive and respectful.

The Scratch team and our many community contributors work very hard to make the experience of programming Scratch as wonderful as we can. We are open to potential changes like this one, and we carefully consider them in the context of all the other work we do to keep Scratch running for children around the world.