You can use a Camera in ARC as a button without any external code. I created a custom multicolor named "Dark" and set it a orange/red range and I set it to the maximum size for detection. This is what worked best for me as I discovered the orange/red color range was reflected off my hand as it moved toward the camera to block the view.
I started out using the darkest shade of blue possible but that color did not perform as well for me. I encourage you to experiment as skin tone, lighting conditions and even the type of camera will very from user to user.
Below is my script which I named CamBlocked It only looks for the $CameraObjectColor value to change and so this scripts acts as a sort of "hair trigger". Code:
#updated 7/21/14
$CameraObjectColor = ""
:Start
IF ($CameraObjectColor = "Dark")
ControlCommand("Bender Sounds", Track_19)
sleep(500)
ENDIF
$CameraObjectColor = ""
sleep(500)
goto(start)
The line below is the action I have chosen to perform when my "Dark" multicolor object is detected.Code:
ControlCommand("Bender Sounds", Track_19)
Video Tutorial:
Here is an alternative take on the script. Rich's modified script uses the WaitForChange function and $CameraIsTracking value. My tests showed that I had to wave my hand slowly more closely in front of the camera for 1-3 seconds in order to trigger the event.
Code:
#from Rich 7/21/2014
$CameraObjectColor = ""
WaitForChange($CameraObjectColor)
:Start
IF ($CameraObjectColor = "Dark")
ControlCommand("Bender Sounds", Track_19)
EndIf
WaitForChange($CameraIsTracking)
$CameraObjectColor = ""
WaitForChange($CameraObjectColor)
Goto(start)
If you test the two scripts, please let us know the results.
Upgrade to ARC Pro
Synthiam ARC Pro is a cool new tool that will help unleash your creativity with programming robots in just seconds!
Interesting and a great tutorial, thank you very much for sharing.
Back on topic for a moment though, the main script may work better if you used a WaitForChange() rather than a sleep. The way it runs at the moment it waits half a second after each pass of the IF and will repeat the command(s) in the IF if your hand if held over the camera for too long. Where if you used a WaitForChange() and didn't reset the variable back to nothing it would only loop back when the variable changes.
I haven't tried it so don't know if it would open up any problems but that's just my first thoughts on the script part of it. I'll give it a try when I get chance but just putting it out there if anyone fancied trying a different method to the scripting part.
Code:
Code:
It'll hold at that line until the colour changes.
Code:
It'll detect the "Dark" multicolor, but the variable $CameraObjectColor no longer changes. It seems to make the above script work once and done. I believe in part it is because I am not currently tracking any other multicolor. I added another multicolor and the above script worked again after another multicolor was detected.
If I wanted to look for the color dark....then ignore it until another color was detected and then watch for it again I think the WaitForChange would work.
I think part of your idea Rich was to show a way to avoid multiple triggers of the camera button function? In my video Bender usually detected the multicolor a couple of times so the "gasp" sound file had the effect of being pressed, play, play, play. Which sounds cool when used as a way to make the robot appear afraid. But if you were using the camera as a button to active another function like a motor control you would not want forward, forward, forward or script start, start, start - that might be bad!
I added an extra sleep within the IF statement and this appears to correct for multiple triggers.
Code:
a) fires the event continuously if the camera is blocked
b) needs to be blocked for half a second
Not huge deals but not as smooth as I personally would go for.
A way around that would be to use WaitForChange. This also reduces the load on the system resources since it's not looping around twice a second.
Since the camera control doesn't revert the variable $CameraObjectColor back to nothing when that colour isn't detected you will still need to figure out a way to reset this when it's not detected.
So we use a WaitForChange() for this too.
We WaitForChange in the $CameraIsTracking variable since when it's not tracking the colour it will be 0 and when it is it will be 1. This holds the script at that point until it changes. After this change we can reset the colour variable.
Once reset to nothing we can WaitForChange in the $CameraObjectColor variable. This will hold the script at that point until the variable changes i.e. until it detects darkness again.
So with both of these added in, the code should look like this;
Code:
Running it should reset the colour in the variable.
Wait until the camera is tracking
Reset the colour in the variable
Wait until the colour changes again
Then loop around
Writing this I've spotted the first time it is covered it wont detect until the hand is moved away again but that's a simple problem to solve...
Code:
If the colour isn't "Dark then the IF will fail, the command wont run, it will stop until tracking again, reset the colour to nothing and wait until it's detected again.
This should, at least in theory, provide a much smoother detection.
DJ said on the first threat about this - "Configure the drop down for how many frames before object is considered tracked. " That suggests the CameraIsTracking trip point can be adjusted, but I'm still not sure where that is at specifically. If anyone has a screen shot of where the option is I would appreciate it.
With the $CameraIsTracking value added to the modify script I find I need to move my hand closer and wave it slowly for 1-3 seconds, almost touching the lens in order to capture a longer box detection in the preview window in order to prompt the change in value for $CameraIsTracking.
This is very neat to see the results from our two scripts. Thank you Rich.