Now that I have two 'bots, this raises the potential of the two robots being “mutually aware” of each other, with a preliminary goal of programming a game of “tag”.
One robot would be “it” and have to chase and corner the other robot. The other robot then becomes “it” and has to chase the first one.
Also if the robot cannot find the other robot, or cannot corner it in a period of time, it can resign, which causes the other robot to show itself and then the game can continue.
Question:
Any ideas on how to make the robots “mutually aware”?
Possible game plot twist:
Since there are visible mirrors in the room, it might be possible to program “distraction” where the robot “sees itself” in the mirror and stops to admire its own reflection for a few moments.
With a remote detector and remote emitter on each, each programmed to a unique code, they can “see” each other. A limited detection angle could be countered by each robot turning to scan for the other bot periodically, or a must spin every 60 seconds when hiding “rule”
Asymmetrical Capabilities
If gigglebot always gets to hide, and Charlie always does the finding, then Charlie could use the PiCamera to “see” either an LED of gigglebot, or use my “PiCamera Light, Color, and Motion Detection Sensor”, or go full machine learning and train a TensorFlow-Lite model to recognize the gigglebot in the PiCam image.
Even better - total software solution possible with PiCam and my GoPiGo3 PiCam Color-Motion-Light sensor.
Of course the hardware approach works as well.
And there is the double remote controlled remote view configuration with one of your grandDs driving each and searching only with the camera view… (you’ll have to set up a joystick on their laptops though.)
that was my first thought - using different colors on each Bot then having some software look for the colors. Might get confused by background colors, but if you used less common colors it could work.
/K
If each one has an ArUco marker “Flag”, they can use the PiCam to find each other and “tag” when achieve a distance sensor reading less than two body lengths.
Imagine Charlie is it, so he spins counting out loud to 60 spins 1… 2…3… (Charlie needs a speaker of course)
Meanwhile Charlene
spins until she “sees” Charlie’s Flag,
then turns 90+random theta
travels until distance sensor says can go no more
spins until she “sees” Charlie’s Flag
Watches her distances sensor for Charlie to come within two body lengths
Meanwhile, Charlie who has finished his “it spin”:
announces “Here I come, ready or not!” (Charlie really a speaker!)
Performs a slow scanning spin looking for Charlene’s ArUco flag
announces “I seeeeeee yoooooou”
turns to face Charlene and drives toward her
when he gets within 2 body lengths he announces “Tagged, You’re ‘IT’”, turns 180 and runs away.
If you want to get real fancy, they can send HTTP posts to each other’s remote-control-console to communicate.
The underside of Charlie already has a 5v power adapter for the Pi-4 to prevent power droop, remember? Likewise, the top is taken up with a liquid-paper display.
Perhaps I have good and sufficient reasons for not including a speaker?
Perhaps a talking robot isn’t high on my list of priorities, or a chattering robot would be annoying to me?
Perhaps, as a design choice, I prefer visual cues and feedback? (i.e. The robot that’s “it” would have red eyes and the other(s) would have green eyes.)
I understand that a speaker would be interesting, and perhaps useful in the same way that a LIDAR might be useful, but maybe I want to concentrate my efforts elsewhere?
I would rather spend my time, (and limited budget!), investigating a Bluetooth, LoRa, or IR signalling solution.[1]
Remember, US ATM cards don’t work here now because of political situations that I don’t feel like discussing on an open topic, and as a consequence I have to be very choosy about what I buy over here and very conscious of the price. A pan-and-tilt and associated distance sensor is my next priority for Charline.
I like the idea of an audio device of some kind, (perhaps a Bluetooth speaker), at some point in the future, but not right now.
[1] You folks have already done a lot of research into visual tags and camera recognition. I think that a parallel line of research into non-visual/non-camera recognition would also be useful.
P.S.
I found a couple of USB/self-powered and tiny Bluetooth/hard-wired speakers at a garage sale while I was in the States, but I’ve already given them to the girls. Maybe later if they abandon them?
P.P.S.
One of my design goals is to create simple solutions that can be used in a classroom environment to demonstrate the capabilities of the GoPiGo without needing huge amounts of AI or dramatically complex programming.
Ideally I would like at least a limited solution in Bloxter, and perhaps a more complete solution in generic Python.
Ouch, you asked, I offered some ideas. No judgement implied, no offense taken if you do your own thing.
A bloxter solution would be super cool.
The bloxter panel allows a camera view and having students write a key press remote controlled bot, that the students provide the game smarts would seem to be relatively straightforward and engaging.
FWIW, I had nothing but headaches with the Raspberry Pi BlueTooth Audio pairing mechanism. Wired solution-no problems.
The reason I push for robots to have a speaker, is from seeing the reactions of folks to Carl. When he does something physical, it rarely invokes a reaction. When he speaks, barks, meows, or plays “Ah-ooo-gah” they smile, laugh, and feel an anthropomorphic attraction.
Agree that adding stuff is complication and expense that are important considerations.
Actually the little Bluetooth speakers are an option because they include a combo USB (power) and audio jack cable - and are a manageable size.
Though, I have my hands full trying to replace the battery in my car-cam (a necessary accessory here) and it turns out to be more complicated than I thought.
