Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Failed to read from stream, Pipeline producer overflowed! #6

Closed
Briancbn opened this issue Oct 16, 2019 · 10 comments
Closed

Failed to read from stream, Pipeline producer overflowed! #6

Briancbn opened this issue Oct 16, 2019 · 10 comments

Comments

@Briancbn
Copy link

Summary

After installing the externalcontrol-1.0.urcap and use my remote pc ip address as the remote host address, I launch the ur3e_bringup.launch file but I keep getting the error Pipeline producer overflowed! , Communication error, what other setting steps did I miss?

Versions

  • ROS Driver version:
  • Affected Robot Software Version(s): PolyScope 5.4
  • Affected Robot Hardware Version(s): ur3e
  • Robot Serial Number:
  • UR+ product(s) installed: ur3e
  • URCaps Software version(s): externalcontrol-1.0.urcap

Issue details

error_msg

Use Case and Setup

Just testing the ur3e driver usability currently

Steps to Reproduce

See summary

Expected Behavior

I didn't expect there to be any error when running the ur3e_bringup program

@fmauch
Copy link
Collaborator

fmauch commented Oct 17, 2019

Thanks for reporting this. I've seen this problem a couple of times during development, but could never quite reproduce it.

Basically, this means that

  • Connection to the robot could be established, the ROS side is receiving data from the robot putting it in a queue
  • Data is not being taken out from the queue, meaning that it overflows.

Looking at the code I might have an idea, where that comes from... Does it happen every time for you? Do the errors eventually stop and the driver is running normally?

@Shaluols
Copy link

This error also happened to me, but not every time. And it did not affect my Moveit controlling.

@fmauch
Copy link
Collaborator

fmauch commented Oct 23, 2019

Thanks for this clarification. I'll prepare a fix that should prevent this from happening.

@Briancbn
Copy link
Author

Briancbn commented Oct 26, 2019

We managed to temporarily resolve the problem by switching to another PC. The error happened all the time on the original PC I tested the code with, but the new PC seems to be ok for now. (I am not sure this helps)

@fmauch
Copy link
Collaborator

fmauch commented Oct 28, 2019

I still think, that this is a bug. Which is why I asked whether the errors eventually stop and the driver is running normally. I'll provide a fix, anyway.

@fmauch fmauch mentioned this issue Oct 28, 2019
@fmauch
Copy link
Collaborator

fmauch commented Oct 28, 2019

@Briancbn, @Abbyls could you please try to reproduce the issue using #18 applied?

@fmauch
Copy link
Collaborator

fmauch commented Nov 7, 2019

Should be fixed in #18. Closing this. If it appears to be not fixed, please reopen.

@fmauch fmauch closed this as completed Nov 7, 2019
fmauch pushed a commit that referenced this issue Feb 5, 2020
Added documentation for non_blocking_read parameter
@ljden
Copy link

ljden commented May 10, 2021

I'm getting this error while running the current stable (master) branch. Would you like me to open a new issue?

@fmauch
Copy link
Collaborator

fmauch commented May 15, 2021

I'm getting this error while running the current stable (master) branch. Would you like me to open a new issue?

Please open a new one describing your specific problem. If we realize that this is really the same problem as here, we can merge them later ( define the new issue a duplicate).

@ljden
Copy link

ljden commented May 15, 2021

I'm getting this error while running the current stable (master) branch. Would you like me to open a new issue?

Please open a new one describing your specific problem. If we realize that this is really the same problem as here, we can merge them later ( define the new issue a duplicate).

See #367. Probably a different source of error

s50370128 pushed a commit to s50370128/Universal_Robots_ROS_Driver that referenced this issue Dec 31, 2021
…ware_interface

Add a parameter to choose the hardware interface for the e-series
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants