Behaviour for proximity and ground sensors blocks with grayed-out sensors

[stephanemagnenat]

A user has reported that the current behaviour, triggering at 10 Hz, is intuitive for the proximity and ground sensors blocks. I agree, especially with the when behaviour introduced in 1.4. This situation needs to be re-thought for the next VPL release, the user suggests that the even never fires.

[ddoak]

Do you mean the possible confusion caused by the "grayed-out sensors" block repeatedly triggering? e.g. will beep continously.

Also, a "grayed-out sensors" block can apparently mask other actions depending on the order of the VPL code. e.g. compare: with: In the second case the red and green top led colour changes are never seen because they are immediately overwritten by a change to white.

[stephanemagnenat]

Exactly :-)

[cwalther]

(I was the user in question.) You probably meant to type _un_intuitive. :)

For the benefit of others reading, here’s the full description of my experience (which was shortly after seeing a Thymio and the VPL for the first time):

We were playing with the state blocks and at one point ended up with a program containing pairs with a proximity sensor block with all sensors gray and some state filter. I found it very surprising and confusing that with this program, the robot actually reacted to changes in the state. This clashed with my mental model, which was that an action can only be initiated by the event (orange) block and the filter (green) block just adds a condition, and since we ignored all sensors, the orange block should never fire. The others explained this behavior to themselves by assuming that also the green block can activate the pair, namely when the state changes to one that matches the filter, but that sounded wrong to me. It turns out my mental model was actually correct, there was another thing that I missed, as I found when I read the manual (https://www.thymio.org/en:thymiovpl#toc5) now: "If all sensors are ignored, this event occurs periodically 10 times per second." That neatly explains the robot behavior we were seeing, but it is a very unexpected behavior for me, and unlike the rest of the VPL, which seems pretty intuitive once you've learned the basics, completely undiscoverable. Is there a reason why it works that way? (My suspicion is that this was originally a bug, but was declared a feature when people found it useful.) Expected behavior for me would be that a sensor block with all sensors ignored never fires (and ideally the compiler should alert me to that, since such a pair is useless), and if I want periodic events, there should be a separate event block for that (maybe with a configurable rate).

(I tried to make screenshots like above, but couldn’t find a way of launching the VPL editor without having a Thymio connected. Is there one?)

I’m glad you agree on the usability problem. I might even have a go at fixing it myself, using the Thymio you left at the FabLab…

[cwalther]

I built Aseba, played with the Thymio, and snooped through the code today, deepening my understanding a bit (and, on the other hand, probably losing some of my fresh outside view in the process).

One could argue that the code

onevent prox
    call leds.top(32,32,32)

generated for an all-gray proximity event block is incorrect. Since the conditions of non-grayed sensors are _and_ed together in a when statement, what it should conceptually actually generate when there are no such conditions (if that were valid code) is

onevent prox
    when () do
        call leds.top(32,32,32)
    end

As the empty and expression is always true, it never has a rising edge that would activate the when statement. The code that never executes can be optimized away, so the actual code that should be generated is no code at all (and a compiler warning about that).

And to answer my own question: Yes, there is a way of launching the VPL editor without having a Thymio connected, namely using Aseba Challenge as described on https://www.thymio.org/en:gettingstarted and running thymiovpl -anytarget.

[cwalther]

Preliminary proposal in #452.

[motib]

I agree that the current bug/feature(*) is obscure. I had to ask Stephane for help when I first encountered it (cf. the "frantic" Braitenberg creature in Chapter 12 of the VPL tutorial). The potential confusion should be weighed against the utility of implementing periodic events without learning about the timer. I haven't been able to form an opinion...

If the decision is made to change the behavior, for consistency, it should also be changed for the empty button event, which causes a periodic event at a different frequency.

Moti

(*) Q: What is the difference between a bug and a feature? A: A feature is documented.