Asked — Edited

Function Request In ARC

Function request.

In speech recognition, on the setup menu I would like to be able to run a script before the Speech Phrase is spoken and one after Speech Phrase is spoken.

Secondly on the same page. It would be great to have a search box to search The Phrase list that trips the script. This would make it much easer to find specific entrees.

:D


ARC Pro

Upgrade to ARC Pro

Unleash your robot's full potential with the cutting-edge features and intuitive programming offered by Synthiam ARC Pro.

#1  

Slee, for the first request you said "In speech recognition, on the setup menu I would like to be able to run a script before the Speech Phrase is spoken and one after Speech Phrase is spoken."

Obviously after the speech phrase a script can run. But how would a script know to run before you ever speak anything? If there was a giant spider about to fall on your head to worn you I would need to speak first and say, "Giant Spider, better move!" before you react, correct?

United Kingdom
#2  

Can I ask, what sort of script do you want to run before speech recognition? I may have an idea.

#3  

I'm having issues where the robot hearse him self talking and the responds to it while in the middle of a script. This tends to crash the computer running the ARC. I have been using the ControlCommand("Speech Recognition", PauseOff) / ON in my scripts but because EZ-Robot can run many scripts at the same time its not always effective. I have also worked wit SayEZBWait("XXXX") but that only effects the script at hand and not the others running scripts as well.

As far as how to know if a phrase is a bought to be spoken, It appears to me ( and I may be wrong) but it looks like an IF statement is used to check each Phrase then starting the a prorate script. If that's the case then the command to run a start script right before the Phrase script is triggered and then an END script right after it has been triggered.

United Kingdom
#4  

Okay, the suggestions I was going to give you was to use a Cheat Sheet command for voice rec and SayWait that have already mentioned. The only other things I can suggest is using the "Enable Speech" phrase and "Enable Cmd" where you can add a script.

User-inserted image

Or in the speech command scrips, add a Cheat Sheet command to pause or disable the speech commands at the top of your scripts so nothing else can be heard while the script is running until the "Enable Speech" command phrase is used again. I can't think of anything else I'm afraid.

#5  

@Slee

Quote:

I'm having issues where the robot hearse him self talking and the responds to it while in the middle of a script.
The best way is using the Cheat Sheet commands to pause the speech control after you say a command (beginning of your script) and when the script is finished running use another Cheat Sheet command at the end of your script to un-pause the speech control...

#6  

@Slee,

Yes that is a familiar problem when the robot hears and talks to itself, there are a couple of my videos with "RedBender" where he comically does just that. My solution was just like RichardR said, script the pause and un-pause of the speech control.

United Kingdom
#7  

@Slee The Sloth.

Yes, the use of cheat sheets to pause the speech recognition control I mentioned in post #5 is something I use in all of my speech recognition scripts as I have I countered the same problems, and it works great.

It's a good idea though about having a search box to easily look for commands, especially when you have about 400/500 of them.

#8  

I have been working with the pause and un-pause of the speech control but they do not always work. Must work on my code a bit more. :)

#9  

You could attached your project file along with some more details on what it is doing that you don't want and we could take a look.

#10  

Sorry I did not post anything sooner. I have been vary busy in my shop. Thanks for all your help. :)

#11  

What I do is put ALL of the major portions of my Speech Recognition scripts in script manager scripts. Mostly in just one script for a given major script program. For example, you could have a script manager module called "Main Program". In it you could have a script called "Speech Responses." All the speech routines for Main Program would be in Speech Responses. The scripts in the individual scripts for the phrases to be recognized would be simple and short. Perhaps set a few variables, then go right to something like


CC("Main Program",ScriptStartWait,"Speech Responses")

One of my main programs is called "RPS Program". In RPS Program is a script called "RPS Main". RPS Main contains all the phrase responses associated with the RPS Program. The individual scripts in the Speech Recognition module for the individual phrases to be recognized are usually very short. Just the setting of some variables and then the calling of the RPS Main script, similar to that shown above. This centralizes the individual scripts for the Speech Recognition module. And that has the advantage of easy searching through them to find (Ctrl-F) any one you need to look at or change by a simple search of the RPS Main script. You don't need to look at every script individually in the Speech Recognition module to find what you want. Same when you want to do a Search and Replace (Ctrl-H).

Additionally, RPS Main does the usual housekeeping associated with the phrases response scripts. Such as turning the Pause Speech off and back on. Rather than doing that every time for every script, it's only done once at the beginning and end of the RPS Main script. If there are cases when you don't want that, you can declare variables to handle those situations with IF statements in RPS Main, setting them in the Speech Recognition scripts that need them. Generally, anything that is done in your software again and again can be handled centrally this way. I even route all my speaking functions through a central routine which handles things such as routing of the speech to either the PC speakers or the EZ-B Speaker or setting the volume (I like to boost the volume going to the EZ-B speaker, then set it back after the phrase is spoken). I actually go a step farther and route some things through central processing script(s) in a Script Manager called "General Robot Management" but I didn't want to throw that complication in here.

A typical sequence would go like this: Speech Phrase ="Cancel game" There are only 2 lines in the Speech Recognition script for Cancel game:


$PhraseToSay ="Are you sure you want to cancel the game?"
CC("RPS Program",ScriptStartWait,"RPS Main")

In the RPS Main script there may be many things starting things off but the salient points are:


CC("Speech Recognition",PauseOn)
SayWait($PhraseToSay)
If($SpeechPhrase = AAAA)
  DoSomething
elseif ($SpeechPhrase =BBB)
  DoSomethingElse
              | etc.
elseif($SpeechPhrase ="Cancel game")
   Do the operation associated with the phrase "Cancel game"
    #(transferred from the Speech recognition script for Cancel game.)
elseif $SpeechPhrase ="CCCCCC"
  DoYetSomethingElse
               |etc.
endif
CC("Speech Recognition",PauseOff)

$SpeechPhrase is a system generated variable that holds the last phrase spoken by the user. It is used to select the correct response via IF-ElseIF statements.

I list the phrase responses alphabetically (according to their first letter), in groups for faster responses. Listing them alphabetically like that allows the IF-ElseIF statements to skip entire blocks of scripts at a time. Like this:


$CharToUse =GetCharAt($SpeechPhrase,0) 
If $CharToUse ="a" OR $CharToUse ="A") 
  #Put all responses that begin with "a" or "A" under here
elseIf $CharToUse ="b" OR $CharToUse ="B") 
  #Put all responses that begin with "b" or "B" under here
                                 |etc.

Doing so would also make them easier to go through manually since they would be alphabetically ordered. Assuming you entered the scripts under the main alpha areas alphabetically as well. The second and third letter is also used in a similar fashion to further skip groups of scripts, making this method even faster. I further speed up the search by actually using goto statements, like this:


$CharToUse =GetCharAt($SpeechPhrase,0) 
if($CharToUse ="a" OR $CharToUse ="A")
  Goto(A_Section)
elseif($CharToUse ="b" OR $CharToUse ="B")
  Goto(B_Section)
             |etc.
endif
Goto(TheExit) #In case it gets this far

:A_Section
 #Put all As here
  #Use If Statements to choose the one that matches $SpeechPhrase
 Goto(TheExit)
:B_Section
  #Put all Bs here
  Goto(TheExit)
              |etc.

:TheExit
CC("Speech Recognition",PauseOff)

I am not showing the use of the second and third character from the phrase to further divide up the searching so as to keep things reasonably simple (yeah, I know, too late:) )

The main point I am making is that moving all the phrase response scripts to one external script can greatly facilitate script modifications and searches later. It can also aid in doing repetitive things in a central script rather than over and over in many scripts.

#12  

WBS00001 , You have some really good ideas here. Thanks for sharing them :)

#13  

@Slee The Sloth Thank you and you're welcome. The overall concept is broader and more complicated than I posted here. I just wanted to cover the concepts and provide some relatively simple examples. If you would like to know more about the real nuts and bolts let me know and I can post a project to the cloud that you could download and have a look. I could include a notepad with a description of what is going on. Although more complicated in some ways, it's also more compact in others. For example, I've adopted a shorter, more abbreviated script naming system. What I showed in the examples was wordy so as to convey the ideas through the names themselves.

#14  

I would like to see your scripting structure.
Sounds like a very good way to organize scripts and the responses or commands.

#15  

@OldBotBuilder Tying up loose threads today and wanted to let you know I am not ignoring you. I've been making some modifications to my methods that involves being able to remove ALL scripts from the script areas in the Speech Recognition window. This allows them to be ordered alphabetically and searchable. A must when you get to the point of having dozens, or even hundreds of phrases to deal with. If you use script managers to hold related scripts in an overall "program," you can even have a separate speech response evaluation script in each of them, further modularizing your code.

Anyway, I'll be posting an Example Project in the next few days. It will include a notepad containing explanations of it all, as well as, copious code comments in the scripts. :)

#16  

@OldBotBuilder et al I have uploaded a basic demo project of the method I used to move the scripts from the Speech Recognition control to an external script. I was writing up my whole project concerning this, which also addressed issues with using the scripting language for this sort of thing, as well as, ways to navigate around them. This more elaborate scheme was needed because I was also making it work such that the scripts from the Speech Recognition control could be distributed to several external scripts instead of just one. This allowed the speech evaluation scripts to be placed in a Script Manager along with other scripts pertaining to a specific overall operation. But I decided that for now, I would just present this aspect of the methods used.

There is a notepad in the project detailing the purpose of the scripts included and the concepts used. Let me know if you have any questions.

The project is titled ESRP (External Speech Recognition Processing).

I also have a method of assisting in the search of the entries in the Speech Recognition control. Right now the Speech Recognition control contains no methods for searching it. Even with the removal of the scripts to a searchable external script, there is still no way to search the phrases still in the Speech Recognition control. You can, however, add a few lines of code to each script to make it announce the row a given phrase is on by simply speaking the phrase.

What you would do is place the following in each script:


#1    
If($SRMode =$Search)
  SayWait("Row, 1" )
else
  Do the normal script as it is now
endif

Putting the number of the row in the first line of the script will result in that showing up in the script box right up front, giving you a line number to view as well. That will make it easier to get to the row number desired as you scroll through the rows. Also putting several spaces right behind the number in the first row will make it stand out better by pushing the next line back.

In this way, setting the variable $SRMode to the value of the variable $Search the Speech Recognition control will speak it's row number when you say the phrase associated with it.

Those variables would be declared wherever is convenient for you like this:


  $DoNotSearch =0 
  $Search =1
  $SRMode =$DoNotSearch  #current value

Then you simply set $SRMode to $Search when you want the Speech Recognition to say a location when you say the phrase, Setting it back to $DoNotSearch will keep it from doing that.

You can, alternatively, set $SRMode directly to "0" and "1" or True and False. It's not mandatory to declare $DoNotSearch and $Search. They just make the code more readable. At the very least, however, $SRMode has to be declared somewhere before it can be used.

Of course, if you are removing all the phrases to an external script then you simply put this script into each script area for each phrase.


#1    
If($SRMode =$Search)
  SayWait("Row, 1" )
endif

What will happen then is that the script in the external evaluation script will run first, then it will say it's row number. To prevent the script in the external evaluation script running you would have to put in an IF condition looking for the $SRMode variable to be $DoNotSearch to allow it to run. This could be placed at the beginning of the whole script so as to prevent anything from running until the $SRMode variable is set back to $DoNotSearch.

Naturally you have to change the number to reflect the row each is actually in.