Why are my rosserial messages garbled on arrival to OpenCR?

asked 2018-08-09 08:16:23 -0600

airhorns gravatar image

updated 2018-08-13 12:27:45 -0600

I'm trying to write a custom firmware for OpenCR to drive a robot other than a TurtleBot3. I'm using Twist messages published from a test rospy script to send onwards to the OpenCR firmware via rosserial, but the contents of the messages on the receiving side are not as I sent them.

I'm not exactly sure how the message ends up as it is, but if I sprintf the values received over the wire, it seems like they vary from being 0, -2, and a very very large integer that seems like it is an overflow. I would expect them to be the same as I am sending them from Python land.

OpenCR only really emulates an Arduino, and there's a mention in the documentation that some of the ros_lib Arduino libraries have been modified for the hardware specific to OpenCR. I have tried running with my own generated ros_lib, the turtlebot3_ros_lib from the OpenCR repository, and with no ros_lib-related libraries in my project such that the one embedded in the OpenCR board configuration gets used, and it doesn't seem to make any difference.

Here's an example run of the test script on my host that publishes messages:

root@sprout:~/catkin_ws# python ~/app/tugboat/test/motor_test.py 
[INFO] [1533820081.365298]: linear: 
  x: -0.135754864055
  y: 0
  z: 0
angular: 
  x: 0
  y: 0
  z: -0.679274703424
[INFO] [1533820081.463683]: linear: 
  x: -0.128229837148
  y: 0
  z: 0
angular: 
  x: 0
  y: 0
  z: -0.715908250178
[INFO] [1533820081.564090]: linear: 
  x: -0.120405402722
  y: 0
  z: 0
angular: 
  x: 0
  y: 0
  z: -0.751644311374
# ... snip

And here's an example of what seems to be arriving at OpenCR:

devfirmware_rosserial_1  | [INFO] [1533757015.825814]: ROS Serial Python Node
devfirmware_rosserial_1  | [INFO] [1533757015.837030]: Connecting to /dev/ttyACM0 at 57600 baud
devfirmware_rosserial_1  | [INFO] [1533757017.974415]: Note: subscribe buffer size is 1024 bytes
devfirmware_rosserial_1  | [INFO] [1533757017.974978]: Setup subscriber on cmd_vel [geometry_msgs/Twist]
devfirmware_rosserial_1  | [INFO] [1533757017.980478]: Setup subscriber on motor_power [std_msgs/Bool]
devfirmware_rosserial_1  | [INFO] [1533757017.984510]: Setup subscriber on reset [std_msgs/Empty]
devfirmware_rosserial_1  | [INFO] [1533757021.342291]: goal_velocity_cmd linear=26815635018547947003520042492298900444795045699074586295975015555529561951619119068050367547157165677495562220457019472005532242858568270096346353898618880.000000 angular= 0.000000
devfirmware_rosserial_1  | [INFO] [1533757021.443306]: goal_velocity_cmd linear= 0.000000 angular= 0.000000
devfirmware_rosserial_1  | [INFO] [1533757021.552619]: goal_velocity_cmd linear= 0.000000 angular= 0.000000
devfirmware_rosserial_1  | [INFO] [1533757021.645970]: goal_velocity_cmd linear=26815635018679589800415901776210826205356983248386788284836442571166664271756824572989573094671584942541931284769711377256392798556191445325024837289115648.000000 angular= 0.000000
devfirmware_rosserial_1  | [INFO] [1533757021.745490]: goal_velocity_cmd linear=-2.000001 angular= 0.000000

Here's the rosserial callback in the Arduino sketch being loaded to OpenCR: https://github.com/airhorns/tugboat/b...

Here's the test script that publishes those messages: https://github.com/airhorns/tugboat/b...

Even more confusingly, I am publishing IMU messages from the OpenCR back to the host without issue at 300Hz. This issue happens with the IMU publisher enabled and disabled. This suggests the serial link is working ok. I've also tried at 57600 baud and 115200 but that doesn't seem to be making any difference.

Why am I getting gibberish but no crashes?

I'm ... (more)

edit retag flag offensive close merge delete

Comments

Have you tried adding some sleeps to the code? You're probably reading too much too quickly.

allenh1 gravatar imageallenh1 ( 2018-08-09 08:51:20 -0600 )edit

No, I can try that! What actually happens if you read too fast? The messages are only being published at 10Hz, and wouldn't rosserial complain if the messages were malformed so I am surprised this might be an issue.

airhorns gravatar imageairhorns ( 2018-08-09 09:03:36 -0600 )edit

Would you try to launch your own node after gyro sensor are calibrated? http://emanual.robotis.com/docs/en/pl...

Darby Lim gravatar imageDarby Lim ( 2018-08-09 19:43:26 -0600 )edit

Darby, do you mean try to launch my host-side test script with the standard Turtlebot3 firmware? At the moment, I'm not using the standard Turtlebot3 firmware and am instead using my own arduino sketch, and I'm not yet doing anything with the gyro. The code is linked above.

airhorns gravatar imageairhorns ( 2018-08-09 20:09:26 -0600 )edit

I just tried publishing IMU messages from the OpenCR back to the host and it worked. This issue happens with the IMU publisher enabled and disabled. This suggests the serial link is working ok. I've also tried at 57600 baud and 115200 but that doesn't seem to be making any difference either. Ideas?

airhorns gravatar imageairhorns ( 2018-08-13 12:28:30 -0600 )edit

Could it be that the printf included with OpenCR doesn't support printing floats? https://www.avrfreaks.net/forum/unabl... Any pointers on figuring out if that's the case?

airhorns gravatar imageairhorns ( 2018-08-13 15:44:16 -0600 )edit