Servo Twitch with IRremote Library

Hello,

I’ve been knocking my head against the wall for a few days trying to get my Arduino Uno to receive IR signals from a 2nd gen Apple remote, and then control a standard Futaba servo with the received codes. It is a BoeBot application, so I am using the Board of Education shield with an IR receiver from Parallax running to pin 4 and the servo to pin 12. The problem I am having is that whenever I load Ken Shirriff’s IRremote.h library and the Servo.h library, I encounter a servo twitch.

Here’s a simple instance of the code that is giving me the issue:

#include <IRremote.h>
#include <Servo.h>
 
int RECV_PIN = 4;
 
IRrecv irrecv(RECV_PIN);
 
decode_results results;
 
Servo myservo;
int pos = 90;
 
void setup()
{
  Serial.begin(9600);
  irrecv.enableIRIn(); // Start the receiver
  myservo.attach(12);
  myservo.write(pos);
}
 
void loop() {
  if (irrecv.decode(&results)) {
    Serial.println(results.value, HEX);
    irrecv.resume(); // Receive the next value
  }
}

It is powered by a 6V supply (4, 1.5V alkalines), and there is a common ground between the servo and the board.

Here are some things I’ve tried:

  1. Using a different servo

  2. Using different pins, for both the servo and IR receiver

  3. Change the IRreceive.h library to interrupt with timer0, instead of timer2. (My thinking here is that there may have been a priority of operation, and I wanted to give the servo priority over the IR pin. This didn’t change anything though, and I’m pretty sure timer0 has higher priority anyhow…)

  4. Wrap the IRremote.h timer ISR in a “detach.servo();” and “attach.servo();” command somehow, but I can’t seem to get the coding correct, and I’m not sure if this approach would work.

I should mention that the IR receive demo sketch and a basic servo sweep sketch work just fine when they’re independent of one another.

I’ve seen some postings online where people have gotten the same code to work on the same type of application, so I feel like I’m really missing something big here. I’ve copied their approach exactly, but am still stuck with a twitchy servo. Any help would be great…I really do appreciate the support.

Ken Shirriff’s IRremote library:

I am experiencing the exact same issue!

I am using an Arduino Uno, and have specified in IRremoteInt.h for IRremote to use Timer 2 (the timer that controls PWM on pins 3 and 11, which I am not using) . My servos are on pins 9 and 10 and are being controlled with the stock Arduino Servo library (which uses Timer 1). When the servos are sitting idle, they jitter; this jitter does not occur if I comment out the “irrecv.enableIRIn();” expression.

Interestingly, the Wire library also causes a small amount of jitter, though not as much as the IRremote library.

Attached is a picture of my project in Fritzing, and my project code.

Any help on removing this jitter (without changing the hardware) would be appreciated!

cat_laser.ino (10.8 KB)

Ive had this issue as well but with only the servo library.

I THINK I've fixed it by detatching the servos while not in use.

for example:

while( //doing something){
servoX.attach(9);
//do rest of what ever it is im doing.
}
servoX.detach();

or:

if (//some command recieved){
servoX.attach(9);
// execute command
servoX.detatch(); //when that command is done
}

I only tested this for a few minutes and they werent twitching. My robot tends to sit idle all night in our bedroom so I was hoping this solved it. let me know how how it works for you.

Detaching the Servos eliminated the jitter for me - nice workaround. So as mentioned above attach the servos when needed and then do a servo detach when done.

BTW: I commented out various portions of the IRremote ISR to determine the cause of the conflict with the Servo library, and as best as I can tell it’s just execution time of the IRremote ISR that’s delaying the Servo Timer code execution. It looks like the Mega2560 disables other interrupts while currently servicing an interrupt. I suppose you could re- enable interrupts in the IRremote ISR don’t know for sure. Using dual edge triggered interrupts on the IR receive pin and having a free running timer would be less resource intensive (I think someone mentioned that above).