Electronics > Electronics

Contact sensor with identification exchange?

(1/6) > >>

Let's say that I have ten little robots roaming around.  They are all exactly the same except their ID's which are unique.  When any bot bumps into any other bot, I want the two bots to exchange ID information with each other during the bump event.  Can anyone think of a way to do that?

My first idea was to use accelerometers and wireless communication to detect the bump, then check to see if any other bot also detected a bump at that exact moment in time.  I fear that it could be defeated if they both bumped a wall at the same exact time?  But maybe the granularity of the bump broadcast event is fast enough that precise simultaneous bumps into non-bot objects are like a 1/10000 event?  That would probably be OK.  If so, should I use zigbee or something else?

What else would work?  Some kind of near field communication?  Capacitive sense?  I can't complete a normal circuit because the bots might be in the midair.  So I can't rely on any return path connection to be there.  I can probably use a conducting material cover if necessary.

Thanks, David.

How about an omnidirectional IR LEDs the flash the ID when a bump is detected.
And also directional detector that turns to the direction of the detected bump or an omnidirectional detector to receive the ID code.

The possible issue with RF is collision of the two RF sources (transmissions) and overloading the RF receivers at such close range.

Hmmm... I hadn't considered IR.  I would still have collisions of IR sources though, right?  I wonder if it would work in sunlight? 

My 2013 Honda Accord has a "Smart Entry" system that activates as soon as my hand touches the handle.  I assume that the handle uses a capacitive sensor, and then a secondary system activates that looks for the key to be within a few feet of the door.  What kind of tech are they using for that proximity key?

I am taking the accelerometer approach as being viable for bump detection, although capacitive or other methods are equally useable, given that my proposal is to separate bump detection from the robot identification and communication processes. Currently, you are using coincidence of the event and communication processes in combination to determine the identification. As already noted, this may lead to interfering broadcasts.

One method is to include real time clocks on each robot. They may have them already. Then when a bump event (however detected) occurs the robot stores the event with a time stamp. Broadcasting this information now allows other robots to ask themselves (as it were) does it have a bump event with the same time stamp? If so, it replies and the robot pair is identified and both know of it. You are not relying on time-contiguity of broadcast to determine coincidence of events, because it is in the data exchanged instead.

The third phase is an information exchange process to avoid interference. Given that each robot has a time-stamped event recorded (or at least one does, if it hit a wall) then broadcasting can be more "leisurely" in the millisecond range. Two possible methods for avoiding simultaneous broadcasts would be to pass a token around the set of robots or to broadcast on randomised delay. Taking the first method, the token ring is established by robot 1 broadcasting "2" to the field. Robot 2 then broadcasts "3" etc and eventually back to 1. Thus there is only ever one robot free to broadcast but the turns circulate at great speed. If there is a bump event (or any other data you wish to send) then it is included in the broadcast and when the pertinent robot (checking its timestamp) gets its turn then it conveys this data in its own broadcast, but the "you may broadcast" token continues to circulate in a fixed pattern.

The random delay method is probably better for the case you describe. After a bump event and time stamp is recorded by each robot then each such robot generates a random (small) delay with negligible probability of coincidence (up to you on the acceptable maximum delay) then one robot will broadcast before the other.  When the second broadcast occurs, both robots will know of a match. Alternatively, the later-braodcasting robot could kill its intended broadcast once it hears from the other robot and send back a specific message confirming the match.

If a robot has a single event (hits a wall) then of course there will be no confirmatory reply, in either the token or random scheme, and the recorded event is discarded after it becomes stale, a period defined by the token returning or else by the maximum random delay in broadcast.

So, I have proposed splitting the problem into steps of event, recording event data, transmitting event data non-simultaneously, and confirmation of event matches. The enabler for this approach is a synchronised real time clock on each robot. If you really want precision, add some form of knowledge of location to each robot. Having three factors (bump, time, location) will make the chance of mis-identification negligible, in case it is not already.

I hope this helps with ideas with which to play around.

Thanks for the input.  That certainly is in the realm of what I am contemplating, but I can't help thinking that there must be a simpler way.   The RTC method requires synchronization and if I add bots at any time, I have to figure out how to synchronize them and adjust the algorithm of existing bots.

I keep thinking that there must be some electromagnetic way to do this.  If I had a ground return path, I could simply send out a digital square wave burst on random periodic intervals.  I would then listen for that digital signal on a continuous cadence, ignoring my own burst transmission when I find it.  The square wave would just be a header that identifies a ID packet, followed by a binary ID. 

If there was some way that I could transmit electrical signals between two objects that make a single point of electrical contact, it would be easy to design a communication protocol between them.  The advantage is that I would know for certain that the two objects were in physical contact.


[0] Message Index

[#] Next page

Go to full version