Hide and Seek Robots - Request for Comments

@thrandell 

Thanks !

Well, I think that I’ve finally finished version 2 of the Hider robot in my Hide and Seek project.  I had to change the wheels out for larger ones. https://banebots.com/wheels/t81-wheels-hubs/   I also tried a different way to mount the Piezo buzzer.  I installed phototransistors, IR proximity sensors and a microphone up front.  I was excited to find that I can use the differential proximity sensors to home in on another IR emitter that is pulsing its signal.  This thing may just work after all!  

Using the data from the microphone has been a challenge, time will tell if these robots will be able to ‘hear’ each other.  One thing that was pretty straight forward was using the mic as a snap switch.  Now when I turn on the Hider it waits for a loud vibration, like a finger snap, before it starts its hide behavior.  That was kinda fun.

@thrandell 

I'm curious, why would you need bigger wheels ?

@thrandell 

Thanks for sharing.  I guess you need two robots to demo this hide and seek behavior?

Hi @will

In my experience with running robots indoors using differencial drive motors both an omni-wheel and the small round caster balls don't work so well over carpet.  So for this one I used a 1 inch  caster ball and some 90mm wheels I had in the junk box.  Unfortunately with that arrangement the front end was lower then the back, so It would try to drive over the edge of a rug, for example, and hit the bumper triggering the escape collision behavior.  With the larger wheels all is good.

Tom

@thrandell 

I understand now, thanks. That means it should work better on gravel outdoors too.

Hi @robotbuilder

Yep, I'll need at least two.  I'm thinking that I'll de-commision the Lewis & Clark robot and build the Seeker from its parts.  The 3D printed chassis was an interesting experiment, but I prefer using the HDPE material.

Tom

@thrandell

Thanks for sharing I think you have done a great job!

In my experience with running robots indoors using differential drive motors both an omni-wheel and the small round caster balls don't work so well over carpet.

Is the swivel at the front (normal direction of travel) or the back. I had mine at the back on the big robot base because if at the front when it hit a ridge the swivel wheels would turn sideways to the direction of travel and jam against the ridge. Whereas the powered wheels at the front would pull themselves over the ridge providing it was no higher than the radius of the wheels.

I notice that the commercial robot vacuum cleaners do have the swivel wheel at the front and they seem to work ok.  They use a barrel shaped wheel.  In one model I used a swivel wheel (see inset within image below) that after turning 90 degrees on carpet it would also jam momentarily on the carpet and the cause the light weight robot base to jump and rotate a bit messing up my dead reckoning navigation. 

This project piqued my interest in robot communication, so my next project will be along the lines of robot communication and coordination. Is anyone working in those areas?

Maybe use the nrf24l01

https://forum.dronebotworkshop.com/introductions/hello-everybody-rclawn-arduino-robot-car-with-nrf24l01/paged/4/

Thanks @robotbuilder for the virtual pat on the back 🙂

Radio is certainly an option as are ultrasonic and infrared  technologies.  I’m still thinking about requirements but it would be nice to incorporate localization with communication.  Some way to find distance and angle information between robots without using some external device, like a stationary beacon.  I’ve got a lot of research to do before I can get started.  I do want to try a switch from wheels to a track system and maybe use Wi-Fi to gather robot debugging information…

Tom

@thrandell 

Where I identify with your approach is you are building from the ground up using your own creative ideas on how to implement solutions rather than just building a kit without understanding.

One thought to measure distance between two bots is: One bot can send a sound pulse and the other can respond with its own sound pulse. The time it takes the sender to receive the pulse would be a measure of the distance between the two bots.

Navigation is with reference to some external frame so I don't see how you can avoid it.

A classic test is illustrated below to show the difference between a dumb animal that only know the direction of the goal relative to itself, red path, and a smart animal that navigates by an external frame of reference taking the green path which involves initially moving away from the goal.

@robotbuilder

I uploaded a video of a short game of Hide and Seek.  I got lucky with this one because the Seeker didn't wander off into another room.  It also shows how directional the sensors are.

Tom 

@thrandell 

Impressive little robots!   Not sure why all the manoeuvring by the seeker robot before touching the hiding robot?

@robotbuilder

Yeah, each time I run these two robots the Seeker finds a different path to take.  

The seeker makes a random angle turn for 95% of any obstacles found, so sometimes it just criss-crosses at almost the same angle.  On this video it also does a slow spin but since the hider has its sensors facing away from the seeker the seeker doesn't pick up the beacon.  It evenually lines up at a right angle to the sensors and that seems to be enough to trigger a bump.

Tom

@robotbuilder

I forgot to mention.  I couldn't get the the microphones to discern a tone from background noise consistently so I only use them to start the game.  The Seeker will try to find and count pulses from the beacon after a collision.  If the count is over a theshold then it considers the hider found...

Tom