Resolved by JustinRatliff!
So I'm getting an error that says: " Error on line 21: Variable not defined: $Associate " So how do I define a variable? Code:
Code:
:Start
# check for motion
if(getDigital(D18)=1)
Print (" associate detected")
$Associate = Y
$AssociateTime = $time
sayEZB(" I SEE a associate")
sleep(3000)
endif
if(getDigital(D17)=1)
$Customer = Y
$CustomerTime = $time
Print ("customer detected")
sayEZB(" I SEE an Customer. ")
sleep(3000)
endif
# Lets see if we need to greet associate
if($Associate = Y)
if($AssociateGreeting = N)
$AssociateGreeting = y
# turn head to look in associate direction LEFT
Servo(D0,135)
Servo(D1, 100)
print(" Greeting Associate")
if($customer = N)
$x101 = GetRandom( 1,7 )
if($x101 = 1)
SayEZBWait(" sIR ")
elseif ($x101 = 2)
SayEZBWait(" HELLO SIR ")
elseif ($x101 = 3)
SayEZBWait(" hello ")
elseif ($x101 = 4)
SayEZBWait(" Hi")
elseif ($x101 = 5)
SayEZBWait(" hi there ")
elseif ($x101 = 6)
SayEZBWait(" back a gin sir? ")
endif
$x101 = 0
else
$x101 = GetRandom( 1,7 )
if($x101 = 1)
SayEZBWait(" Sir can you help this costomer? ")
elseif ($x101 = 2)
SayEZBWait(" HELLO SIR this costomer needs your help ")
elseif ($x101 = 3)
SayEZBWait(" hello sir, we have a costomer ")
elseif ($x101 = 4)
SayEZBWait(" Sir we have a customer who needs your help. ")
elseif ($x101 = 5)
SayEZBWait(" Sir we have a customer ")
elseif ($x101 = 6)
SayEZBWait(" Customer sir. ")
endif
$x101 = 0
endif
# face forward
Servo(D0, 90)
Servo(D1, 100)
endif
endif
goto(Start)
Code:
Just put $Associate ="null" or $Associate =0 or whatever at the beginning of your script.... You have it = y... but does y have a value?
Code:
And you also need to make sure what you set is the same value, because Y is the not the same is y. Lots of little mistakes.
Code:
To be sure not to have that happen, I initialize all of my variables in my init script, but that is just personal preference.
Alan
This is what Alan and Richard are talking about. You made a statement about variables being script wide. I just wanted to make sure you understood.
d.cochran, Being able to run several scripts and have them share variables is the difference between night and day. Now all we need is an expansion board for more pins. But I'm thinking I can get one EZB-4 to talk to a Arduino mega 2560 via serial. Then the EZB-4 will be the brain and the mega 2560 will be a slave. This will make my later project ( When I integrate the EZB-4 in to my existing R2D2's systems. But for now I'm using my associate droid as a learning point so I do not bugger up my R2. I will tell you that when I purchased my EZB-4's I got 3 of them and 2 cams. I have already mount the second EZB-4 in R2 already, its just not hooked up. While my R2 works just assume as it is. It is nothing more the a big RC toy. EZB-4 will give it autonomous functions when R2 is not in RC mode.
So Thanks for all the help guys!
My associate droid named Droid-Mun: https://www.youtube.com/watch?v=zvnVki1lYF0
My astromech droid R2D2: https://www.youtube.com/watch?v=UcoBHKIsNrY
ARC can control multiple EZ-B's which you know.
ARC can run multiple scripts at the same time, which you now know.
These scripts can run at the same time for the same EZ-B. This is the part that based on your statements I don't know you are clear on.
In the arduino world...
you write code and dump it to the arduino which loops through that code and does what you have told it to do. The arduino is a single threaded processor and can only do one thing on each clock cycle of the processor. You can split up those cycles using some tricks but only one thing per cycle can be done.
In the EZ-Robot world, your computer is the brain and can do multiple things on each clock cycle based on the number of cores your computer processor has. This is commonly a minimum of 2 and sometimes up to 128 if you are running on a huge server (actually now there are some that are higher than that). Most of the time it is 4 to 8 for consumer grade machines. ARC is a multi-threaded application which allows the use of these cores, and handles the logic needed to handle many more threads. I am not going to explain how this works as it is far beyond what I am trying to convey.
Lets say you want your robot to monitor its battery level, follow shapes and play some sounds at the same time. In the arduino world you would have to have it do this in a linear approach. It would do one thing, then do the next then do the next and then repeat. In the EZ-B world, you could start a script that is in a loop that monitors battery levels, start another script that follows shapes and then another script that plays sounds. All three of these could run at the same time. Now you could communicate between these scripts. By setting a variable in the script that is monitoring battery levels to something like $BatteryLevelIssue = 0 then the other scripts could just check the $BatteryLevelIssue in an if statement to make sure that it is not set to 1. If it is set to one, you could have these other scripts exit the loop that they are in and stop.
This is a different mindset than the arduino and one that is a bit difficult for some to grasp that are used to the arduino. I use arduinos for things like running a bumper sensor array and converting that data back to the EZ-B via serial. If there is something sensed by the arduino driven array, it alerts the EZ-B over serial which is being monitored by its own script. This script is doing nothing but looking for a serial feed from the arduino that would indicate that there is something in the path of the robot and setting a variable to let other scripts know which of the bumper sensors has been tripped. The other script uses this information determine what needs to happen to have the robot get a clear path to travel. Now, compass and other sensors could be employed and used by the V4. These could be used in the same script or in other scripts which can communicate with each other using variables. The compass could always be being read by the V4 or you could just start the script that reads the compass when you need a heading. This reading could be gathered by a script which would be setting a variable called $heading. The other script could use the $heading variable along with the bumper alert variable to then decide which direction (in degrees) the robot should move. Another script could then be called which would turn the robot to that degree (using the heading variable which is changing from the compass script as the robot turns). This script could report back to the navigation script that it has completed or simply set a variable saying something like $amnowincorrectdirection = 1 which the navigation script would be waiting on before telling the robot to continue to move forward.
This is an example that could then do so much more, but as you can see, the use of multiple scripts can become quite powerful. Also, having one script do one and only one thing and do it well allows you to then segment and test your scripts. Having a single script run which does everything can become quite difficult and it will be single threaded, which hurts the power of the platform you have to build on.
If you already understood all of this, great. If not, great. I just wanted to make sure you got what was being said.
Thanks.