IR communication for swarm bots

Hello everybody!

I'm new to the forum, but I've already found a lot of useful information.
For my school I'm working on a project of "swarm bots", that should be a group of little robots able to move in the environment and communicate with each other.
We are solving the motion part without big problems, but the communication is giving us problems.
What we were thinking of doing was to create a system of IR communication, and use the directionality of the communication itself to detect the position of the sending robot relative to the reviving one.
To do that, each robot should have an IR sender and at least three IR receivers, something like this: File:IR shield PCB mounted front.JPG - XinCheJian
We are using the library of Ken Shiriff, but we realized that is not possible to have more than one receiver working at the same time. We tryied to use switches to turn on and of the different receivers, but it doesn't seem to work.
Does anybody has any suggestion or idea on how to solve this?
thank you!!!

Maybe you'll find PinChangeInt library suitable for your case.

I've used it in a similar situation, the syntax differs just a little from using native interrupts:

#include <PinChangeInt.h>
#include <IRremote.h> 
#define RECV_PIN5 5
#define RECV_PIN6 6

int receivePins[] = {RECV_PIN5, RECV_PIN6};
IRrecv IRreceivers[] = {IRrecv(receivePins[0]), IRrecv(receivePins[1])}; 
int receivePinsCount = sizeof(receivePins)/sizeof(receivePins[0]);

decode_results results; 

unsigned long volatile IRBuffer, IRStartTime = 0, IREndTime = 0;
long volatile IRCodes[2];

void setup() 
{ 
  Serial.begin(9600);
  for (int i=0;i<receivePinsCount;i++)
  {
    IRreceivers[i].enableIRIn();
    PCintPort::attachInterrupt(receivePins[i], getIRCode, FALLING); 
  } 
} 
  
void loop() 
{ 
  for (int i=0;i<receivePinsCount;i++)
  {
    if(IRCodes[i]>0) {
      Serial.print(receivePins[i]);
      Serial.print('=');
      Serial.println(IRCodes[i]);
      IRCodes[i] = 0;
    }
  } 
}

int getPinIndex(int receivePin)
{
  for (int i=0;i<receivePinsCount;i++)
  {
    if(receivePins[i] == receivePin) {
      return i;
    }
  }
  return 0;
}

void getIRCode()
{
  PCintPort::detachInterrupt(PCintPort::arduinoPin);
  int pinIndex = getPinIndex(PCintPort::arduinoPin);
  if (IRreceivers[pinIndex].decode(&results))  
  { 
    if (results.value > 0 && results.value < 0xFFFFFFFF) 
    { 
      IRBuffer = results.value; 
      IREndTime=millis();
      if (IREndTime-IRStartTime>1000)
      {
        IRCodes[pinIndex] = IRBuffer;
        IRStartTime=IREndTime;
      }
      else
      {
        IRCodes[pinIndex] = 0;
      }
    } 
    IRreceivers[pinIndex].resume(); 
  } 
  PCintPort::attachInterrupt(PCintPort::arduinoPin, getIRCode, CHANGE); 
}

This code worked fine. Read pinchangeint documentation carefully: some optimization is strongly recommended (disabling unused ports, etc).
But beware: I'm just a newbie, I believe the code is far from ideal :wink:

Thank you!!! For sure I'm more newbie than you! XD
The code works fine, now I need to manage a bit the code flow to keep everything working, since the interrupts are kind of messing up the code.
Just one question: it seems that somehow when I use this code, I have less current available on output pins. I'm tryngo to blink an LED according to the status of the receiver, but their blink is really low.
Do you have any idea of why is this happening?

I'm tryngo to blink an LED according to the status of the receiver, but their blink is really low.
Do you have any idea of why is this happening?

What does "blink is really low" mean? Slow or dim?

The usual problem of dim LEDs is trying to toggle an INPUT pin, pretending it is an OUTPUT pin. Have you set the pinMode() correctly?

By the way, I've missed that in the later version i made the "results" an array too. Don't know if it is much useful - I hardly can imagine that 2 interrupt handlers run simultaneously - but as for me it's a bit more clear when every pin has its own "results" var.
Speaking about interrupts, I believe it's more efficient to use them rather then checking in loop (as in IRremote's demo), because we work with events here, so no need to disturb the processor while events not happening.

What status is it? If you mean "slow", and if you try to blink every time getIRcode is executed, maybe, just maybe, the board doesn't always manage to blink the LED - the interrupt handler must always work very quick. You can change some variable in the handler, then check it in the main loop and turn the LED on, respectively.

Well, programming is my job (although not C language), but electronic - aah, it's terra incognita.
By the way, what Arduino do you use? I'm trying to understand if the 3.3V/8MHz board is suitable to send and receive IR codes. I've asked about it in "Project guidance", but got no answer. Maybe nobody has tried, or maybe my english is a bit poor :slight_smile:
Generally, for what purposes the 8MHz duino is not quick enough?

Actually i am an architect, so I'm quite out of place both on the programming and on the elctronics side... XD
I wanted to ask you just one other thing. I cannot really understand how the interrupts really work. Mainly, I will need to drive motors according to the IR signla received, in order to control the movement of each robot in relation to the other robots position. What I cannot understand is if the interrupt stops the code and then starts from the point that it reached, or if it starts again. Also, I wanted to ask you if there is a way to control the interrupt with conditionals, let's say, check the IR reveiver just one time each 2 seconds...
Regarding the Arduino, I'm using an Arduino Duemilanove and an Arduino Uno, so I do not really know what are the performance of the 8Mhz board. What would you use it for?
Thank you again for the help!

What I cannot understand is if the interrupt stops the code and then starts from the point that it reached, or if it starts again.

You get out of bed in the morning. It's not a work day, so you have some breakfast, run some errands, and sit down to read a book.

The phone rings. (That's an interrupt.) You answer (that's an interrupt handler) it. When you hang up (the interrupt handler ends, do you go back to bed and start the day over, or do you resume reading your book?

(The Arduino resumes reading it's book).

...clear enough!!! :smiley:
Thank you!