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

What is the function of this package now? #26

Closed
DongMuJi opened this issue Jun 19, 2018 · 16 comments
Closed

What is the function of this package now? #26

DongMuJi opened this issue Jun 19, 2018 · 16 comments

Comments

@DongMuJi
Copy link

Hi
Now I want to use this package. But I do not konw what is the function of this package now.
I also see a stack named staubli. What is different between staubi_experimental and staubli?
Thank you very much!

@nilsmelchert
Copy link
Contributor

Hi,

What is different between staubi_experimental and staubli?

There is basicly no difference between those two packages. The only difference is, that the packages in staubli_experimental are not fully tested yet. Am I right @gavanderhoorn ?

Both of them contain support packages of certain robots from staubli (a description of how to work with support packages can be found here).

The staubli package contains support packages for the staubli rx160.

The staubli_experimental package contains support packages and gazebo simulation packages for the tx60 and tx90 series. Besides that, there has also been a hardware interface (staubli_val3_driver) delevoped by @muhrix in order to communicate with the "real" robots.

The common way to work with these packages and control a certain robot. is to use a moveit package.
If you are new to ros industrial, I would recommend to do these tutorials first, which give you a nice introduction.

In order to give you a more specific answer, it would be great if you would tell me what you would like to do:

  • working with a real robot?
  • working with a simulated environment?
  • starting to work with ros industrial?

For now you can first of run

roslaunch staubli_tx60_support test_tx60.launch

to be able to see what a robot, built from an URDF-file looks like and can test how the links and joints of a certain robot refer to each other.

@gavanderhoorn
Copy link
Member

@DongMuJi: @nilsmelchert is exactly right.

@gavanderhoorn
Copy link
Member

We should start migrating the packages in staubli_experimental to staubli though.

@gavanderhoorn
Copy link
Member

@nilsmelchert wrote:

Besides that, there has also been a hardware interface (staubli_val3_driver) delevoped by @muhrix in order to communicate with the "real" robots.

One nitpick: let's not use the name "hardware interface" for staubli_val3_driver, but let's call it a "driver".

hardware_interface is a package in ros_control and that works quite differently from how staubli_val3_driver works.

@nilsmelchert
Copy link
Contributor

We should start migrating the packages in staubli_experimental to staubli though.

What would be the next steps to make this happen?
Since I am working with the tx60 and the tx90 robots (in gazebo simulation mode and with the staubli val3 driver for the CS8C Controller), I can confirm, that I have not had any problems with any of the packages.
The val3 driver works perfectly fine.

@gavanderhoorn
Copy link
Member

For all packages in staubli_experimental we can migrate them.

There is no fixed 'period' of time as it also depends on usage (ie: a bunch of pkgs sitting in a repository unused for 6 months is not a good indicator of stability, regardless of whether they see PRs or issues being reported).

But all packages in this repository have seen sufficient usage.

What would be the next steps to make this happen?

We'd need to start opening PRs migrating the packages. I have a process documented, but it's not publicly accessible right now. I could make it available, but there is a bit of a debate (see ros-industrial/ros_industrial_issues#49 fi) whether to do that with all history or just do a 'current-state' import.

@nilsmelchert
Copy link
Contributor

nilsmelchert commented Jun 19, 2018

Well then I would just start creating PRs for the Tx90 and Tx60 support and gazebo packages.

If I get you right, there is a debate about moving the hardware drivers of ros industrial robots into an isolated repo.
I actually like that the location of the hardware driver. Since the Issue you mentioned is still open, I would recommend to also move the staubli_val3_driver to the staubli repo for now.

Are you ok with that?

@gavanderhoorn
Copy link
Member

@nilsmelchert wrote:

If I get you right, there is a debate about moving the hardware drivers of ros industrial robots into an isolated repo.

the debate is about whether to move things with git history (ie: commits) or without. ros-industrial/ros_industrial_issues#49 touches on that, which is why I mentioned it.

Let's continue discussion of migration of pkgs in #27.

@gavanderhoorn
Copy link
Member

gavanderhoorn commented Jun 19, 2018

@DongMuJi: as your question is not a software-related issue, but more a usage one, I'm going to close this here for now. I also believe @nilsmelchert has explained things quite well.

If you still have questions you can keep commenting on this issue though.

@DongMuJi
Copy link
Author

@nilsmelchert :Thank you for your replay. Now we use this package with the real robot(RX160). We meet some issues.

  1. Follow the staubli_val3_driver README ,from the topic /joint_state, we can only see every joint position (no velocity and effort) . Is this right?

  2. We try to use the moveit to control the arm.
    First, roslaunch the move_group.launch. It shows that can not find the robot module.
    Then, we add the robot module in the launch file.It shows some warnings.
    img_20180615_161042
    We use the move_group plugin in RVIZ, the robot state is same as the real robot.But when we set the target location and click planning button.It shows the error,planing false.
    img_20180615_160527
    Can you give me some suggestion how to use it?

  3. Can we use position control mode(or velocity control mode or effort control mode ) to control the joint which we select?

  4. Now we are confused when we roslaunch the file, what we can do to control the arm?

Thank you a lot!

@gavanderhoorn
Copy link
Member

staubli_val3_driver supports joint position control only. No velocity or torque control.

It also only reports joint positions, but that could be extended to include velocity and effort if the VAL3 code is extended.

As to the warnings and errors: can you please show the exact commands that you are using to start things? What do you mean exactly with "robot module"?

Please also provide some more details on your OS, ROS version and how you installed everything. We cannot guess these things.

And please try to avoid posting images that show console output: it's all text, so please just copy-paste it instead of making photos of monitors.

@jacktnho
Copy link

staubli_val3_driver supports joint position control only. No velocity or torque control.

It also only reports joint positions, but that could be extended to include velocity and effort if the VAL3 code is extended.

As to the warnings and errors: can you please show the exact commands that you are using to start things? What do you mean exactly with "robot module"?

Please also provide some more details on your OS, ROS version and how you installed everything. We cannot guess these things.

And please try to avoid posting images that show console output: it's all text, so please just copy-paste it instead of making photos of monitors.

Hello!
May i ask if the current package staubli_val3_driver support controlling the digital I/O ports of the CS8 controller?
many thanks!

@nilsmelchert
Copy link
Contributor

As far as I know, the IO is not implemented so far. Nor are the effort values of the joint torques.
You are of course very welcome to create a PR for those new features.

@gavanderhoorn
Copy link
Member

@nilsmelchert is correct: there is no support for IO as exposed by the controller in staubli_val3_driver.

I would like to add that I don't believe we will be adding that any time soon as the currently accepted practice is to use a separate fieldbus (and accompanying ROS interface) to control IOs. Fieldbus are much more mature, standardised, come with a lot of tools, have a long history of working and are deterministic and directly supported by the manufacturers of both (industrial) robots and of fieldbus interface cards.

@simonschmeisser
Copy link
Contributor

Highjacking this old question and knowing your objections @gavanderhoorn ;) ... how would I toggle the valve on ValveIO\valve1 from VAL3?

@gavanderhoorn
Copy link
Member

If you are asking how you'd do that using staubli_val3_driver, then I believe the answer would be: you'd have to add it, as there is no support for that right now.

I believe you've already done that in your fork though.

My recommendation for any production system would still be to use a proper fieldbus. Perhaps even modbus (for which several ROS packages exist).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

5 participants