General Robotics

Scratch for Vortex programming

userHead Mares Jaroslav 2016-01-26 01:59:01 56953 Views15 Replies

Thanks to Rex’s post to my last contribution (thread named ‘Error message/red dot when trying to connect to Scratch’) I am now able to put the Scratch into operation. Nevertheless, some troubles still remains. Using Win7 64 bit with Vortex connected by USB cable I found the following:

1) After successful start of ‘Launch Vortex Communication Service‘ the red dot displayed in Scratch–More Blocks (next to DF Robot title) is changed to green. But the green briefly flashes to red every six seconds or so. Only after Vortex is switched on, the green dot remains stable. 

2) The S4V tutorial says that when the Vortex is connected, its lights have constant brightness. Of course, my Vortex is connected in spite of its lights repeatedly brightening up and fading, as it obeys most Scratch commands in this state. It plays and stops music, it moves, rotates, dances, sets its facial expressions and eye colors. But at the same time, it does not set its bottom lights (they brighten up and fade still again), and even starts autonomous dancing when pushed forward and also reacts to hand waving just like it does without any external control. I would call it a semi-connected state:). 

3) Anyway, I have found a way how to connect it fully. 
After my Vortex dances one second and then stops, its bottom lights get constant brightness and can be set by appropriate Scratch commands. So I start this short dance at the beginning of each programming session. 

I have checked all Scratch commands listed for DF Robot (except of just two top lights settings as the top LEDs do not light without the top dome mounted and this is impossible for me because of USB cable) and noticed just two problems described below.

4) The first is only a tiny bug: some color names in the following command menu do not correspond to reality

5) The second problem bothers me more - I do not know how to bring to life the proximity and grayscale sensors. Autonomous Vortex indicates waving close to him, so the proximity sensor certainly does work. I was not so successful checking the line following sensors autonomously, probably I am not clever enough. Anyway, I have checked both sensors in Scratch. Surprisingly they both work but just once after the Vortex start. Then both keep the last read value until a Vortex restart. Do they need a reset? I don’t know. Hopefully Rex or another DFRobot expert could help?

 

2016-02-04 16:13:40 Hi Rex,

After the firmware update the proximity sensor works as expected, is very reliable and ready to be used in Scratch programs. Thank you very much!

The greyscale sensors with updated ’DF4Scratch_EN’ do work, too. I have spent a lot of time by their testing in recent days and now doubt they could be used for anything in Scratch. In their present implementation they seem to be very low sensitive and yet their sensitivity is very different and with large variance for each sensor. I am unable to register any greyscale sensor activity when the robot controlled by Scratch moves over black lines on white paper. So I tried to cover and uncover the whole bottom (i.e. all six sensors) by hand with black velvet. Some of these changes haven’t been registered in running Scratch script at all, while another have been registered by one or more sensors (verified also in node.exe log).
N.B. The grayscale trigger count is a good idea but the only possible reset is Vortex switch off-on. Some ’reset all counts’ command would be nice (as analogy to pair of standard Scratch blocks ’timer – reset timer’), to avoid programming with offsets.

Conclusion: Obviously, the grayscale sensor hardware is ok because it works well in the firmware and probably also using the WhenDo app. Questionable behavior in Scratch may by caused by the analog sensors (connected to analog pins) implemented in Scratch digitally. For the time being this S4V feature is in my case unusable.

Perhaps it might be better in Scratch for Arduino (or even Snap for Arduino, with much faster response times than S4A and optional translation of simple scripts into Arduino sketches). But I do not dare to test it now as I am afraid of uploading StandardFirmata to Vortex board. I couldn’t restore the original firmware with VortexBot.apk again having no iOS device available.
userHeadPic Mares Jaroslav
2016-02-04 16:13:40 Hi Rex,

After the firmware update the proximity sensor works as expected, is very reliable and ready to be used in Scratch programs. Thank you very much!

The greyscale sensors with updated ’DF4Scratch_EN’ do work, too. I have spent a lot of time by their testing in recent days and now doubt they could be used for anything in Scratch. In their present implementation they seem to be very low sensitive and yet their sensitivity is very different and with large variance for each sensor. I am unable to register any greyscale sensor activity when the robot controlled by Scratch moves over black lines on white paper. So I tried to cover and uncover the whole bottom (i.e. all six sensors) by hand with black velvet. Some of these changes haven’t been registered in running Scratch script at all, while another have been registered by one or more sensors (verified also in node.exe log).
N.B. The grayscale trigger count is a good idea but the only possible reset is Vortex switch off-on. Some ’reset all counts’ command would be nice (as analogy to pair of standard Scratch blocks ’timer – reset timer’), to avoid programming with offsets.

Conclusion: Obviously, the grayscale sensor hardware is ok because it works well in the firmware and probably also using the WhenDo app. Questionable behavior in Scratch may by caused by the analog sensors (connected to analog pins) implemented in Scratch digitally. For the time being this S4V feature is in my case unusable.

Perhaps it might be better in Scratch for Arduino (or even Snap for Arduino, with much faster response times than S4A and optional translation of simple scripts into Arduino sketches). But I do not dare to test it now as I am afraid of uploading StandardFirmata to Vortex board. I couldn’t restore the original firmware with VortexBot.apk again having no iOS device available.
userHeadPic Mares Jaroslav
2016-02-02 10:23:19 Hi,

The greyscale sensor works as a trigger. Whenever the sensor sees a change, it passes the data to the backend service. It does not matter if it is white to black or black to white, the message is identical. Originally I only set the status to true once a message arrives.
So I have changed the status, and added a trigger count for better information. Updates are ready on github.
userHeadPic Xia Rex
2016-02-02 10:23:19 Hi,

The greyscale sensor works as a trigger. Whenever the sensor sees a change, it passes the data to the backend service. It does not matter if it is white to black or black to white, the message is identical. Originally I only set the status to true once a message arrives.
So I have changed the status, and added a trigger count for better information. Updates are ready on github.
userHeadPic Xia Rex
2016-02-02 09:39:11 Hi,

Yes, like you have insightfully deduced that we relay sensor data that way.

For proximity, the issue only happens with the early firmware. I suppose you are using the first version of firmware. It has some compatibility issues with Scratch and we have already fixed in the latest version of firmware. To update, please go to https://github.com/DFRobot/DFResources for latest android version ( most compatible with android 5.x version phones with Bluetooth 4.0 hardware). Or if you have iphone/ipad, you can search for Vortex app. Upgrade detection is automatic.

I need a bit more time to test the greyscale sensor data. I'll get back to you when I have something.

Mares Jaroslav wrote:Hi Rex,

Many thanks for your reply. Your updated DF4Scratch.zip really solved my points 2-3-4 and the ‘red/flashing green/100% green’ signalling levels of Vortex connection mentioned in point 1 are informative enough and don’t need to be changed.

I also understand your explanation of sensor programming troubles caused by commands in Scratch, which simply ask for a Vortex sensor value but have to do it by sending a HTTP request via extension helper and then waiting for answer which needs to come back on the same road. Yes, it’s no comfort but kids can learn anyway what a sensor is, what is it good for and how to program a robot responding to sensor values.

Unfortunately, I have to repeat my question you have avoided. Why do the Scratch sensor blocks work just once after Vortex’s start? I suppose that Vortex’s firmware uses a dictionary of sensor variables and executing a reporter block then simply returns the most recently reported value for the appropriate sensor variable. So when I wave in front of Vortex, the proximity sensor (an Arduino pin) signals true (1), and with my hand off this value should change to false (0). But this does not happen:
proximity.JPG

Similar test with the same result can be done with the greyscale blocks. Of course, as you clarified, their behaviour is more complicated, so I would be happy to solve the proximity first. I am looking forward to your response again.
userHeadPic Xia Rex
2016-02-02 06:35:39 Hi Rex,

Many thanks for your reply. Your updated DF4Scratch.zip really solved my points 2-3-4 and the ‘red/flashing green/100% green’ signalling levels of Vortex connection mentioned in point 1 are informative enough and don’t need to be changed.

I also understand your explanation of sensor programming troubles caused by commands in Scratch, which simply ask for a Vortex sensor value but have to do it by sending a HTTP request via extension helper and then waiting for answer which needs to come back on the same road. Yes, it’s no comfort but kids can learn anyway what a sensor is, what is it good for and how to program a robot responding to sensor values.

Unfortunately, I have to repeat my question you have avoided. Why do the Scratch sensor blocks work just once after Vortex’s start? I suppose that Vortex’s firmware uses a dictionary of sensor variables and executing a reporter block then simply returns the most recently reported value for the appropriate sensor variable. So when I wave in front of Vortex, the proximity sensor (an Arduino pin) signals true (1), and with my hand off this value should change to false (0). But this does not happen:

Similar test with the same result can be done with the greyscale blocks. Of course, as you clarified, their behaviour is more complicated, so I would be happy to solve the proximity first. I am looking forward to your response again.
userHeadPic Mares Jaroslav
2016-01-29 15:00:39 Hi,

Latest Release on github fixed the bottom light issue, using an 'init' command after connection. You don't need to go through the short dance ritual again.

Regards,
Rex
userHeadPic Xia Rex
2016-01-29 15:00:39 Hi,

Latest Release on github fixed the bottom light issue, using an 'init' command after connection. You don't need to go through the short dance ritual again.

Regards,
Rex
userHeadPic Xia Rex
2016-01-29 11:17:46 Hi,

Thanks again for such detailed feedback. I'll get to each of your points.
1. The green dot indicates if a vortex is being connected with steady communication. Our communication service program uses time out mechanism so it responds with a bit of latency. Only a Vortex with default firmware installed will interact with the service and keep the green light on. This is expected. If the flashing seems to be confusing we might need to find a way to make it red.

2. That has something to do with the connection method. If the Vortex is connected via bluetooth, then it will act as such. But if connected with cable, the signals goes through serial port directly and bypasses bluetooth. So it has no idea. Vortex, or Arduino compatible devices, does not regard serial port connection as stateful as bluetooth connection, it just sends and reads signals from it, regardless if the serial port is connected or not. We will put this point into consideration for our next iteration of Vortex firmware design.

3. Same as above. Maybe we can find a way to consolidate its behaviour. Still, Vortex is mainly designed for Bluetooth connection so please do not be discouraged if we assign higher priority to functions related to Bluetooth.

4. I'll revisit the color scheme and make changes to the menus accordingly. Thanks for the heads-up.

5. Greyscale and proximity does need some explaining. We must remind you that programming with sensors are harder with Scratch because they have significant latency with bluetooth/network traffic overhead. Network traffic overhead is more and inevitable because that is how Scratch talks to its extensions.

Another big thumbs up for spotting the bug in the extension description file. I did not notice that because I did not use 'duplicate' function during testing. Good to know.

One thing I must clarify is how the greyscale sensor actually works with Scratch. Fact is, they work not so great in the form of a bool status. Greyscale sensors sense the change of the surface color beneath the sensor. It triggers whenever there is a change, whether it is white to black or black to white. In fact you don't need the sensitivity block for this to work at all. The threshold is hard coded. That redundant block will be removed.

We have to admit that we did not put too much effort on the greyscale sensor functions because they are too slow to respond, and the latency is sporadic due to the large network traffic overhead. You cannot easily program sleek sensor based programs on Scratch, but you can program simple examples like hand-waving signals, or 'reverse wheels when stepped on a black line'. This is entire reason that we promote our WhenDo application on iPad. It enables native programming without any overhead.

We will dig into 'sensing' blocks in Scratch and see if we can migrate some of the functions to there.

I have released updates regarding greyscale threshold block and eye color fix.

Thanks again.


Mares Jaroslav wrote:I have searched for the cause of the damaged program in my post above and found another deficiency of S4V solution. Scratch 2 Offline Editor can input so called extension description file, where all additional command and reporter blocks are described (its format is available on Scratch wiki). These blocks then appear in the More Blocks palette. Scratch cannot execute them itself but calls another application that must be installed as part of extension.

In our environment the extension description file is ‘vortex.s2e’ (in ’contents’ folder). Its lines belonging to two greyscale blocks are visible in the picture below. The trouble is that both, i.e. the command block and the reporter block use the same (yellow) name as a reference to appropriate operation or sensor variable. It seems that Scratch identifies blocks in saved programs by this name and always uses the first line only while opening a file. Therefore any Scratch program containing the block placed in vortex.s2e in the second place will be always damaged when saved.

grayscale.jpg
userHeadPic Xia Rex
2016-01-29 11:17:46 Hi,

Thanks again for such detailed feedback. I'll get to each of your points.
1. The green dot indicates if a vortex is being connected with steady communication. Our communication service program uses time out mechanism so it responds with a bit of latency. Only a Vortex with default firmware installed will interact with the service and keep the green light on. This is expected. If the flashing seems to be confusing we might need to find a way to make it red.

2. That has something to do with the connection method. If the Vortex is connected via bluetooth, then it will act as such. But if connected with cable, the signals goes through serial port directly and bypasses bluetooth. So it has no idea. Vortex, or Arduino compatible devices, does not regard serial port connection as stateful as bluetooth connection, it just sends and reads signals from it, regardless if the serial port is connected or not. We will put this point into consideration for our next iteration of Vortex firmware design.

3. Same as above. Maybe we can find a way to consolidate its behaviour. Still, Vortex is mainly designed for Bluetooth connection so please do not be discouraged if we assign higher priority to functions related to Bluetooth.

4. I'll revisit the color scheme and make changes to the menus accordingly. Thanks for the heads-up.

5. Greyscale and proximity does need some explaining. We must remind you that programming with sensors are harder with Scratch because they have significant latency with bluetooth/network traffic overhead. Network traffic overhead is more and inevitable because that is how Scratch talks to its extensions.

Another big thumbs up for spotting the bug in the extension description file. I did not notice that because I did not use 'duplicate' function during testing. Good to know.

One thing I must clarify is how the greyscale sensor actually works with Scratch. Fact is, they work not so great in the form of a bool status. Greyscale sensors sense the change of the surface color beneath the sensor. It triggers whenever there is a change, whether it is white to black or black to white. In fact you don't need the sensitivity block for this to work at all. The threshold is hard coded. That redundant block will be removed.

We have to admit that we did not put too much effort on the greyscale sensor functions because they are too slow to respond, and the latency is sporadic due to the large network traffic overhead. You cannot easily program sleek sensor based programs on Scratch, but you can program simple examples like hand-waving signals, or 'reverse wheels when stepped on a black line'. This is entire reason that we promote our WhenDo application on iPad. It enables native programming without any overhead.

We will dig into 'sensing' blocks in Scratch and see if we can migrate some of the functions to there.

I have released updates regarding greyscale threshold block and eye color fix.

Thanks again.


Mares Jaroslav wrote:I have searched for the cause of the damaged program in my post above and found another deficiency of S4V solution. Scratch 2 Offline Editor can input so called extension description file, where all additional command and reporter blocks are described (its format is available on Scratch wiki). These blocks then appear in the More Blocks palette. Scratch cannot execute them itself but calls another application that must be installed as part of extension.

In our environment the extension description file is ‘vortex.s2e’ (in ’contents’ folder). Its lines belonging to two greyscale blocks are visible in the picture below. The trouble is that both, i.e. the command block and the reporter block use the same (yellow) name as a reference to appropriate operation or sensor variable. It seems that Scratch identifies blocks in saved programs by this name and always uses the first line only while opening a file. Therefore any Scratch program containing the block placed in vortex.s2e in the second place will be always damaged when saved.

grayscale.jpg
userHeadPic Xia Rex
2016-01-27 18:55:49 I have searched for the cause of the damaged program in my post above and found another deficiency of S4V solution. Scratch 2 Offline Editor can input so called extension description file, where all additional command and reporter blocks are described (its format is available on Scratch wiki). These blocks then appear in the More Blocks palette. Scratch cannot execute them itself but calls another application that must be installed as part of extension.

In our environment the extension description file is ‘vortex.s2e’ (in ’contents’ folder). Its lines belonging to two greyscale blocks are visible in the picture below. The trouble is that both, i.e. the command block and the reporter block use the same (yellow) name as a reference to appropriate operation or sensor variable. It seems that Scratch identifies blocks in saved programs by this name and always uses the first line only while opening a file. Therefore any Scratch program containing the block placed in vortex.s2e in the second place will be always damaged when saved.

2016-01-27 18:55:49 I have searched for the cause of the damaged program in my post above and found another deficiency of S4V solution. Scratch 2 Offline Editor can input so called extension description file, where all additional command and reporter blocks are described (its format is available on Scratch wiki). These blocks then appear in the More Blocks palette. Scratch cannot execute them itself but calls another application that must be installed as part of extension.

In our environment the extension description file is ‘vortex.s2e’ (in ’contents’ folder). Its lines belonging to two greyscale blocks are visible in the picture below. The trouble is that both, i.e. the command block and the reporter block use the same (yellow) name as a reference to appropriate operation or sensor variable. It seems that Scratch identifies blocks in saved programs by this name and always uses the first line only while opening a file. Therefore any Scratch program containing the block placed in vortex.s2e in the second place will be always damaged when saved.

2016-01-26 18:16:00 Now I see the second screenshot is even worse. By some mistake Scratch displayed there non existent blocks 'If turn grayscale check then'. They all should be read as 'if grayscale then'. I am very sorry for that confusion. Yet I confirm the results of my experiments. Regards Jaro. userHeadPic Mares Jaroslav
2016-01-26 18:16:00 Now I see the second screenshot is even worse. By some mistake Scratch displayed there non existent blocks 'If turn grayscale check then'. They all should be read as 'if grayscale then'. I am very sorry for that confusion. Yet I confirm the results of my experiments. Regards Jaro. userHeadPic Mares Jaroslav
2016-01-26 01:59:01 Thanks to Rex’s post to my last contribution (thread named ‘Error message/red dot when trying to connect to Scratch’) I am now able to put the Scratch into operation. Nevertheless, some troubles still remains. Using Win7 64 bit with Vortex connected by USB cable I found the following:

1) After successful start of ‘Launch Vortex Communication Service‘ the red dot displayed in Scratch–More Blocks (next to DF Robot title) is changed to green. But the green briefly flashes to red every six seconds or so. Only after Vortex is switched on, the green dot remains stable.

2) The S4V tutorial says that when the Vortex is connected, its lights have constant brightness. Of course, my Vortex is connected in spite of its lights repeatedly brightening up and fading, as it obeys most Scratch commands in this state. It plays and stops music, it moves, rotates, dances, sets its facial expressions and eye colors. But at the same time, it does not set its bottom lights (they brighten up and fade still again), and even starts autonomous dancing when pushed forward and also reacts to hand waving just like it does without any external control. I would call it a semi-connected state:).

3) Anyway, I have found a way how to connect it fully.

After my Vortex dances one second and then stops, its bottom lights get constant brightness and can be set by appropriate Scratch commands. So I start this short dance at the beginning of each programming session.

I have checked all Scratch commands listed for DF Robot (except of just two top lights settings as the top LEDs do not light without the top dome mounted and this is impossible for me because of USB cable) and noticed just two problems described below.

4) The first is only a tiny bug: some color names in the following command menu do not correspond to reality


5) The second problem bothers me more - I do not know how to bring to life the proximity and grayscale sensors. Autonomous Vortex indicates waving close to him, so the proximity sensor certainly does work. I was not so successful checking the line following sensors autonomously, probably I am not clever enough. Anyway, I have checked both sensors in Scratch. Surprisingly they both work but just once after the Vortex start. Then both keep the last read value until a Vortex restart. Do they need a reset? I don’t know. Hopefully Rex or another DFRobot expert could help?
userHeadPic Mares Jaroslav