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

     I finally finished up the Seeker robot.  I can’t believe that this project took 6 months, yikes.  The seeker uses 4 IR proximity sensors: two in the front for wall following and two on the sides for obstacle avoidance.  And yes that’s heat shrink tubing shrouding the sensors and black electricians tape on the bumper.  

     I set up the Hider to toggle its side IR proximity sensors at a rate of 500usec while it waits to get bumped.  This worked out pretty well and I can get a range of about 4 feet.  I went back and forth on the best way to follow the beacon.    I first tried a new behavior in the Seeker that used its side sensors to steer the motors towards a signal that was toggling at the same rate.  It worked ok, but it would sometimes lose sight and wander off track.  So next I tried a behavior that would randomly kick off and do a 360 spin and if it caught sight of the beacon it would use the two side sensors to drive the motors until it bumped the Hider.  I finally decide on the first option.  It was simpler and I put the 360 spin in another behavior.

     A new thing for me was combining behaviors.  For example, I have a behavior that will spin the robot to a random angle when there is an obstacle in the way.  I combined this one with a wall following behavior. The idea is that the Seeker robot will be able to randomly search a room and occasionally follow a wall into an adjacent room.  I also combined an escape collision behavior with one that ‘listens’ for a tone right after a collision.  So a typical scenario might go like this: run into something, back up a few inches, try to detect a sound from the hider and if nothing is ‘heard’ complete the escape sequence.  And none of that can take very long to execute.  What joy! 

     I pulled together some random functions in the Seeker code that someone might find useful.  With the Random_Walk behavior the robot spins at random angles to avoid collisions by using the random_uniform(-180,180) function.  To get the robot to follow a wall with a probability of 5% I used the variable  follow_wall = random_select(0.05) to start wall following.  The final version of Random_Walk has three behaviors: random walk, follow wall and spin.  To control how often each of those get executed I used index = random_weighted_choice(0.75, 0.15, 0.10).  That’s 75% walk, 15% spin, 10% follow wall.

float random_random() {  // this might need to be a double
// returns a float where 0.0 <= x < 1.0
  return (float)rand() / (float)RAND_MAX;
}


float random_uniform(float a, float b) { // this could check that a < b first)
// returns a float where a <= x < b
  return a + (b - a) * random_random();
}


boolean random_select(float p) {  // this could check that 0 < p <= 1 first
// returns true if random number with probability p is generated.
  float generated = (float)rand() / (float)(unsigned)(RAND_MAX+1); 
  if (generated - (1.0 - p) < 0.0)
    return false;
  else
    return true;  
}


unsigned char random_weighted_choice(float p, float q, float r) {
// returns parameter index if random number with probability p, q or r is generated.
  float generated = (float)rand() / (float)(unsigned)(RAND_MAX+1); 
  if ((generated - p) <= 0)
    return 0;
  else if (((generated - p) - q) <= 0) 
    return 1;
  else return 2;
}


int16_t random_binary(int16_t a, int16_t b) {
// returns a or b
  if (rand() % 2 == 0)
    return a;
  else
    return b;
}

     So that’s it.  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?

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