Timing issues in Bloxter


#1

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?

Thanks!

Jim “JR”


#2

Hello @jimrh

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.
scratch

It’s just something that has to be explained.


#3

@jimrh

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: servo_with_delay

Sometimes it takes me a while to realize that a really worthwhile suggestion can be implemented! Thank you again.


#4

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.


#5

A thought

Make delay after action.

Set [servo1] to [90] for [1] second

Acton happens, then delay, then next action.


#6

And make the existing set command have a hidden 1 second attribute?


#7

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.


#8

GMTA ! That’s what the new upcoming block will be doing, as per the screenshot I added.


#9

What about this:

Case 1:

Device has feedback (like a motor encoder)

Internal to the function, wait for the desired state then return.

Case 2:

Device has no readable feedback.

Internal to the function, impose a delay of not less than one second.

I’m on a tiny phone. I will elaborate in greater detail when I get on a real system.


#10

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.


#11

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


#12

To start, let’s try replacing “in” with “for” and see how it flies.

BTW, where are you guys located?


#13

Once the blocks are finalized they will be tested in a classroom.

As for us, we’re spread all over. I’m in Canada. :canada: :slight_smile:


#14

Here’s my GoPiGo with a little “added personality”. :wink:


A New Bot Was Spotted
#15

. . . 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?


#16

Except when they don’t.