search

OpenRoberta / openroberta-lab

The programming environment »Open Roberta Lab« by Fraunhofer IAIS enables children and adolescents to program robots. A variety of different programming blocks are provided to program motors and sensors of the robot. Open Roberta Lab uses an approach of graphical programming so that beginners can seamlessly start coding. As a cloud-based application, the platform can be used without prior installation of specific software but runs in any popular browser, independent of operating system and device.
Apache License 2.0
125 stars 121 forks source link

Calliope: receive message string issues #757

Open taslior opened 4 years ago

taslior commented 4 years ago

Describe the bug

the block "receive message 'String'" seems not to return the documented empty string if no message is inbound.

To Reproduce Run the code below

Expected behavior I am struggling with checking if a message has been received via bluetooth on the Calliope mini. According to the docs, if no message has been received, the block "receive message 'String'" is supposed to return an empty string. If I save the result of the block in a variable and check if that variable != "" I would expect the condition not to be true. Unfortunately this is not working. In the code below the LED shines green all the time. The same code on the same mini just with message = receive message 'number' and testing if message != 0 works as expected (in accordance with the documentation)

Screenshots grafik

Device information

Additional context The "receive message 'Number'" block returns on idle the number 0. It is not totally clear to me how I could distinguish between

boonto commented 4 years ago

Yes this seems to be a problem, there is no real differentiation possible between "0" or empty values and "null" or no values at all. Our documentation is wrong for strings as well, because the empty PacketBuffer returned by the recv (see this) which we wrap in a ManagedString seems to evaluate to something (but not an empty string, null, or similar).

We should probably provide the dataReady method.

To do:

philippmaurer commented 4 years ago

We added a workarround for the problem in our wiki, with which you can work until we fixed the issue. English wiki entry Deutscher Wiki Eintrag

bjost2s commented 4 years ago

This is not a bug, but a "feature" of the firmware. The only way to solve this is to add the "message availabe" block.

heini208 commented 1 year ago

dataReady does not work. It uses queueDepth which is not changed when using MicroBitRadioDatagram.

This could be adjusted. MicroBitRadioDatagram::recv and MicroBitRadioDatagram::send should increase the queue depth.