Quantcast
Channel: ROS Answers: Open Source Q&A Forum - RSS feed
Viewing all articles
Browse latest Browse all 99

"wrong checksum for id and message" when using interrupts to read ultrasonic sensors.

$
0
0
I am using interrupts to read from ultrasonic sensors on a Teensy 3.5 board. When I publish data I get a stream of "wrong checksum for topic id and message" warnings. I will also occasionally get errors: Mismatched protocol version in packet: lost sync or rosserial_python is from different ros release than the rosserial client When I increase the delay in my loop the amount of the first error decreases and the second one generally does not occur but the node will eventually crash in any case, displaying: Traceback (most recent call last): File "/my/home/catkin_ws/src/rosserial/rosserial_python/nodes/serial_node.py", line 85, in client.run() File "/my/home/catkin_ws/src/rosserial/rosserial_python/src/rosserial_python/SerialClient.py", line 493, in run self.callbacks[topic_id](msg) File "/my/home/catkin_ws/src/rosserial/rosserial_python/src/rosserial_python/SerialClient.py", line 107, in handlePacket m.deserialize(data) File "/opt/ros/kinetic/lib/python2.7/dist-packages/nav_msgs/msg/_Odometry.py", line 225, in deserialize raise genpy.DeserializationError(e) #most likely buffer underfill genpy.message.DeserializationError: unpack requires a string argument of length 4 When I disable the trigger pulse to the ultrasonic sensors or when I detach the interrupts that read the pulse back from the sensors the issues go away. When I comment out all ros publishes the problems (logically) don't happen as well. I have some pretty large publishes such as Odometry and if I comment just that one out the issues decrease drastically but are still present. Here is the really weird part, if each of the ultrasonic sensors detects a distance of less than a meter there are no issues with 5 ms of delay in the loop function, if there is more than a meter of clear space it takes 50 ms of delay to make the issues go away which is too slow for how often the wheel velocity commands are updating. I'm pretty sure it has something to do with the interrupts for reading the distance activating during publishing but I have no idea why or how to fix it. The interrupt function looks like this: void ISR_USreadB2() { Threads::Scope m(mylock); if (digitalRead(PIN_ECHO_B2)) { B2PulseStart = micros(); } else { d_b2 = (micros() - B2PulseStart) / PULSE_TO_CM; } } The interrupt is attached: attachInterrupt(digitalPinToInterrupt(PIN_ECHO_B2), ISR_USreadB2, CHANGE); I know micros() doesn't work great inside of interrupts but it seems to be working decently when I tested outside of ROS. I am running: ROS Kinetic Ubuntu 16.04 The code is running on a Teensy 3.5

Viewing all articles
Browse latest Browse all 99

Trending Articles