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".
#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.
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.
#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.
Thank You, Justin. You are always coming up with good stuff to know.
Did you like how Bender kept interrupting, LOL. My next goal is a voice command "Shut Up!"
Great tutorial and creative use of the camera!
This is really great Justin. I can see how this can be used many ways. BTW you got a good video voice and do a great job producing this stuff. Very easy to follow despite Bender giving you a hard time.
Great video Justin ! This is what I call a very nice contribution to EZ-Robot ! Interesting and a great tutorial, thank you very much for sharing.
Great tutorial! Even better, I loved Bender. I was cracking up through the tutorial.
Thank you for all the positive feedback! This encourages me to keep producing tutorials.
Justin, dude... yes more videos.... you're one of the smartest guys on here... I learn a lot from you.... Unrelated.... here's a laugh.... I am "trying" to teach my self Python because I am jealous of a bunch of you guys knowing higher programming languages.... I love ARC and ez robot (lord knows I gave them enough of my money), but I just bought a raspberry pi and I want to lean more programming than just clicking a mouse...
Dude, Python is a pain, it depends too much on indentation if memory serves me correctly. While I know bits of Python it's not a language I wanted to spend more time than was necessary on. Good luck to you!
Thank you Richard! My hats off to you for learning Python. I have a virtual VMware Raspberry pi but I never have time to play with it. I'd like to hear about your experience with it as you learn more.
I hear you Rich... I am learning C too via arduino... one has to try new things to figure out for oneself what works and what doesn't... I mean if someone told me (and if I listened to them) that ez robot was lame, quite possibly I would have never discovered the awesomeness of EZ Robot.... Bottom line, I just want to expand my knowledge and contribute to some threads I previously had no idea what was being discussed... Just want to lean, that's all...
Oh don't get me wrong, I wasn't saying don't learn Python at all (learn it, that way I can call on you for help!). I'm in the same boat, trying to learn, just never seem to have the time to sit down with my Arduino or Visual Studio at the moment. The decent weather we are having at the moment doesn't help, we don't see the sun often so when it's out so am I
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.
That did not work at all. Unless I'm not implementing it the way you are describing?
It'll hold at that line until the colour changes.
Ok, I didn't catch the variable went in the brackets, my bad. I have this code now:
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.
I've just got home so give me 5 or 10 minutes and I'll have had a proper look at the script
My thinking is that in your script it does; 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;
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...
All it needed was a WaitForChange() for the colour at the top, this makes sure that the variable would be "Dark" before running the if for the first pass and therefore letting it work.
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.
Its still not working as hoped. I think what is negatively effecting it is $CameraIsTracking variable does not really change state when the motion of the hand moves up to the camera. So to the $CameraIsTracking variable may not change it all, while $CameraObjectColor would change to "Dark" and atleast trigger the event/sound once. If I remove the WaitForChange($CameraIsTracking) then the functionality goes back to an increase of multiple triggers (as the original script does).
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.
Really? $CameraIsTracking should change from 0 to 1 when the camera begins tracking pretty much instantly, at least it did when I tested it.
I think I see where the issue is. In my original script, I only look for $CameraObjectColor value to change to "Dark" and then I reset it to "" so the effect I get is anywhere a flash of my multicolor is detected, even for a hot second, my event is triggered. This gives the effect of a "hair trigger" and I can have my hand further away from the camera lens.
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.
I'll keep looking at the script and seeing if there are any other methods or ways to possibly improve detection etc. I'm sure I'll be doing that sub-conciously too - chances are I'll be driving along and suddenly have a thought about a different approach to it, that's usually when things hit me