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.

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.

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.

imo the simplest and lowest cost solution would be a wire "skirt" around the perimeter of each robot. contact would be easy to detect and also function as the communication link. ive successfully used this to detect and transfer info from a robot to its docking/charging station but should be no problem between robots.

ir would be next best were it not for your concern about sunlight which is DEFINITELY a problem. kilobot swarm projects use this but only under controlled/subdued lighting.

wireless can also work but youd need rssi capabilty for proximity so that leaves out cheapo ook uhf modules. cc2500, a7105, rf24l01, rfm22/12, etc modules would do the job but at a cost and complexity penalty. packet collision detection is a somewhat trivial issue.

Each robot is encircled by a pair of slip rings.When they touch they complete 2 conductive paths.Output A on each robot is connected to the top ring.The bottom ring is connected to common on all robots.Output A is also connected to an RC network that will decay at a predetermined rate, according to the RC constant.Each robot has a unique RC time constant. ie .1, .3, .5, .7,.9.........When two robots make contact, the RC time constant will change to a new value.If .1 and .3 collide, the RC will change to .4 and that can be read by Input B on each robot.A look up table that has the values of all possible combinations of RC times will then be able to determine which 2 or more individuals are colliding.

Each robot is encircled by a pair of slip rings.When they touch they complete 2 conductive paths.Output A on each robot is connected to the top ring.The bottom ring is connected to common on all robots.Output A is also connected to an RC network that will decay at a predetermined rate, according to the RC constant.Each robot has a unique RC time constant. ie .1, .3, .5, .7,.9.........When two robots make contact, the RC time constant will change to a new value.If .1 and .3 collide, the RC will change to .4 and that can be read by Input B on each robot.A look up table that has the values of all possible combinations of RC times will then be able to determine which 2 or more individuals are colliding.

Are you happy this will cope with Robot A colliding with Robots B and C simultaneously - and that each Robot knows it has hit the other two? Yes/No is fine for me!

Please note that my objects floating around in space may not collide in a predictable way. Therefore there will only be one point of contact. And my bot is, well, plushy. I have no assurances of completing a DC-like circuit.

However, I have been thinking about the way that an antenna works. High frequencies radiate into space when there is no ground plane nearby to keep the signals tied to the wire. So what if I set the output power for a transmitter so low as to not radiate far off of a mesh antenna more than a few millimeters? The mesh antenna could be conductive thread. Then I can put the receiver for each bot in continuous listen mode, set the transmitters to quick random bursts, and the receivers will not pickup the transmitted signal until they touch or are nearly touching.

Would that work? What kind of receiver/transmitter or transceiver would work and how adjustable is the transmitter gain?

Regarding RFID tags, can someone point me to a cheap transmitter/reader that I can incorporate into my bot? How about a source for the tags themselves? I am using that for a different function in this bot, to detect nearby bots at a distance of up to 5 feet or so. Thanks.

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.

Synchronisation is a piece of cake. Designate a master to broadcast the time at regular intervals with a deputy which takes over the task if it does not hear its master after 2x periods. There are peer strategies as well but let us not complicate it. Any new robot added after the first two is just a slave, with the same programming as all other slaves and indeed the same as the master & deputy apart from the time role.

After that, whether you use randomised or fixed-interval (tied to ID) broadcasts of time-stamped events, you are assured of exchanging the data without relying on instantaneous (rather than recorded) simultaneity for identification.

I like also the suggestion made for identifying the event and simultaneously passing data contact-electrically, except I am not sure how you are going to make this work in the air unless you have found a way of keeping spheres airborne . It also raises a question of what constitutes an event if there could be sufficient contact or grazing proximity to trigger Event without leaving time or communication quality to exchange necessary data on it. Would this be important?

... So what if I set the output power for a transmitter so low as to not radiate far off of a mesh antenna more than a few millimeters? The mesh antenna could be conductive thread. Then I can put the receiver for each bot in continuous listen mode, set the transmitters to quick random bursts, and the receivers will not pickup the transmitted signal until they touch or are nearly touching.

A receiver can detect a signal at a far greater range than the two can reliably exchange data, even a small burst. Therefore, you would have a significant problem with apparent detected events on which there was no data exchange and thus no actual identification or record of the event. Further, the frequency of pulses and more importantly the gap between them will have a direct effect on whether you detect an event at all.

This problem exists to some extent with any method of course. Using accelerometers as you originally suggested, their event detection threshhold would have to be set "sufficiently" beyond the envelope of g-forces which the robot is capable of generating by its own manoeuvres. It depends a bit what you want to define as an event. The big advantage of accelerometers as I am reading this thread is that they work for flying objects without additional complication.

The collisions should be real collisions and not just glancing blows, for my application anyway. But the moment of impact will probably only be 100 milliseconds? And these objects are oddly shaped, not spheres, which is why the RFID for this application may not work without sprinkling lots of RFID tags throughout the object. Even then, is the range of the RFID transmitters tweakable enough?

I have lots of plausible solutions, but I lack experience to know what really works. Eventually I will need to buy parts and start making mistakes, but I'm trying to get the best design out of the starting gate.

The output power of an RF transmitter can easily be reduced with an attenuator between the output and the antenna.Same with receiver sensitivity. So these could be an option.

Also, if the bots are touching and there surfaces are insulative there is still capacitive coupling at RF frequencies (down into the kHz range). It may be possible to use this method of sending an ID from one Bot to another.

Another method is that all Bots send/receive to a central transceiver. A message may be "I detected a collusion at x time". Then the central processor arbitrates which two Bots detected a collusion at the same time and sends IDs.

Each robot is encircled by a pair of slip rings.When they touch they complete 2 conductive paths.Output A on each robot is connected to the top ring.The bottom ring is connected to common on all robots.Output A is also connected to an RC network that will decay at a predetermined rate, according to the RC constant.Each robot has a unique RC time constant. ie .1, .3, .5, .7,.9.........When two robots make contact, the RC time constant will change to a new value.If .1 and .3 collide, the RC will change to .4 and that can be read by Input B on each robot.A look up table that has the values of all possible combinations of RC times will then be able to determine which 2 or more individuals are colliding.

Are you happy this will cope with Robot A colliding with Robots B and C simultaneously - and that each Robot knows it has hit the other two? Yes/No is fine for me!

If all robots have the same capacitance value for the RC time constant, and If the number combinations above are treated as 2 or 3 resistors in parallel.Any combinations that are determined to calculate to the same resistance value, one or more of the robots in that combination will need a different capacitance value to change the RC time constant to that combination.

Given further information that the collisions will be very brief and somewhat random rather than on a flat plane, this scheme may not work.

...there is still capacitive coupling at RF frequencies (down into the kHz range). It may be possible to use this method of sending an ID from one Bot to another.

Sounds good! What kind of parts could I experiment with to do that? Do I just use some kind of GPIO pin on a microprocessor and toggle it at some kHZ or MHZ frequency? Do I need to amplify it too? What part can I use for that? Just run this signal straight into my "mesh antenna?"

What do I use to listen for the signal on the other side? Another GPIO? I have a feeling that I need something besides a general purpose pin to discriminate these frequencies.

A square wave generator (digital output pin) would work for a transmitter. Use a high enough frequency as the 'carrier, and then Modulate it with the data. This could be the same as use for an IR TV remote. The higher the frequency the small the effective cap value needed to couple.For a receiver you will need a fairly high impedance input to an amp. A JFET op-amp follower with a series resistor should work for a receiver front end. Don't forget to add input protection on the op-amp (diode clamps work) and some DC bias (megOhm to ground). You may then need another gain stage and pulse shaping to insert the data signal into a digital input. Demodulation can be done with an external circuit or in a processor.

Using the sensing medium as the communication medium will fail unless you ensure the sensing threshhold for signal strength is set reliably above the level at which you can exchange structured communication rather than merely sense the existence of a signal. Given the relative ease of tuning physical contact methods compared with nominally remote sensing methods against this criterion, I take it there is some other significant problem with contact methods as yet unstated in this thread.

There follows the problem of exchanging data on simultaneity. Unless there is some separation in the signals by channel or sub-channel then simultaneous data messages (rather than sense messages) will interfere with one another, destroying one or both messages. Distinguishing by channel does not scale well. Further, if either message fails then the opportunity to exchange the message at the correct time is lost with it. The alternative separation is by time, in which case you need to have known what was the time, and if you know what was the time then the messages are substantially freed from timing constraints and can be exchanged reliably.

If data exchange is by a process which relies on message content to establish simultaneity rather than on temporal signal existence, then there is greater freedom to select each of the preferred sensing and data exchange methods to suit each of the respective problem characteristics.

@waltr, I know what a op amp is, and I know what demodulation means, diode clamping, and all of that. I can certainly follow along with the theory, but when it comes to actually building this with real parts, I am lost!

Yes, that will be the difficult part since it is not a common circuit.The second paper uses high speed differential drivers/receivers with capacitive coupling. I recently did this for an isolated 24MHz clock/data interface between two instruments to keep them 'is sync'.This used SN65LVDS179 LVDS chips from TI. This does require two coupled paths.

The scheme I wrote about above uses a single ended path with no solid ground reference. Here the receiver would probably need to be high impedance (JFET). This will require a good amount of experimentation to get working. Look for a high-Z input circuit and get it a try. Also, be sure to read any App Notes you can find about these types of circuits. Here is one example:http://www.ti.com/lit/an/snoa664/snoa664.pdfTI, Analog Device and Linear Tech all have good App Notes on various aspects of op-amps.

How does that work for bots that are in the air and don't have ground return, like the OP describes?

with low freq rf carrier, pretty much as realized in subsequent posts. at those frequencies an actual ground rail is not required. kinda like with some of the capacitive sensing popular with avr crowd. with careful calibration no additional circuits required. for example basic avr io with little more than a few resistors and appropriate software. the "skirt" can be 3d and collison only and not proximity simplifies things.

all this talk of floating around in space leads me to wonder how serious the application. smart quadcopters? robo-ballons? autonomous orbital satellites? is op nasa employee? w/o more info hard to imagine this as more than a daydream.

The application is a toy/sport gadget and that is all I can say about it for now. I found a lot of information recently on NFC and RFID that could work, but I need to figure out if I can unroll the coil in the RFID tags and use that as my grid antenna.

having considerable experience with low freq (125khz) rfid i can say that unrolling the coil does increase range significantly. as long as both ends remain attached. in fact ive been able to boost by an order of magnitude. however 6 foot loops are a bit unwieldy and off the shelf chips like the popular 2270 wont work due to your unique requirements.

imo the capcitive loading approach is best. it could be as simple as a resistor between 2 io pins. bring one low and immediately check the other to see if it follows. by fine tuning resistance and/or delay ive been able to detect objects as small as 1" piece of wire.

Capacitive sense is an interesting idea. I thought that it could only detect humans? I am going to experiment with that idea and see if I can detect the difference between my other bots versus other objects. I really just need to know that I hit another bot, then I can use the timestamps to see which one I hit. But I still wonder if other inert objects might "look" like my bot.

Each bot is covered in wire (cage, fur, mesh, etc) that carries a signal, which is at first approximation a square wave at some particular frequency. This uses capacitive coupling both for signal generation, and for signal sensing.

Each bot has its own particular frequency, where the difference in frequency between any two bots is at least 1 kHz to allow for short contacts (a few milliseconds) to be discriminated. This means carrier frequency must be in hundreds-of-kilohertz up to megahertz range -- approximately the radio AM band range of frequencies.

Each bot analyzes the signal it actually sees on the contact shroud for beating frequencies, which are generated when some other frequency is present in addition to the specific bot's emitted frequency.

This will tell you if there is a contact, and what the ID of that other bot is.

Right before the men in black from the FCC breaks down your door for operating an unlicensed radio transmitter :-)

Capacitive sense is an interesting idea. I thought that it could only detect humans?

...

I still wonder if other inert objects might "look" like my bot.

actually metal objects work better than humans. its the water in people that conducts but metal does that a lot better. if tuned sensitive enough it can trigger up to an inch or two away but for my "tuna-bot" (chicken-of-the-sea frame) actual contact was required at the charging station. once this occured bi-directional communication was a cinch. very reliable even if electrodes corroded and noisy due to the nature of the capacitive link.

of course each bot needs unique id stored in ee so we can tell who is who.