I'm implementing a motor controller on Arduino connected to ROS stack via rosserial_arduino.
The motors have a Hall sensor-based wheel encoders with a relatively high resolution (~3000 ticks per turn of the wheel). So I'm measuring the speed of the wheel using interrupts (one of the 2 outputs of a hall sensor is connected to interrupt pin).
When I run the program and connect it to ROS with rosserial.py everything runs smoothly (I'm getting ROS messages from Arduino) till the interrupt is triggered for the first time (i.e. the wheel starts turning). At this point it seems like Arduino program is restarted (crashes?) and rosserial loses connection to it (I get "lost sync with device")
I troubleshooted the problem a little bit and have minimized the code to just this:
ros::NodeHandle nh;
void motorInterruptLeft() { // literary just an empty function }
void setup() { attachInterrupt(1, motorInterruptLeft, CHANGE); nh.initNode(); }
void loop() { nh.spinOnce();
long curTime = millis(); static long lastTrigger = 0; if (curTime - lastTrigger > 100) { lastTrigger = curTime; // logger.publish(...); // doing some publishing every 100ms } }
I still get the same "Lost sync with device" problem. Anyone has ideas about how to use ROS on Arduino while still being able to handle interrupts?
Originally posted by gorsman on ROS Answers with karma: 16 on 2013-07-15
Post score: 0
Original comments
Comment by HenryW on 2013-07-16:
Hey,
I do exactly as you have described with my robot to get wheel speeds. Have not encountered this issue myself however. What version of ROS are you using?
I will look at my code and see if I spot anything overly different
Comment by HenryW on 2013-07-16:
OK, one difference I can see.
Do you really want to set an interrupt on change? Rising would make more sense as you only want a interrupt when the hall effect goes high, not both rising and falling edges.
Other than that, can't see any problems sorry.
Comment by gorsman on 2013-07-17:
Triggering on both rising and falling effectively makes the resolution of measuring wheel encoder ticks twice as high (as on both of these 2 events I can figure out the direction of a wheel turn by XORing the measurements from the hall sensor pins).