ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
0

Unreliable connection using rosserial [closed]

asked 2011-10-04 23:26:16 -0500

updated 2011-10-07 20:18:55 -0500

I'm using a Atmega 168 based Microcontroller as a motor controller (http://robosavvy.com/store/product_info.php/products_id/1168). I have implemented a custom serial protocol before rosserial came out, which works fine for sending commands to the motor controller ( as seen here: http://www.youtube.com/watch?v=7zcr5IVYHN4 ).

I now wanted to switch to using rosserial, this however does not work reliably. Note that I edited the rosserial buffer settings as suggested here: http://answers.ros.org/question/2120/problem-setting-up-rosserial_arduino to be able to run it on the low RAM Atmega 168. I can send motor commands to the platform for around 20-30 seconds max, afterwards i get the following:

[INFO] [WallTime: 1317812318.730347] ROS Serial Python Node
[INFO] [WallTime: 1317812318.732631] Connected on /dev/ttyUSB0 at 38400 baud
[INFO] [WallTime: 1317812320.870123] Setup Publisher on base_health [thumper_msgs/BaseHealth]
[INFO] [WallTime: 1317812320.886399] Setup Subscriber on base_desired_state [thumper_msgs/BaseDesiredMotorState]
Traceback (most recent call last):
  File "/home/stefan/rosext/rosserial/rosserial_python/nodes/serial_node.py", line 58, in <module>
    client.run()
  File "/home/stefan/rosext/rosserial/rosserial_python/src/rosserial_python/SerialClient.py", line 212, in run
    chk = self.port.read(1)
  File "/usr/lib/python2.7/dist-packages/serial/serialposix.py", line 456, in read
    raise SerialException('device reports readiness to read but returned no data (device disconnected?)')
serial.serialutil.SerialException: device reports readiness to read but returned no data (device disconnected?)

I tried both the default 57600 baud rate as well as 38400 (which I used in my custom serial protocol so far). So communication seems to work in principle (both to and from the microcontroller), but it is very unreliable. Any pointers on how to improve the situation are welcome :)

Edit: I'm using the current rosserial version checked out from https://kforge.ros.org/rosserial/hg

Edit for more info: I now tried the suggestions by fergs, observations:

  • There is nothing suspicious in the Kernel log, nothing added when trying dmesg before and after disconnect.
  • I occassionally get "Failed Packet Flags", then after some random time the connection drops, as described above.
  • Sometimes when restarting after disconnect, the message "Tried to publish before configured, topic id xxx" is continously spammed to the console. Another reconnect fixes this most of them time. UPDATE: This apparently was caused by accidentaly spamming data on a topic on a publisher at the arduino side. I limited it to 10 Hz now and this error has gone.
  • It seems the spamming fix made everything a bit more stable, but disconnection errors persist, with the system running few minutes max at a time.
  • After disabling the publisher on the arduino side the disconnects are gone (Just to confirm that we're solely looking at read errors on the Linux side)
edit retag flag offensive reopen merge delete

Closed for the following reason question is not relevant or outdated by tfoote
close date 2012-04-01 09:39:25

2 Answers

Sort by ยป oldest newest most voted
0

answered 2011-10-08 06:18:15 -0500

Per Lenander gravatar image

Are you using a custom message and if so have you correctly exported it to the arduino using the make_library.py script? I got an error similar to this previously (packet fail errors and "device reports readiness to read but returned no data" from serial_node.py), and I managed to resolve it by cleaning everything up, rebuilding my custom message packages (both roscpp and for the arduino).

I think the error I experienced was due to the generated arduino messages being out of date.

edit flag offensive delete link more
0

answered 2011-10-05 11:55:06 -0500

fergs gravatar image

I've not seen that SerialException before. Could you check the output of "dmesg" command around the time this happens and see if the kernel log is reporting any interesting USB issues? Also, is your other code using PySerial, or something different?

It seems some people with other PySerial software have been able to simply catch this error and proceed as normal, I'll investigate that a bit more.

edit flag offensive delete link more

Comments

Hi fergs, thanks for the quick response. I'll look into the kernel log next time I'm near the hardware and will post the results here. I'm also using PySerial for my custom protocol. Currently, I can switch between the rosserial and the custom protocol using multiple ugly #ifdefs on the mc side.
Stefan Kohlbrecher gravatar image Stefan Kohlbrecher  ( 2011-10-06 00:00:16 -0500 )edit

Question Tools

Stats

Asked: 2011-10-04 23:26:16 -0500

Seen: 2,381 times

Last updated: Oct 08 '11