Hide and Seek Robot...

Clear all

# Hide and Seek Robots - Request for Comments

67 Posts
8 Users
20 Reactions
6,439 Views
(@thrandell)
Brain Donor
Joined: 3 years ago
Posts: 231
Topic starter

I’m trying a new approach (for me) at defining my next robot project, and I was hoping that some of you ‘old hands’ could provide me with your comments.

Problem statement: Two or more robots that play hide and seek.  At the start of the game the seeker and one or more hiders are together in the center of the room.  As the seeker counts to 20 the others run away.  After the count to 20 they stop and the seeker starts to search for them. When a seeker bumps a hider, the hider acknowledges that it was found.  The seeker then starts looking for the next hider.  The game ends when all hiders are found.

Analyze statement looking for hidden assumptions about how a human might accomplish the task and the limits a robot will have:

• Does a seeker just randomly cruise around until it bumps a hider?  A human seeker can often search until it sees or hears the other player.  How will these players ‘see’ each other?
• How does a seeker count and a hider know when the count is over?  These players will need a voice, ears and the ability to count.
• How does a seeker know that it has found a hider?  How does a hider know when it has been found?  How do they communicate?
• How does the seeker know when the game is over?
• Human hiders won’t hide in the same way.  How do these players all hide in different ways?  In shadows, in bright light, along a wall, equal distant from all objects (in plain sight), behind the closest object (how does a player know that it is behind an object?), as far away as possible (full speed ahead).

Minimum set of competencies:

Communicate with other players: See other players, hear other players.  Hide, Avoid Hazards, Cruise, Escape Collisions, Follow, Seek.

Methods that enable each competency with existing technology:

• Communicate with other players: See other players, hear other players.  Players should possess IR emitters/detectors, instrumented bumpers, buzzers and microphones.  The seeker will use IR detectors to ‘see’ and home-in on a hiders IR emitter beacon.  After the count to 20 the hiders will need to turn on their IR emitters.  The bumper is used by both seeker and hider to initiate a ‘conversation’.  When the seeker bumps something it beeps and listens.  If the listening seeker doesn’t hear anything then it didn’t contact a player but something else and it would then continue seeking.  If a hider is bumped it listens, if it hears a beep then it beeps in return and is out of the game.  If there is no beep then the hider continues to wait and run its IR emitter beacons.
• Hide. There should be multiple ways to hide so that each player could employ different hiding strategies.  Accomplished by some combination of the avoid, escape, follow, cruise competencies.
• Avoid Hazards.  Use two IR proximity sensors to steer away from walls and canyons.
• Cruise. Quickly move forward using differential drive actuators.
• Escape Collisions. An instrumented bumper will allow an escape from ‘unseen’ obstacles
• Follow. An IR distance sensor will be used to follow walls, Also photo transistors will allow light following and darkness following.
• Seek.  IR detector tuned to the same frequency as the IR beacons will home-in on hiders.

Every question implies an action.  Is a collision eminent?  Is a wall adjacent?  Did I detect an IR emitter?  Has a collision just occurred?   Am I stuck?   Did I hear a beep?  Which direction is darker?  Which direction is lighter?

Match sensors to questions:

• Use IR proximity sensors for the avoidance behavior and an IR range sensor for wall following.
• Infrared detector, IR Receiver Sensor - TSOP38238.
• Infrared emitter, Super-bright 5mm IR LED - 940nm.  Sparkfun has a schematic to boost the range of the emitter beyond 10 feet!
• Bumper switches to allow the creatures to escape and communicate.  DigiKey has them.  How many would give coverage on all sides?
• Piezo buzzer for the seeker to ‘count’ to 20 before seeking the hiders.
• Microphone for hider to ‘listen’ for the count to 20 and to recognize when found by a seeker.  Also used by the seeker to confirm that it bumped a hider.
• Photo transistors could be used as proximity sensors for the Hide and Follow behaviors.  Use two for lightness and/or darkness differential steering.

Clear as mud?  Is there an easier way?

Thanks  Tom

To err is human.
To really foul up, use a computer.

(@robotbuilder)
Member
Joined: 5 years ago
Posts: 2045

@thrandell

I googled "robots playing hide and seek" and indeed it is something others have investigated. I guess it is like seeking prey and avoiding predators. I imagine you could use those little soccer playing robots to explore algorithms to implement such behaviours and to test any ideas.  I used to play with such things using simulated agents. Here is a snapshot of the display in one of my experiments in programming soccer player agents.

My personal interest now is in practical robots that I can actually build myself that can do something useful rather than robots to test theories about social behaviours.  It was an interest learning the physical requirements of a robot that resulted in my being here in the first place to see if I could learn anything useful from the tutorial of the DB1 build.

(@thrandell)
Brain Donor
Joined: 3 years ago
Posts: 231
Topic starter

It’s been a month since I sent out my ‘message in a bottle’ fishing for comments on a new robot design, so I’ve decided that it is time to set sail with all that I’ve learned from the sleepy seas that are The Dronebot Workshop Forum.

My wife tells me that the kids at the Elementary School where she works would get a kick out of robots that play Hide and Seek.  As long as there are lots of blinking LEDs!

To err is human.
To really foul up, use a computer.

(@robotbuilder)
Member
Joined: 5 years ago
Posts: 2045

@thrandell

Not sure what response you are looking for?

You say it is your next robot project so what was your first robot project?

(@thrandell)
Brain Donor
Joined: 3 years ago
Posts: 231
Topic starter

@robotbuilder

Well, feasibility I guess.

For example, I proposed that a piezo buzzer and a microphone could to be used for the players to ‘communicate’ when a bump contact was made.  Well, that’s turning out to be easier said then programmed.  The microphone senses vibration (acoustic wave) and turns it into a voltage.  I don’t think my MCU will have the cycles to convert that voltage into a frequency so I’m trying to find the piezo tone that elicits the biggest response from the microphone.

I think that I’m getting the most volume from the piezo.  I’m using a PWM signal with a 50% duty cycle and I’ve mounted the piezo on a little sound board.  So I’m playing around with grabbing voltage highs and lows during specific time slices, and timing the length of these voltage highs and lows.  Maybe I can recognize a 1 second on, 1 second off kind of protocol.  I’m making progress, but slowly.  The microphone has an adjustable gain so I’m also ‘tuning’ the response with that.

What works really easy with this microphone is a ‘clap’ switch.  The vibration of a clap just spikes the voltage like a champ!  This might also work for fax voice commands.  You could count the spikes and translate that into a robot command.

Tom

To err is human.
To really foul up, use a computer.

(@robotbuilder)
Member
Joined: 5 years ago
Posts: 2045

@thrandell

Perhaps use light instead of sound for a less noisy method? A modulated LED to send and a phototransistor to receive. You could in theory even use color coding with the RGB color LED and the RGB color sensor? The modulation is important to shield the signal from ambient light. A fast changing voltage will be passed by a capacitor while the constant or slow changing voltage will not.

With clapping you might use two microphones arranged such as to use the difference in volume to determine the direction of the sound.

If children are going to be involved then having the robot innards enclosed would probably be wise.

(@thrandell)
Brain Donor
Joined: 3 years ago
Posts: 231
Topic starter

@robotbuilder

I thought about using IR emitters/detectors to ‘communication’ after a bump.  I might use that idea if I can’t get the buzzer/microphone handshake to work.

As far as my previous project goes, I logged it on the Forum as Lewis & Clark.  It was a big step forward for me, but it can still get stuck.  It gets hung up on the bumper when doing small ledges and the wheels just spin.  Some kind of suspension would help.  Something like what you have with your repurposed vacuum robot.

To err is human.
To really foul up, use a computer.

(@robotbuilder)
Member
Joined: 5 years ago
Posts: 2045

@thrandell

There are not many experimental robot enthusiasts on the forum only some who have made a one off robot usually a replicate of some robot that is remote controlled or follows a line or chases a colored object rather than an experimental base to invent their own solutions.

I like the idea of building a practical robot that does something useful like the vacuum robot. This forum is essentially about the electronics but ...

"The building of my robot, TIMEL, began with an assumption: hobbyists who want to contribute to the emergence of intelligent home robots should concentrate their efforts on software. It might be expensive, but we can build hardware theoretically capable of opening doors or washing windows. We can give robots the parts needed for voices, ears and even eyes. But it is software -- intelligent control programs - that will determine what these pieces can do and how useful home robots will be."

John Blankenship

I posted a video of his last robot in this thread,

If however you have suitable workshop,  building the mechanics from scratch can also have its inventive aspect as you have done with your Lewis and Clark post.

As far as my previous project goes, I logged it on the Forum as Lewis & Clark.

I had forgotten about your other base, I tend to forget who did what, which you first posted about with regards to a suitable bumper.
https://forum.dronebotworkshop.com/user-robot-projects/lewis-and-clark-project/
https://forum.dronebotworkshop.com/user-robot-projects/mechanical-bumpers-for-robot-base/

(@thrandell)
Brain Donor
Joined: 3 years ago
Posts: 231
Topic starter

To err is human.
To really foul up, use a computer.

(@will)
Member
Joined: 3 years ago
Posts: 2552

Very interesting, I've not done anything with robots but I like the way you set up for corners and execute them.

However, I don't really understand why you can't allow theta to be zero, since I don't understand how sin(theta) being zero interferes with the calculation of newY ?

Anything seems possible when you don't know what you're talking about.

(@thrandell)
Brain Donor
Joined: 3 years ago
Posts: 231
Topic starter

Wow, you read it, I’m impressed.   I did a lot of desk checking of the calculations so hopeful I got this right.  I appreciate you calling me out on it, a second set of eyes is always a good thing.

So, if we take an example x and y coordinate grid with the robot at point (30,0) and facing ’right’ in the direction of the positive x coordinate arrow (theta = 0 radians) and we have the vehicle move forward in a counter clockwise arc.  We could assume the the vehicle’s left wheel traveled 20mm and the right wheel 30mm and the distance between the wheels (baseline) is 225mm.  Using the calculations:

dCenter = (20 + 30) / 2 = 25

phi = (30 - 20) / 225 = 0.044

newTheta = 0 + 0.044 = 0.044

newX = 30 + (25 * cos(0)) = 30 + (25 * 1) = 55

newY = 0 + (25 * sin(0)) = 0 + (25 * 0) = 0

Does that make sense?  I know this example has a phi of only a few degrees, but a longer path would give the same results for newY.  Am I blowing smoke?

Tom

To err is human.
To really foul up, use a computer.

(@will)
Member
Joined: 3 years ago
Posts: 2552

OK, please be patient while I try to wrap my head around this.

It seems that you're using phi to approximate the change in angle from the old theta and that you're assuming that it's so small that it is well approximated by its sine (the diff/baseline).

But I would have expected the increments of the new x and y to be calculated using phi instead of theta. The formulae suggest that we're taking the old x and y (based on the past motion of the vehicle) and adding on the new bits resulting from the new movement in direction phi.

In your example, you turn a different amount in both wheels, which suggests that there should be some change in both x and y, but y is unaffected. If you repeated that uneven wheel rotation, wouldn't you expect the vehicle to move in a small circle (and not just spin in place).

Apparently, I'm still missing something (probably obvious, as usual 🙂

Anything seems possible when you don't know what you're talking about.

(@will)
Member
Joined: 3 years ago
Posts: 2552

OK, I think it's sinking in part-way. I've finally deduce that x and Y are the current location based on some arbitrarily chosen origin and theta is the direction it's facing (I assume that it's normal to the axle).

Still working my way through the rest of it.

Anything seems possible when you don't know what you're talking about.

(@robotbuilder)
Member
Joined: 5 years ago
Posts: 2045

Thank you for sharing.

Would be interested to see an actual photo of the new robot?

Unlike Will, untangling source code is not something I am good at,  particularly if I don't have a clear high level understanding of what is being coded.

I took a simpler step by step approach. To move from x1,y1 to x2,y2 first compute the angle and then rotate the robot base to that angle. Compute the distance to travel in a straight line to get to that new position x2,y2 and then move that distance. A curved path can be broken down into a series of straight lines and directions. I measured the amount of change in direction (angle) and the amount of distance travelled in ticks rather than degrees and centimetres.

So to do a square,

```void loop()
{
waitForButtonPress();
forward(2000);     // move 2000 encoder steps and stop
rotateRight(200);  // rotate 90 degrees right
forward(2000);     // move 2000 encoder steps and stop
rotateRight(200);  // rotate 90 degrees right
forward(2000);     // move 2000 encoder steps and stop
rotateRight(200);  // rotate 90 degrees right
forward(2000);     // move 2000 encoder steps and stop
rotateRight(200);  // rotate 90 degrees right
}

```

As interesting as odometry is I do not see it as robust enough for robot navigation in the real world. Rather I see encoders mainly useful for motor control feedback.

(@robotbuilder)
Member
Joined: 5 years ago
Posts: 2045

Ok. Well I do understand the math to some extent although I haven't implemented it myself.

I found this an interesting example of using odometry with some videos to show it in action,

Page 1 / 5