aseba-community / thymio-vpl2 Goto Github PK

plz fix
kthxbai

When inconsistent actions are put together in simple mode, VPL should generate an error. This happens when there are on the same line:

1. two instances of the same action blocks
2. two instances of different blocks using the same actuators, such as the simple and the advanced motor blocks

Point 2. might be solved by #46, but 1. remains.

There is a tension between the game needs and the educational needs. In the first one, for the sake of immersion, a dark theme is optimal. In the second one, to match the educational paper metaphore and to ease screenshots, a light theme is optimal.

Currently there are two types of color blocks: palette and sliders, and also two types of motor blocks: directions and motor speeds. This might be better solved with having different "editors" in different tabs.

The following program in VPL1 works perfectly, both in simulation and in the real robot:

The corresponding code being:

onevent prox
	when prox.ground.delta[0] <= 400 and prox.ground.delta[1] <= 400 do
		motor.left.target = 200
		motor.right.target = 200
		emit pair_run 0
	end
	when prox.ground.delta[0] >= 450 and prox.ground.delta[1] <= 400 do
		motor.left.target = 200
		motor.right.target = 0
		emit pair_run 1
	end
	when prox.ground.delta[0] <= 400 and prox.ground.delta[1] >= 450 do
		motor.left.target = 0
		motor.right.target = 200
		emit pair_run 2
	end

However, the corresponding code in VPL2:

easily losses the track.

From the behaviour of the robot, it seems that the sensors are under-sampled, although the tests are made in the onevent prox handler.

Testing with a VPL1 parent and child user, they report that they wished to see the whole line being highlighted upon execution, similarly to VPL1.

since fixing #13

Testing with a VPL1 parent and child user, they report that the lack of the click and add to empty slot behaviour is a regression for them.

Currently, in simple mode, the user can scroll the blocks outside the view. This is prone to loose the blocks, and is useless. The blocks should not be able to be scrolled farther away then the margin, meaning that margins apart, there should not be areas on the screen with no blocks.

Trying to load a previously-saved code results in this error:

qrc:/thymio-vpl2/EditorSimple.qml:104: Error: Cannot assign [undefined] to BlockDefinition_QMLTYPE_14*

and the code is not loaded.

It seems there is a problem with initialization of conditions in simple mode.

For instance, if one writes a simple line following code with 3 events and 3 motor actions, and the robot is placed on the track, the robot does not start moving until it is shown white area/obstacles.

This problem does not appear with VPL1 and is critical for simulating the Thymio behind the back of the user as the user cannot interact with Thymio.

Testing with a VPL1 parent and child user, they report that the lack of the possibility to delete a line is a regression for them.

It would be good to be able to exchange lines by drag and drop, as in VPL1

Both in simple and advanced mode, the proximity and ground sensors blocks do not show their current parameters in the edit mode.

It is easy to reproduce:

1. add a proximity sensor block,
2. edit it, set one of the sensor to detection,
3. acknowledge the changes, they can be seen in the miniature,
4. edit again the block, the changes are not shown.

Other blocks seem to work.

While executing a simple line following program in the simulator, this error is repeatedly produced:

qrc:/thymio-vpl2/Compiler.qml:498: ReferenceError: blocks is not defined

Maybe it is due to the highlighting code.

It would be very nice to have a way to bind remote controls.

it will solve compatibility problems with non-official remote and users can chose to have a different use of the official one ( for example : hold it horizontally, like a game pad !)

concept image of remote settings

Currently because we have a ListView to hold block icons on side bars, dragging a block tend to scroll the sideview if the block is not dragged perpendicularly to the border, which happens with most users.

Preliminary testing with users for the block editor screen show that these confuse users. We have to rethink this mechanism. Maybe there is a better way to present this editor to the users.

They should be separate.

In simple mode, the start indicator should not move when dragging the event block; the invisible link from the last non-empty action of the row should point to the start indicator state (proper fix for #9).

In advanced mode, the user should not be able to create such link.

Currently, the VPL2 compiler generates enterX dead code.

One a simple line following program in simple mode (3 event-actions pairs, with one event and one action each), not generating this code would reduce the bytecode usage from 38% to 33%.

On the long run, the Aseba compiler should remove dead code by itself, but it is harder to implement (although much more general) than not generating the dead code in the first place.

As with VPL1, two similar events with similar parameters should not be allowed in simple mode.

In VPL1 advanced mode, there are sliders to control the thresholds for the proximity and ground sensors blocks. We should do a user study to see whether they are appreciated and used to see whether it is worth adding them to VPL2. If so, we should improve them in VPL2 by showing the current value, as this is requested by several users.

From an educational point of view, it would be useful for a teacher to be able to easily select a set of blocks for a given educational activity, and having the children's app provide only these blocks. This could be good through a connected system, but also in a disconnected way, but having the teacher's app showing a QR code of the configuration to the students' apps.

It would be more intuitiv if the "block configuration panel" (where we set the color, the motor speed, the wanted button, ...) was opened automatically at the block creation.

It seems that in simple mode, sometimes, the program does not start.

I can create such a situation by making a simple program to follow a black line on the ground using 4 pairs of ground-sensor (each one with a different configuration of black/white) and simple motor block. When I put the robot on the track and then start the program, sometimes the robot does not move. If I take the robot away from the track and move my hand in front of the ground sensors, the robot starts moving, and then the program works correctly.

When a program is loaded, an empty event-action pair is displayed on top of the others in the list. See this screenshot:

The motor block currently does not show animation of the robot moving, while it was doing it in VPL1. Without it the understanding of the sliders is worst than in VPL1.

It would be really useful to be able to record a sound on the robot, and replay it in a VPL program.

This depends on the firmware providing an indication whether a mounted SD card is available (issue Mobsya/aseba-target-thymio2#20) and what is the duration of a given sound (issue Mobsya/aseba-target-thymio2#21).

Currently (and in VPL1), button and proximity blocks can be set in a mode where there is no condition. The corresponding behaviour in VPL1 is to fire at regular interval, which has no justification and can be seen as a undesired side effect of an unspecified behaviour. It is reported and discussed as such in aseba-community/aseba#446. To maintain compatibility with existing educational material, this behaviour is kept in VPL1.

However, it should not be permitted in VPL2. A solution is to create the block with a value set, and do not allow to validate it if no value is set, while showing an error message in the block editor.

While the sound block in VPL1 allows users to compose some melodies, and allows activities such as Morse code, it is not very flexible. In VPL2, we have a version of this block with 8 notes and variable play speed, which is nice and appreciated in preliminary tests.

We can also imagine other types of blocks in relation with music:

1. percussion system, where the user records a rhythm on the tablet.
2. audio record/play on the robot

... as it is done in VPL1

Currently an event without an action is valid in simple mode, while it was forbidden in VPL1. The reason being that it does not make sense, so the user should be encouraged not to do it.

I think that from an educational view, and to have a symmetry with actions, it is helpful to produce an error.

It would be useful, especially for the first hours of use, to give visual hints on which elements can be clicked/interacted with.

As the current obstacle detection block proposes a fine control of each sensor, including the "ignore" state, a simple version grouping sensors together and allowing only a binary state (obstacle/no obstacle) should be provided.

Maria designed a version:

While 95f0000 corrected #9, it seems it introduced another bug: now the action executed is never highlighted in simple mode.

Currently the error message when missing an action is "unreachable block". It should rather be "missing action".

In VPL1 the location of the error is shown. I think that a similar feature should be available in VPL2, at least in the simple mode.

Currently, in simple mode, children easily write long programs that fill the full memory of Thymio. However, this is often because events are duplicated. However, correcting #41 and #10 should make the memory limitation harder to reach.

Nevertheless, simple improvements could be made, as described in issues:

• #28: bitfileds in compiler are filled from the msb, generating large bytecode
• #29: VPL2 compiler currently generates dead code

As bitfileds in the VPL2-to-aesl compiler are filled from the msb, the aseba compiler must generate LARGE_IMMEDIATE loads which take 4 bytes, while if these bitfields would be filled from lsb, a SMALE_IMMEDIATE load would be sufficient for most cases, saving a lot of bytecode for VPL2 code.

Currently it is possible to drop a block on a line that is half visible, and the line is still half visible. It would be good that the line whose editor is open is set to visible. And if this leads to the creation of a new line, show that line as well.

I'm trying to do a timer delayed toggle from State A to State B and then from State A to StateBindefinitely.

Here is an image of what I'm trying to do. Here is the aesl file as well.
Thymio should switch indefinitely from red to blue.

I don't think it's possible to do this only using VPL.
(which I'm trying to do because I'm doing a workshop for kid)

Do you think there would be a fix for this? Like an else-if statement in this block or the state copying and return statement in if block?

I'm not sure if this would have any consequences in other use cases though.

What do you think?

onevent timer0
    timer.period[0] = 0
    if state[1] == 1 then
        call leds.top(32,0,0)
        new_state[1] = 1
        new_state[3] = 1
    end
    if state[1] == 1 and state[3] == 1 then
        call leds.top(0,0,32)
        new_state[1] = 1
    end

    call math.copy(state, new_state)
    callsub display_state

This leads to the new drop position to be outside view, even when starting from a zoom where everything is visible initially. A way to solve that is to zoom out by the ratio of how much the line was extended, and move the view by the size of the line extension.

It would be nice for the color blocks (top and bottom) to be able to pick a color from the tablet/phone camera.

It would be nice to be able to record a trajectory of the tablet using its IMU, that would then be used by the robot. This would allow very interesting activities for instance related to dancing, and could also be useful for children with special needs.