-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Define servo blocks same way as Sonar #23
Comments
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. |
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. |
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.) |
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. |
I think your arguments are convincing but I fear it would generate too much memory overhead. The problem is my awfully inefficient compiler. 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. |
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?
The text was updated successfully, but these errors were encountered: