Hi! I have big problem using a different IR controller with my Zumo 32U4 robot. Anyone know how to change codes to a controller that’s not from Pololu?
Best Regards / Jimmy
Hello, Jimmy.
It sounds like you are trying to get the RemoteControl example in the Arduino library for the Zumo 32U4 robot to work with your IR controller and need to modify the remote constants, which are defined for our Mini IR Remote Control. The file you are looking for is RemoteConstants.h. Please note that if your IR remote does not use the NEC protocol with a 38kHz modulated IR signal, then it will not work with our RemoteControl example without further modifications.
- Amanda
Hi Amanda, I had an old IR remote with NEC protocol. I tried the Zumo32u4 remote control. Initially, I got a message on the LCD screen saying “bad addr”. After playing around and changing “remoteAddressByte1” in RemoteConstants.h from 0xBF to 0xFF, the message disappeared. Eventually, I was able to use the remote to control Zumo.
After that, I ordered a 38HZ mini IR control from Robotshop.ca (I am in Canada) ( https://www.robotshop.com/ca/en/infrared-remote-control-20-keys.html). When I run the tutorial from Adafruit (https://learn.adafruit.com/using-an-infrared-library/hardware-needed), it shows NEC protocol. However, when I tried the Zumo32u4 remote control example, the red light flashed but the message showed “waiting”.
My understanding is that any 38HZ remote controls with NEC protocol should work and the LCD screen should at least show something. Any suggestions? Thanks!
Hello, Cookie.
I was able to reproduce the behavior you described using our remote. It sounds like the Zumo 32U4’s IR receivers might not be getting a good signal reading from your remote. Can you try positioning your remote closer to the sensors by aiming it at the front of the Zumo 32U4 blade and see if that changes anything?
- Amanda
Yes, I even lift my zumo and point my remote directly at the three IR proximity sensors. The message remains the same. I noticed that your remote has 21 keys (Adafruit) while mine has only 20 keys (robot shop), although my spec matchs NEC and 38kHZ. As I mentioned earlier, an old worked remote has only 12 keys.
When I used the Adafruit example to decode the buttons, showed different prefix, for example, the one worked shows FF30CF while the one doesn’t work shows FD30CF. This is also the reason I changed the Adress1 in the code from 0xBF to 0xFF to make the first remote work.
Do you have any suggestion?
Can you enable the debug output in the RemoteControl example, press a few buttons on the non-working remote, and post the results from the Arduino IDE’s Serial Monitor here? To enable debug mode, uncomment this line in RemoteDecoder.h. Can you also post the output for the Adafruit example?
- Amanda
I was able to run it with the 20-key remote with the code below by plugging a Keyes IR receiver into pin 2 after removing the front sensor array. By the way, I was using ZumoMotors library instead of Zumo32u4 library. So, I guess your proximity sensor was expecting some address, according to NEC protocol.
#include "IRremote.h"
#include <ZumoMotors.h>
#define button_forward 0xFDA05F
#define button_backward 0xFDB04F
#define button_left 0xFD10EF
#define button_right 0xFD50AF
#define button_stop 0xFD906F
int receiver = 2;
ZumoMotors motors;
IRrecv irrecv(receiver);
decode_results results;
void setup()
{
Serial.begin(9600);
irrecv.enableIRIn();
}
void loop()
{
if (irrecv.decode(&results))
{
Serial.println(results.value, HEX);
translateIR();
irrecv.resume(); // receive the next value
}
}
void translateIR() // takes action based on IR code
{
switch(results.value)
{
case button_forward:
motors.setSpeeds(400, 400);
delay(100);
break;
case button_backward:
motors.setSpeeds(-400, -400);
delay(100);
break;
case button_right:
motors.setSpeeds(250, -250);
delay(100);
break;
case button_left:
motors.setSpeeds(-250, 250);
delay(100);
break;
case button_stop:
motors.setSpeeds(0, 0);
delay(100);
break;
default:
Serial.println(" other button ");
}
delay(500);
}
Thanks for posting those screenshots. It looks like the timing of your new remote is off from what our program expects. It is possible that the RemoteControl program is being too strict in its timing requirements. I attached a modified version of RemoteDecoder.h which allows some additional margin in the timing. Can you try replacing the file in your sketch folder with this one and see if it works? Please let us know the results.
RemoteDecoder.h (12.7 KB)
- Amanda
Hi Amanda. It worked. I would never thought timing was the problem. Even I know, I would never be able to modify the code. The address is also a problem. If I want to use the white remote control, I still need to change fro 0xBF to 0xFF. Thanks so much for your helps. Have a great day.
1 Like
Great; I’m glad the modified code worked for you!
Having to change the address is expected (different remotes models will have different addresses). The “bad addr” error message just means the program was able to decode the address but has not been told to respond to that address.
- Amanda