Asked
— Edited
All script examples are on the EZ-Cloud for download and updated after each additional post Download Now
Index
Part 1 - You are here
Part 2 - Page 1 Post #6
Part 3 - Page 1 Post #8
Part 4 - Page 2 Post #6
Part 5 - Page 2 Post #9
Part 6 - Page 3 Post #5
Part 7 - Page 4 Post #3
I have some time on my hands and nobody seems to be asking questions at the moment so I though I'd just write up a nice and simple introduction in to EZ-Script. I may write more in the future but we will see how received this is first.
EZ-Script is a powerful scripting language with a wide variety of commands. The command user manual is displayed to the right of the EZ-Script environment within ARC and a PDF version of the manual is maintained and downloadable from here.
Scripting needn't be difficult. A lot of people see lines and lines of code in the examples and are overcome by this however the number one rule in scripting, at least for me is to think logically, dumb it down and tackle one piece at a time.
I will go through how to write an example script in a logical manner and have a working script as an end result. In this example we will define variables, look at If statements, control devices attached to the EZB and read data from the EZB.
First we need to work out the algorithm for the task we want to achieve. Think of it as you think of a recipe when making a meal. It's a sequence of events in a specific order to achieve the overall result.
This example we will make our robot scared of contact and run away when anyone or anything comes in close proximity. In order to achieve this there are some hardware requirements;
Drive motors or servos
Proximity detector
For this example we will assume the robot is driven by DC motors via a 4 wire HBridge, with a correctly set-up HBridge Movement Panel in ARC and for proximity detection a low range infra red sensor connected via the ADC port ADC0.
So first, we need to think about what it is we are doing. We need to know if anything is coming in close proximity to the robot so we need to read the information supplied to the EZB via the infra red detector.
EZ-Script has a neat command for this, the GetADC command;
Quote:
GetADC( Port )
Returns the ADC value of the specified port
Example: GetADC(adc0)
So the first part of our code would be to get that ADC value and store it in a variable for ease of use. We will call this variable $proxsense. Notice the $ symbol preceding the variable name, this is required for all variables.
Code:
$proxsense = GetADC(adc0)
The value of ADC0 is now stored as the variable $proxsense.
So now that we have the value of the proximity sensor we need to use it. We need to know if someone or something is in close proximity to the robot, so we need to compare the value of ADC0 to a known close proximity ADC value. This varies on different hardware and testing may be required for accurate results. For the benefit of this example we will assume an ADC value of 50 or less is close proximity.
So let's add this as another variable;
Code:
$proxclose = 50
Easy right? It doesn't get much harder either
So we have the current sensed proximity value and the minimum allowed proximity value stored as variables. We want to be able to do something if the sensed proximity is more than the maximum allowed proximity. If you read that sentence you may be able to work out the next command we need to look at...
The IF command;
Quote:
If (Value Condition Value )
IF condition can support multiple comparisons and functions.
Condition tree must be closed with an ENDIF
See the Functions section of this document.
Condition can be =, , =, , AND, OR
Example:
If (GetDigital(D0) = 1)
Print("One")
EndIf
Example:
If ($Day = 2 AND $Hour = 3)
Print("Hello")
EndIf
So let's look at this logically, we have the sensed proximity, the maximum allowed proximity and want to see if one is higher than the other.
Code:
IF($proxsense > $proxclose)
ENDIF
This will look at $proxsense, check it against $proxclose and if it is greater than (>) $proxclose it will run the next commands. If not then it will jump down to the endif command. All if statements must be finished by an endif command.
So the code so far should look like this;
Code:
$proxsense = GetADC(adc0)
$proxclose = 50
IF($proxsense > $proxclose)
ENDIF
While the code will compare the values it still doesn't do anything. Nothing has been defined in the if statement. But what we have achieved is for the script to now be able to find out if someone, or something is in close proximity to the robot.
So now we want to have the robot do something if the statement is true. The next question is what do we want it to do if someone or something is too close? We want it to run away, all scared and full of panic.
So how do we do that?
First we decide if we want the robot to just reverse away, as if running backwards. We could, but do you run backwards? No, you turn and run. So we will make the robot turn 180 degrees (roughly) and run away.
How do we do this in EZ-Script? Easily!..
EZ-Script has all five of the Movement Panel commands. Forward, Reverse, Stop, Left and Right;
Quote:
Forward( [speed], [milliSeconds] )
Using a Movement Panel Control, this will start your robot in the Forward direction.
Optionally, you can provide the speed and/or number of milliseconds to move.
You will require at least one Movement Panel to be configured within the project. This function will control that movement panel.
Speed is a number between 0 and 255
Example: Forward()
Example: Forward(200)
Example: Forward(255, 5000)
Reverse( [speed], [milliSeconds] )
Using a Movement Panel Control, this will start your robot in the Reverse direction.
Optionally, you can provide the speed and/or number of milliseconds to move.
You will require at least one Movement Panel to be conf igured within the project. This func tion will control that movement panel.
Speed is a number between 0 and 255
Example: Reverse()
Example: Reverse(200)
Example: Reverse(255, 5000)
Stop()
Using Movement Panel Control, this will stop your robot.
You will require at least one Movement Panel to be configured within the project. This
function will control a movement panel.
Example: Stop()
Left( [speed], [milliSeconds] )
Using a Movement Panel Control, this will turn your robot left.
You will require at least one Movement Panel to be configured within the project. This function will control that movement panel.
Optionally, you can specify the speed and/or number of milliseconds to turn.
Speed is a number between 0 and 255
Example #1: Left()
Example #2: Left(200)
Example #2: Left(200, 5000)
Right( [speed], [milliSeconds] )
Using a Movement Panel Control, this will turn your robot right.
You will require at least one Movement Panel to be configured within the project. This function will control that movement panel.
Optionally, you can specify the speed and/or number of milliseconds to turn.
Speed is a number between 0 and 255
Example #1: Right()
Example #2: Right(200)
Example #2: Right(200, 5000)
Direction of turn doesn't matter so either the left or the right command would be suitable. For the purpose of this example we will turn left. To turn 180 degrees is not an exact science since the robot has no means of knowing it's direction. Turning is time based and this must be calculated by timing your robot for how long it takes to rotate 180 degrees. For the purpose of this script we will assume the robot rotates 1 degree in 0.1 milliseconds or 180 degrees in 1800 milliseconds.
Code:
LEFT(255,1800)
Now that the robot has done an about turn and is facing away from the scary thing in front of it it needs to run forwards to get away. So a forward command is issued. We will make it run away for 5 seconds.
Code:
FORWARD(255,5000)
And that's it. As simple as that. So the code so far should look like;
Code:
LEFT(255,1800)
FORWARD(255,5000)
Now let's put it all together. We can do this a couple of ways. One way would be to put the left and forward commands inside the if statement, and if you have a basic script there is nothing wrong with that at all but I want to show you the Label, Goto and Return commands too;
Quote:
:Label
Defines a label for a GOTO() command
Example: :My_Label
Goto( label )
Goto a specific :Label location
Example: Goto(My_Label)
Return()
Return from a Goto()
If you jump to a position of code with a Goto(), the Return statement will allow you to return back to that piece of code following the last Goto()
If you attempt to Return() with an empty stack, nothing will happen. The script will ignore the Return() statement.
Example: Return()
These commands can be used to set up what I like to call Sub Routines. A small piece of code which can be called up from many places within the code. These are great if your script is long and manages many different tasks that all may require the same sub routine.
So we set up the "runaway" sub routine;
Code:
:runaway
LEFT(255,1800)
FORWARD(255,5000)
RETURN()
And then we add in the Goto to the first part of the code we wrote;
Code:
$proxsense = GetADC(adc0)
$proxclose = 50
IF($proxsense > $proxclose)
GOTO(runaway)
ENDIF
And when we put it all together;
Code:
$proxsense = GetADC(adc0)
$proxclose = 50
IF($proxsense < $proxclose)
GOTO(runaway)
ENDIF
:runaway
LEFT(255,1800)
FORWARD(255,5000)
RETURN()
At this point there is an obvious problem. Once the script runs and the if statement is run it follows on to run the runaway code, regardless of the outcome of the if statement. It also only runs once. This is taken care of with another label and another goto command. The label at the start of the script and a goto after the endif. This loops the script around forever.
The code should now look like this.
Code:
:loop
$proxsense = GetADC(adc0)
$proxclose = 50
IF($proxsense > $proxclose)
GOTO(runaway)
ENDIF
GOTO(loop)
:runaway
LEFT(255,1800)
FORWARD(255,5000)
RETURN()
The last thing to tackle is the demand the script above may have on the hardware and your PC. Reading from the ADC port can be demanding on the system. The way to overcome this is with a Sleep command, which pauses the script for the desired time.
Quote:
Sleep (milliseconds)
Pauses for specified milliseconds
Example sleeps for 1 second: Sleep(1000)
To restrict the number of reads of the ADC port we will add in the sleep right before it loops around, giving a sleep command for 1 second.
Code:
:loop
$proxsense = GetADC(adc0)
$proxclose = 50
IF($proxsense > $proxclose)
GOTO(runaway)
ENDIF
SLEEP(1000)
GOTO(loop)
:runaway
LEFT(255,1800)
FORWARD(255,5000)
RETURN()
And there we have it, the completed script. It's simple yet effective. The script will run, it will then check the value of ADC0, check if this is less than the minimum allowed value, if it is then it will jump down to the "runaway" sub routine, turn left, run forwards and return back to the main script. If not then it just loops around and around forever.
This post has not been written with the intention of showing a detection script but more for showing how to tackle writing any script. I hope you can now take what I have shared above and start creating your own scripts and routines to make the robot perform the tasks you require it to perform.
If you have any specific tasks that you would like to achieve but cannot quite figure out where to start please mention them and we can all discuss the way to do this, break it down piece by piece like the above and find you your solution.
Last time we went through changing the IR sensor to Ultrasonic. Now we will change the script for 3 IR sensors to give the option of 3 IR or Ultrasonic Sensors.
So we start of with the code for 3 IR sensors from Part 4;
Code:
The key areas to adjust in this script are the variables, to allow for the option of IR or Ultrasonic and the runaway and sensorcheck sub routines.
We already know, from Part 5 that the ultrasonic sensors require 2 digital ports, one for Trigger and the other for Echo. So we know that we need some variables for these ports added at the top of the script. We also want to add in the option variable for choosing IR or Ultrasonic.
So we visit the variable area of the script;
Code:
Since it's getting big, and it's all about making things as easy as possible while we are here we will also restructure it to make it easy.
First we want to set out the Options such as sensor type and only when moving forward;
Code:
Next we will set up the movement configuration;
Code:
Then we will set out all of the Port Configuration including the 6 new variables for the Ultrasonic sensors.
Code:
And finally we need to put down the detection sensitivity configuration
Code:
Now it looks like a really complex script but really all we have done is set up a bunch of variables. This shows my point about breaking down code to figure it out, a lot of the time it will look a lot worse than it is.
Combine all of the smaller pieces of the configuration to give you the start of the script;
Code:
Now we have the variables all set up it's time to tackle the sub routines.
We will want to look at the sensor check routine first as without it the runaway routine wouldn't know the direction to turn in. So we have the routine from Part 4
Code:
In to that we need to add a few things. First the code for checking the ultrasonic sensors and second the commands to decide which sensors to check.
Adding in the code for the ultrasonic sensors is pretty much the same as Part 5 changing the code. But in this case we leave the IR code in there also.
The code to check a ultrasonic sensor is;
Code:
We want to assign these to variables like the IR readings so for all three sensors we would have something like;
Code:
But, we only want those commands run if the configuration says so. The same goes for the IR code. So we add in another IF to check on the option and run the code if it is turned on.
Code:
So now the code to check the ADC and Ping will only run if the configuration is set to check them. And that's almost it for the sensorcheck sub routine, all that is left is the code to run the runaway code;
Code:
Simply add it to the above code;
Code:
Now the code will check the sensors as specified in the config and if any of them fall within the conditions it will run the runaway code.
So now we need to look at the runaway code. The final part of this.
Code:
So it's already set up for the IR sensors from Part 4 but we need to add in the same kind of checks as the sensorcheck code had added while on the other hand avoiding any rouge commands from unused sensors. A few more IFs come in to play here again, just like the sensorcheck.
Code:
And then put all of that together and you have the final code for Part 6
Code:
Now I have deliberately left one minor bug in the code somewhere. I will reveal it and tackle it in a later post but I figured if I was getting tired of writing this then you would be getting tired of reading it, so digest the above until next time. See if you can find the bug and feel free to post about it (I leave myself open for other bugs doing this but hey, all of us are learning including me).
Adding in test mode may well be the next part and overcoming the minor bug mentioned. Both should tie in nicely together.
As always this script example, while will run fine and function correctly is not supposed to be a working example for a useful function but supposed to explain the methods used to have actions and commands run depending on circumstance.
I have a project that needs to decode a digital circuit using bcd 1,2,4 and 8 using 4 digital I/0.
ANY help would be cool
It's leading up to this but with the variables and the IF nests to only check and run code depending on the variable we will eventually be able to use $time and $date or even other sensors, locations etc. to have the robot decide for itself which sensors to use.
A typical example is the IR sensor which dislikes natural light, or sunlight. Not a problem in the UK, we haven't seen the sun other than in movies or on TV. But if it's daytime you could have your robot only use the UltraSonic sensors. When it gets dark out it changes over to IR.
That wasn't it, although good eye
All fixed
I am following your robot build with great interest. It's going to be very cool.
Rex
And additionally, if it results in more people being able to put together scripts it means there are going to be loads of scripts for all to use, all doing different awesome functions.
I have plenty of plans for the small tutorials so expect them to continue coming for a while longer yet. There are things I've not yet touched on, there are things I have not even used myself yet but all will be covered eventually.
I'm waiting on my serial LCD display currently, I have a few plans for tutorials for using one of those with variables and making it display information or even animate text (if I can figure it out myself - I wont know until it turns up though).
Math functions are also something I want to cover too. The idea from the ping avoidance with sweeping servo script for having the robot center itself in a corridor is one I can't wait to explore and sharing that should be both informative and fun.
The best thing though is by explaining each step of the way I am finding I learn more too, and it gets committed to memory. Which is great as I can write script ideas while at work and figure out what's required, in what order etc.
Once again, thank you everyone for the kind words, they mean a lot. It's nice to see the appreciation after some things that have been popping up recently.
While a big bug was spotted it wasn't the one I was referring to. But due to the way I am writing these I kinda messed up while piecing the code back together - the code in the project file on the EZ-Cloud was correct (in my defence).
But the bug I was referring to is in this part of the code;
Code:
What could happen is a double runaway. The code first checks if IR sensors are active, if they are it will check to see which way to run away. Execute the run away (if required) and then check if Ping sensors are active, if they are will run away again.
I left this in as it lead on to the next part I wish to explain and example. The conditions that can be used within IF commands.
If we refer to the EZ-Script manual under IF we are told that;
I'm assuming the forums have replaced some of the conditions due to the formatting, but if it has just look in the EZ-Script Reference Manual. You will find it on page 5.
The conditions we need to look at are AND and OR. We want to combine the code above so that if both sensor types are enabled it will perform an AND and an OR check. Currently it just checks for AND, to ensure that two of the sensors are either higher or lower than the other (depending on sensor type) to determine which sensor has the closest proximity.
Using AND and OR in the same condition is pretty straight forward but you must write the condition correctly. Think about it logically, imagine someone is giving you instruction for instance "if the time is 12am and it's a monday or if the time is 4am and it's a saturday you should be asleep in bed" two separate conditions combined in one. It wouldn't make much sense if it was "if the time is 12am or the time is 4am and it's a monday or a saturday..."as you wouldn't know which time goes with which day.
So, let's take a look at the code and change it to avoid the bug. My way of doing this may be different to someone else's way but I'm a firm believer in stick with what you know. My way would be to adjust the whole routine and rather than use two different IF conditions which run one after the other to use one IF condition with ELSEIF so that if the first is true then the rest don't matter, if the first is false it checks the second, and so on.
We will also need to add in a further condition to check if both sensor types are to be used. In an effort to save the post becoming very long I will only post the outline of the code for now.
Code:
So now the code will have a choice of three options. The final ELSEIF could be just an ELSE, I prefer ELSEIF to ensure it only runs if the condition is met, it's personal preference really.
The code within the ELSEIF ($irsensor = 1) and ELSEIF ($pingsensor = 1) remains as it was however in the new code for both sensors at once we will need to combine the two.
This is where the AND and OR conditions come in to play. We need to work out what it is that needs to be true to run what code.
We know that;
If the left hand sensors detect proximity we need to move right
If the center sensors detect proximity we need to move left
If the right hand sensors detect proximity we need to move left
We also know that;
If the left hand IR reading is higher than the center IR reading and the left hand IR reading is higher than the right hand IR reading then something is to the left.
If the left hand Ping reading is lower than the center ping reading and the left hand Ping reading is lower than the right hand Ping reading then something is to the left.
If the center IR reading is higher than the left hand IR reading and the center IR reading is higher than the right hand IR reading then something is in front.
If the center Ping reading is lower than the left hand Ping reading and the center Ping reading is lower than the right hand Ping reading then something is in front.
If the right hand IR reading is higher than the left hand IR reading and the right hand IR reading is higher than the center IR reading then something is to the right.
If the right hand Ping reading is lower than the left hand Ping reading and the right hand Ping reading is lower than the center Ping reading then something is to the right.
So let's put that as IF conditions (very long if conditions);
Code:
So now it checks if the left IR is higher than the other two or the left Ping is lower than the other two. The same for the center and the same for the right.
And then it is just a case of adding in the code for turning the robot in the right direction, and putting it all back together
Also, the sensorcheck code needs a slight adjustment;
Code:
This code will currently run checks on the IR if applicable, then could run the runaway code without knowing the ping sensor readings. Then it will run the runaway code after receiving the Ping sensor readings again (if applicable), that's if it hasn't halted on error.
To overcome it is very simple with IF. First we need to check which sensors are active with the
Code:
much like in the above routine.
Then the required code for checking only the sensors used added in to the IF and ELSEIF conditions, with the code for both sensors having the IF condition for running the runaway code checking all three IR sensors and all three Ping sensors, if any are true then runaway.
Code:
You could, if you wanted to, add in two new sub routines for getting the Ping and getting the IR sensor readings and replacing the code for Gotos however with only using the same code twice I have opted to just add it in twice. It's personal preference, personally once or twice I will type it all out, three or more and I like to make sub routines. I digress, but if you want to test what you are learning a good exercise would be to make the routines and call them up.
Now that the sensorcheck code is also fixed it's time to piece all of the bug fixed code together. You should end up with something a little bit like this;
Code:
Today and tomorrow were nothing but scripting basics, but was feeling a little lost. I've worked with Arduino and C++ a bit, and with tons of tutorials and videos available it was simple to get started with the basic principles do's and dont's.
Now I've found my lesson plan in your Lesson/Thread!
Blown away everyday by such an community and product! DJ, keep up the amazing work that you do! Love your passion
That being said, it is possible you will find something you can't do. If that happens, there is a .NET SDK that can either totally replace ARC (lots of work) or communicate with ARC (in my opinion, the preferred direction).
About the only thing that an Arduino can do that would be very difficult with an EZ-B are very timing sensitive automation actions like a balance bot. However, if you you find you need something like that you could combine your existing Arduino skills with your new EZ-Robot skills by having the two devices communicate with each other via the UART port, so EZ give the commands and Arduino follows them and returns data. @Luis Vazquez gives a great example here: http://www.ez-robot.com/Community/Forum/Thread?threadId=6577
Alan
The Master controller is the EZB4 of course, but many functions will be handled by Arduinos coupled with a PCduino to allow multi platform programming to access/control various parts of the robot.
Simple thing, rules can trip people up when learning a programming language, such as,
int yellowOnTime=250
Example: Once you know it, it seems obvious, but knowing that a Cap letter must used in the word On and Time in this string is a must, but without knowing that it is an actual rule, you could easily mistake it for a typo, an not realize how important it is. "basic principles do's and dont's".
So thats my mission today, is to understand the basic elements, and rules.
Alan
See this thread. Already been done
http://www.ez-robot.com/Community/Forum/Thread?threadId=6886
(well, already done using Speak or SpeakEZB command. Replacing that with sound board should be a relatively simple exercise)
Alan
If you want me (or Rich) to write the script for you, I can add it to my already too long todo list, but you could figure it out a lot faster than waiting on me to get around to doing it for you
Alan
Proxsense is the value of the sensor and is fetched from the sensor so doesn't need the initial declaration.
@Anthony, that would be a very simple script adaptation to the time script I posted a few weeks back. The sound file played back can be a variable. Use ifs to piece together yhe phrase and ControlCommand to make it play the correct files in the correct order. It wont be as fluid as text to speech though.
I'm still away at the moment but when I get back home I'll add it to the to do list.