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

Rosserial and Arduino resets

asked 2012-03-08 08:27:28 -0600

0pc0 gravatar image

updated 2014-01-28 17:11:36 -0600

ngrennan gravatar image

I'm having an interesting issue with rosserial. When uploading some arduino code, for example Hello World , and running:

rosrun rosserial_python serial_node.py /dev/ttyUSB0

I am able to connect with no issue. If I upload the same code, but unplug and plug back in the arduino hardware before running rosserial I am unable to connect. And only see a repeating:

Lost sync with device, restarting...

I have made sure that the hardware is actually still on the correct serial port. Something about the arduino losing power is changing how it is able to communicate....sounds crazy I know. Has anyone else seen this issue?

-Parker

edit retag flag offensive close merge delete

Comments

Could it be a USB thing? Is the Arduino IDE still connected and rosserial can't access it? Just blindly guessing.

Kevin gravatar image Kevin  ( 2012-03-08 11:20:33 -0600 )edit

6 Answers

Sort by ยป oldest newest most voted
0

answered 2012-03-08 20:55:33 -0600

Bence Magyar gravatar image

This answer might be suitable for you as well: http://answers.ros.org/question/11237/rosserial-lost-sync-with-device

edit flag offensive delete link more
2

answered 2014-02-09 19:07:23 -0600

kvogt gravatar image

For anyone else having this issue, we found a workaround. When the device was unplugged from the USB port, we'd need to reprogram it or change the baud rate a couple times. I noticed the devices worked fine when using minicom and other serial programs, so we looked at the source of these programs to see what they're doing. minicom "resets" the modem by setting the baud to 0 and back. We just made SerialClient.py do the same:

self.port = Serial(port, baud, timeout=self.timeout*0.5)

changes to

self.port = Serial(port, 0, timeout=self.timeout*0.5)
self.port.baudrate = baud
time.sleep(2.0) # give usb chip time to reset
edit flag offensive delete link more

Comments

It didn't work ... I am using rosserrial-indigo and still have the same issue

Wafaay gravatar image Wafaay  ( 2017-03-20 08:19:51 -0600 )edit
2

answered 2012-03-09 14:23:07 -0600

Dustin gravatar image

Bence, thanks for the link but that did not work. I am a colleague of Parker's and have been working with him on this issue. Upon further research we have found that the problem only occurs if the serial cable is disconnected after using serial_node.py to communicate with the node. In other words we can flash the Arduino with the Hello World sketch, disconnect and reconnect the USB cable and communicate with the node via serial_node.py. However if we disconnect the USB cable after doing so, regardless of whether the Arduino is powered via the barrel plug, we are no longer able to communicate with the node via serial_node.py upon reconnecting the serial cable.

Even more strange I just tried this at home and the results are completely different. In fact everything works as expected. I flash the Arduino and communicate with it via serial_node.py. I then disconnect the USB cable, reconnect it and communicate with it via serial_node.py again. No problem. I can repeat this process as much I as I like and all works well.

In both cases our machines are running Ubuntu 11.10, ROS electric and are completely up-to-date with respect to software updates. Spot checking the ros-electric packages shows they are the same version on both machines. It's fine that it works at home but we need it to work in the lab as well. Any thoughts as to how to correct this issue would be greatly appreciated.

edit flag offensive delete link more

Comments

Are you using the same model of arduino at home and in the lab?

ahendrix gravatar image ahendrix  ( 2012-03-09 17:24:12 -0600 )edit

In fact I am using the exact same unit.

Dustin gravatar image Dustin  ( 2012-03-09 17:25:31 -0600 )edit

Are you using the same kernel version on both machines? Are there any extra udev rules on your lab machine? I've found that sometimes certain udev rules can start a process that steals the /dev/ttyUSB0 device.

ahendrix gravatar image ahendrix  ( 2012-03-09 17:58:52 -0600 )edit

It is the same kernel on both machines and the udev rules are the same except my machine has two additional rules. One called 40-joystick.rules and one called 40-virtualbox-guest-dkms.rules.

Dustin gravatar image Dustin  ( 2012-03-11 09:58:53 -0600 )edit

Well, I'm out of easy ideas. This sounds like trouble between your lab machine and the USB to serial chip on your arduino; I would look at the kernel logs (dmesg) and google around for other people having similar issues.

ahendrix gravatar image ahendrix  ( 2012-03-11 11:01:13 -0600 )edit

Same here. Unfortunately this was working just last week without error on the same machine. Reviewing the change log for software updates reveals nothing out of the ordinary though. One thing that stands out is that rosserial_python sends a request to synchronize but the Arduino node never responds.

Dustin gravatar image Dustin  ( 2012-03-11 13:11:50 -0600 )edit
0

answered 2016-06-23 04:36:10 -0600

Tones gravatar image

updated 2016-06-23 04:37:12 -0600

Your problem might be related to this issue (although the error message is slightly different): https://github.com/ros-drivers/rosser...

I am encountering this problem with ubuntu 14.04 and different kernel versions (3.10.96, 3.13.0, 3.16.0).

I found three possible workarounds:

  • Use the current xenial kernel (version 4.4.0) with ubuntu 14.04 (DISCLAIMER: This is a serious change in your system and might cause trouble such as driver incompatibilities)
  • Start the serial_node with baud rate 0, exit and restart the serial node with the correct baud rate. You have to repeat this every time the error occurs.
  • Modify SerialClient.py according to the suggestion of kvogt
edit flag offensive delete link more
0

answered 2016-11-13 08:52:12 -0600

Henrique gravatar image

Well i got this type of problem too, and after some time, i have already tryed all those hacks and nothing worked.

I think this problem is caused by some type of problem with arduinos which use bad usb_serial converter chips. The solution that i worked out is puting those lines in the beginning of the client.py:

        self.port = Serial()
        self.port.port = self.portAdress
        self.port.baudrate = self.baudrate
        self.port.timeout = self.timeout
        self.port.dsrdtr = False
        self.port.open()
        self.port.setParity(PARITY_NONE)
        self.port.setParity(PARITY_ODD)
        self.port.setParity(PARITY_NONE)
        #with the port open reset the arduino
        self.port.setDTR(True)
        time.sleep(0.5)
        self.port.flushInput()
        self.port.setDTR(False)
        time.sleep(0.5)

I dont know why, but the parity change did the trick, dont remove it..

edit flag offensive delete link more

Comments

Can you tell me which client.py did you edit ? I have something like this in client.py in src/rosserial_arduino

import roslib; roslib.load_manifest("rosserial_arduino") import rospy from rosserial_arduino.srv import * def callback(req): print "The arduino is calling! Please send it a message:"

roborag gravatar image roborag  ( 2017-01-24 03:13:44 -0600 )edit
0

answered 2014-02-19 14:25:19 -0600

I tried kvogt solution without success, but found that these other lines worked for me:

self.port = Serial(port, 0, timeout=self.timeout*0.5)
self.port.baudrate = 1200
time.sleep(1.0)
self.port.baudrate = baud
time.sleep(1.0)
edit flag offensive delete link more

Question Tools

1 follower

Stats

Asked: 2012-03-08 08:27:28 -0600

Seen: 5,076 times

Last updated: Nov 13 '16