Hide and Seek Robots - Request for Comments

@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.

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!

@thrandell

Not sure what response you are looking for?

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

Do you have any robot design in mind? You will need to start with at least two robots.

@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

@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.

@robotbuilder

Thanks for sharing your ideas.

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.

@thrandell

Thanks for sharing your ideas.

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,

https://forum.dronebotworkshop.com/show-tell/my-new-robot-test-base/

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 

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 ?

@will

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

@thrandell 

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 🙂

@thrandell 

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.

@thrandell 

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.

@will 

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,

https://www.instructables.com/How-to-build-a-self-navigating-Robot/