Robotiq simulation

[TheDash]

Hi guys,

I've been thinking - I should make a separate repo for the gazebo plugins and simulation for the robotiq grippers. Simply because putting it into the robotiq stack doesn't make sense for the real robot as it makes robot hardware have to install gazebo which is massively unneeded.

Thoughts?

robotiq_simulation repo?

[shaun-edwards]

So far in ROS-I, we've always included everything under a single repo for simplicity. This has the main benefit of not having multiple PRs across several repos for changes, although I'm not sure how often such a change would touch simulation and hardware.

What "makes" you have to install gazebo? Is it rosdep? If we released a debian (which we are pretty close to), would that make a difference?

[TheDash]

It would be the ros dependencies in the package.xml, since gazebo_plugins depends on gazebo, and if its included here, all robots with the hardware robotiq_ package have to then install gazebo which is unnecessarily large. This becomes a dep for the debian packages too, and it prevents compilation using catkin_make because gazebo isn't installed

[shaun-edwards]

I see. Is it just a meta-package problem. Should we create two meta-packages

• robotiq_hardware
  • ...
• robotiq_simulation
  • ...

And then the robotiq meta-package becomes:

• robotiq
  • robotiq_hardware
  • robotiq_simulation

Will this solve the issue?

[athackst]

Doesn't this issue go away with the debian release? Then you would install robotiq__control, which shouldn't have a dependency tree that points toward a gazebo plugin. You wouldn't need to install the entire meta-package on a robot.

[shaun-edwards]

Just an FYI...we are close to a debian release. I just have to verify the installs are correct. I'm out next week, so it may be a couple of weeks until this is done.

[TheDash]

@athackst I guess so? As long as only everything that depended on gazebo was logically separated. If that's the case, the code should be divided as well into two meta-packages for clarity. It's a convention 90% of ROS enabled robots/hardware uses

@shaun-edwards yeah, a robotiq_robot and robotiq_simulator (as per conventional naming) is ideal.

[athackst]

@TheDash Then you would also have to add a robotiq_common because there should be shared resources between robot and simulator (for example the urdf and msgs).

Unless you're just suggesting two additional meta packages that will aide in debian installs and not a hierarchy.

[TheDash]

Well, I'm up for it. We have deployed this code on 3-4 robots now and maintaining it as is is getting very difficult & logical commits/architecture are getting very messy.

I'll make some repos and reference them to this thread where you guys can code review and take a look and see if it makes sense. If they're good, we can initiate a transfer

[carlosjoserg]

Hey @TheDash , how are you doing with the simulation? Could you point out the repos you say above?

I'm starting to work on the new 2F models, and I'd like to see what others are doing as well.

@shaun-edwards I'd like to create one unique folder like this:

• robotiq_2f_hardware
  • real : similar to PR #63 by @athackst
  • simulation : with the adaptable behavior added, not in gazebo_ros_control plugin ;)

I understand the implications of having gazebo as dependency, but hey, ain't ROS already a large dependency anyway?

My reasoning behind is that I like to have a hardware abstraction class described under ros-control, and then share it for real and simulation purposes. That is, the only thing to implement for any new interface (real or sim) is the init(), read() and write() which are defined as pure virtual in the abstract class. So the derived class for simulation will inherently depend on gazebo, as the real depends on the communication libraries.

What do you think?

[athackst]

@carlosjoserg That was the point of PR #63. It has a comm abstraction layer that allows for the integration of the many different communication libraries that the hand supports. If I were to reorganize this repo, I would separate out the communication files into their own separate packages (ex: robotiq_can, robotiq_ethercat, or even robotiq_gazebo for simmed comm) and they would depend on the shared control code in robotiq_s_model_control. However I thought my PR was large enough as is, and didn't pursue it.

I believe @TheDash wanted to separate simulation and real portions of the code into different repos, which I don't think is the right solution to the problem of having to install a bloated set of dependencies to get this running on a robot. I think the right solution involves better package separation and debian installs, but all the code lives in one repo. It makes things much easier to update and maintain.

[TheDash]

@carlosjoserg

No longer working on this stuff, and still unable to complete these long standing robotiq/universal_robot PR's =(.. until probably... January Lol

But thoughts:

as per convention that has worked rather well, is that each robot (or robotics product) has a _simulation package and a _robot package, each independently included on the computer it is intended for. This allows for logical separation for the suites it provides, and dependencies included.

So for example, Gazebo and RViz doesn't get forced to be installed on your robot (which may or may not be able to render or support the CPU required to use these things, or bloat your hard disk)

@athackst Adding to what I just said above - the separate repos have just been conventional - what the real function here is to just have logical separation between the intent of use. It doesn't matter if its in a separate repo, but separate packages at a minimum. Separate github repos is a matter of my preference.

[carlosjoserg]

@athackst Yes, I'm looking at it to develop it for the 2F models, since unfortunately, it can't be used for these, I believe. So that's what I am onto now.

Thanks for the thoughts @TheDash ... when you say the robotiq/universal_robot PR's what do you mean, could you point me to those PRs or work you have done? Is it that you wanted to have a single hwiface to move both devices using a single ethernet connection (like accessing the USB of the remote debian within the UR controller while the gripper is connected to it)?

I see your points of having robot and simulation separated, it is for the case in which one would like to have an on-board PC with the minimum of stuff. In that case, yes, it is useful to have separated apt-get'able packages, but I'd definitely go for a single github repo (agree with @athackst on this), also because the different packages would be tightly related and they'd refer to the same gripper.

What I would probably have in two separated github's is for 3 and 2 finger model packages.

I'll soon provide what I have on the new 2F models so you can give me your feedback. Thanks.

[wxmerkt]

@TheDash any update on the robotiq/universal_robot PRs? We are very keen to get them integrated to move forward with the dual_ur5_husky simulation and development

[ancorasir]

not sure if it helps but I'm working on a PR including a robotiq 3 finger gripper and a ur5 arm for simulation ancorasir_urobotiq.

currently experiencing problems with rostopic /left_hand/command and state to send command to the gripper, any suggestions to resolve this issue?

like @TheDash mentioned, the osrf/drcsim is really complicated to "hack"

Thanks a lot

[gavanderhoorn]

@ancorasir wrote:

currently experiencing problems with rostopic /left_hand/command and state to send command to the gripper, any suggestions to resolve this issue?

Well, what are the "problems"?

[ancorasir]

@gavanderhoorn sorry but I'm not exactly sure, can make the gazebo simulation work just like the drcsim's robotiq tutorial, but somehow the left_hand/command and left_hand/state topics are not showing up, can't control the gripper.

any idea where to look for the solution? thanks

[TheDash]

You've gotta get the atlas gazebo plugins and port them over to get the gazebo topics working in sim

[TheDash]

@wxmerkt Heads up we are planning another development cycle in approx 1 months time relating to this where I will fix all of this up and re-org our robots setup

[ancorasir]

@TheDash

could you please explain a little bit more on the following line? new to ROS, sorry about that

get the atlas gazebo plugins and port them over

do you mean "apt-get install" drcsim in ROS or put the drcsim package in the same workspace?

[TheDash]

Sorry, trying to do this with little instruction as possible here.

https://bitbucket.org/osrf/drcsim/src/194be8500fef/drcsim_gazebo_ros_plugins/?at=default

In short, you want to make sure you have this: (RobotiqHandPlugin)

https://bitbucket.org/osrf/drcsim/src/194be8500fef81593f79607a21ee2badd9700a0e/drcsim_gazebo_ros_plugins/include/drcsim_gazebo_ros_plugins/RobotiqHandPlugin.h?at=default&fileviewer=file-view-default

[TheDash]

@ancorasir

In the indigo-devel branch see the robotiq gazebo articulated plugins package, i ported it over to there. That should work if it's in your catkin ws and you are loading the gazebo plugin in your urdf

[superxingzheng]

I am trying to simulate the 3 finger hand in Gazebo with the ros-industrial kinectic-devel branch. I see the plugins mentioned by @TheDash . But I don't see any URDF that loads the plugins. A tested template URDF for Gazebo would be very helpful. Thanks in advance!

[padhupradheep]

Hey guys,

I'm trying to use robotiq-3f-gripper along with UR-10 Robot in simulation. Currently, I was able to fix the gripper to the robot by making changes to the urdf. But, I'm unsure how to do basic operations like pinch, open in the ROS, Gazebo simulation. Can you guys just guide me on how to start of with the simulation.?

Thanks!

[ngwk1]

Hi, I have attempted to use the default gazebo plugins for the robotiq-3f-gripper along with UR Robot in simulation. Able to control by setting from both rostopic and moveit. Need more work on setting the PID as well as other factors to make the model less agitated/wobbly. Attached a GIF to show the controlled via Moveit to Gazebo model.

Noteworthy: If used on only RVIZ, the package will work perfectly fine.