Question:
How is Blockster supposed to handle multiple statements that “should” be atomic?
Device: GoPiGo v3
DexterOS: whatever was delivered with the kit. It should be reasonably recent. (Will check later)
Assumption: DexterOS “block” programming language is supposed to be simple and usable by a pre-teen audience with little to zero programming experience.
Observed behavior:
Many statements appear to be very timing critical.
Example:
Servo1 [center]
Set [servo1] [0]
Set [servo1] [180]
Servo1 [center]
Since this is supposed to be a simple programming language environment, I expected the front servo (servo 1) to center if not already there, swing all the way to the right, all the way to the left, and then re-center.
What actually happens is that the servo centers itself since that is the last command as (apparently) the commands execute so quickly that the device has no time to respond. Adding a one second pause between steps allows for the expected behavior.
Is this expected behavior in a “elementary” programming environment? I would expect this in a C/C++ environment, but not in one targeted towards a younger crowd.
As far as I could find, nothing in the lessons and nothing in the forum comments mentions this kind of timing care needed in Blockster.
Is this expected? Am I doing something wrong? Am I missing a crucial update?
You are indeed right. Each servo call should be followed by a “Count x sec” block.
We did attempt to hide a pause in each block but we ran into other timing problems.
Scratch has a similar issue with the following sequence. Nothing will show on the screen if you run this.
Couple of hours later… I want to thank you for bringing it up. As soon as I have a moment I’ll add blocks where you can assign a delay right in the block like this:
Sometimes it takes me a while to realize that a really worthwhile suggestion can be implemented! Thank you again.
I had a couple of ideas about that, primarily the use of message queues where the next message for a particular servo, sensor, or actuator was fetched only after the first one had completed. There are design aspects to this that need thought - The wife and I are taking the granddaughters to see the Nutcracker today. I’ll comment more when I get back.
The main issue with this is that the servos do not send any type of signal back when they reach their target. From the GoPiGo’s point of view it has no way of knowing. So we can only use delays unfortunately.
That’s not what the block appears to say as designed.
set [servo 1] to [90] in [1] second
appears to say "after a one second delay, move the servo to 90 degrees. for [1] second says to start the action, continue doing it for one second, then stop.
It may seem like a trivial difference, but it will make the intent much clearer.
BTW, I really appreciate the opportunity to help collaborate with you on this. Thanks so much for allowing me to help.
Oh, I see what you mean. Yes indeed the block could be misunderstood.
What I was attempting (and failing) to say was " take [1] second to bring the [servo 1] to position [90]"
Any idea on how to phrase it better?
I’m always ready to discuss Bloxter blocks and improvements. This is fantastic! Thank you for all your input!
Cleo
. . . and I’m here, (with the granddaughters), in Moscow Russia.
Question:
Since the blocks are - in essence - pictorial representations of Python functions - couldn’t you do something like this?
SetServo(seconds)
switch (seconds)
case seconds = ""
set seconds = 1
break
case seconds < 0
set seconds = 1
break
case seconds = 0
MoveServo() # run as a non-blocking process until stopped
return(0)
endswitch
MoveServo(seconds) # run as a *blocking* process for specified period
return(0)
Pardon my psudo-code, but hopefully this will give you an idea of how I believe the functionality should run by default. Perhaps there can be two different Python function calls, one with a timer and one without.
What do you think?
Jim “JR”
p.s. Any chance of getting to play with it when you have a beta?
p.p.s. What’s a “GMTA”? A French Canadian curse word?
