Skip to content
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

Support for robot interaction within block editor #119

Open
stephanemagnenat opened this issue Sep 15, 2017 · 6 comments
Open

Support for robot interaction within block editor #119

stephanemagnenat opened this issue Sep 15, 2017 · 6 comments

Comments

@stephanemagnenat
Copy link
Member

stephanemagnenat commented Sep 15, 2017

It would be useful to have the possibility for VPL to interact with the robot (if connected) during block edition. For instance, as suggested by @Vincebecker, sound preview could improve the music block. The same applies for the colour block, and for distance and ground sensors blocks to see the actual values of the sensors, especially in an advanced mode where thresholds can be set manually.

There are different ways to implement that:

  1. To provide support for this feature within all uploaded programs.
  2. To load another program to the robot that provides this feature.

The advantage of 1 is that the robot could potentially still run, or at least, easily be paused and then continued. However, currently modifying a program stops its execution, so this is not a strong requirement. Moreover, this has a cost in term of the size of the generated program, which I think we do not want to pay. So I vote for 2.

@mbonani
Copy link
Member

mbonani commented Sep 19, 2017

To correctly understand you I think you mean the advantage of 1 " the robot could potentially still run"
Then I vote also for 2. from a firmware point of view it will more clear to have different upload program that reset better the status of the automatic behavior (led and button noise)
Then this is perhaps an option that could be de activated?

@stephanemagnenat
Copy link
Member Author

stephanemagnenat commented Sep 19, 2017

I made a mistake in my phrasing (now corrected), I meant that the advantage of 1 is that the robot could potentially still run.

In general I am very careful with publicly-available options, as they typically show that we did not find a good default behaviour, they confuse most users, and they require more implementation, maintenance and documentation work. I think that one of the reason macOS is so successful with teachers who can afford it is that it provides simple ways of doing basic things, that users can learn and feel safe with. Options are spooky for most users. Actually, macOS has tons of options that can be enabled only with the command line. This allows the power users to still customize the system why not requiring a proper user interface and documentation for these features.

@mbonani
Copy link
Member

mbonani commented Sep 19, 2017

The default behavior should propose the option with the robot interaction enable. I understand your point of view to not scary the teacher with options, but a teachers could like to disable sound editing in a classroom. Also I am still not convinced about stopping the robot when you edit a program so it could be an option of having still your code working, or having your robot stop and have "coding interaction".
Also I am not sure that even if I fill as a "power" user, I can edit option in command line on a tablet.

Another issue:
If we have such mechanism (code to interact with robot while editing) one nice tool should permit user to change volume of Thymio

@stephanemagnenat
Copy link
Member Author

stephanemagnenat commented Sep 20, 2017

Also I am still not convinced about stopping the robot when you edit a program

If we do not do so, the feedback makes no sense. We could disable it in that case. Based on my previous observations, I think that stopping the robot is the best thing to do, in particular because most users want to keep track of what is going on, and a single thing should be going on in the same time to make this tracking easy, but we should do more tests with users.

If we have such mechanism (code to interact with robot while editing) one nice tool should permit user to change volume of Thymio

This is an interesting option, and should be in its own issue. Currently the volume is controlled on the robot. Do you think it would make a huge improvement to control it from VPL? We could imagine a volume control icon that appears when the robot is connected.

@Vincebecker
Copy link

Since I am not enough aware of what this implies in term of developpement I will let you decide about this.

My comments :

  • I think stopping the robot when you edit a program is a bit strange. (But, as you said, we can (we have to) test it with users.)
  • Maybe an alternative to this is to have a "feedback" option. If you check it it will interupt the robot and you will have live feedback on both tablet/phone and robot.

For the volume I think this is great but it opens more questions :-) Do we think about calibration and other "options" too ?
let's not discuss about this here and make a new issue if you find it interesting.

@stephanemagnenat
Copy link
Member Author

For the volume I think this is great but it opens more questions :-) Do we think about calibration and other "options" too ?

Yes these are meaningful questions, and indeed we should open issues for them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants