GIRA / PhysicalBits

A web-based programming environment for educational robotics that supports live coding and autonomy using a hybrid blocks/text programming language.
https://gira.github.io/PhysicalBits/
MIT License
18 stars 5 forks source link

Define servo blocks same way as Sonar #23

Open kristiank opened 4 years ago

kristiank commented 4 years ago

I think it would be good to define the servo blocks the same way as sonar blocks, e.g. to abstract the servo pins to use names instead of just the pin number.

I can see this affects some sort of pedagogical statement that we should not abstract components too much. I mean, yes it is nice that users instantly understands that servo controlling is something very simple (just a value set to one output pin). But still, that could be up to the teacher to reveal, that hey, actually you can use the 'set pin variable' block to do the same. In that case it would be even more clear to the user, that not even the text on the block that mentions 'servo' doesn't do any magical tricks.

What do you thitk?

RichoM commented 4 years ago

Maybe you're right. We had a similar discussion in our lab a few weeks ago when I added the Buttons pane. If you look at the generated code you'll see that the button blocks are implemented in a library. So it kind of made sense to treat buttons the same way as we did with the sonar library. I thought it was overkill to have to declare each button separately but maybe for servos it makes more sense.

kristiank commented 4 years ago

Yeah, I see this as a clash of many dimensions. One dimension is that "we all know" what's behind those abstractions, but those who are new to the game don't know. Another dimension is the user interface and how coherent it is, from this point of view I really would like to have the 'configure ...' button for all sensors and actuators just out of aesthetical reasons. And a third dimension would be how coherent blocks are with respect to each other, e.g. joystick blocks could also be pin-based, e.g. "Read joystick magnitude on [pin X]" just to make them more similar to other blocks..

I think my motivations for abstracting the Servo block was all the above but also a pragmatic one, that I don't need to change the pin number every time a drag a servo block out on the board. It just felt that I want a name for that servo.

kristiank commented 4 years ago

Now thinking about, actually I would like to have a name for the buttons also, instead of needing to name a variable for holding the pin. But I guess there's more work to be done elsewhere first, so this is not a priority. (And while on it, why not have the debounce time overwritable for each button as well, if it doesn't create a too much of an overhead in terms of device memory.)

kristiank commented 3 years ago

Have you had any thoughts about this lately? Should I close it as a feature request that never reached through, or is it worth having it open still? I still think the arguments are valid, that a servo deserves a name the same way as a DC motor does.

RichoM commented 3 years ago

I think your arguments are convincing but I fear it would generate too much memory overhead. The problem is my awfully inefficient compiler. You can see how bad it is by adding two sonars and looking at the generated program. You'll notice it includes every sonar function twice, one for each sonar. As you can imagine, that's a terrible thing from a memory usage point of view.

My excuse is that it was the easiest way of implementing it and I was planning on eventually optimize the compiler so that it would be able to detect duplicated functions and remove them from the compiled program. However, I didn't get to do that yet. So I think I would prefer to leave things as is until that optimization is done. It's high on my TO DO list, though, so don't close the issue yet.