Potential use with Robotiq 3f?

[umicharmlab]

Hello! I'm wondering if I can use this to control our 3f grippers. I believe this is for the 2f, so I would expect to need to do some work to make it work for 3f but so far this is the best/closest thing I've found to a ROS2 driver for the robotiq 3f.

I have the datasheet so I could presumably make a new driver class for 3f? I'd also need a urdf, which I can probably copy from the ros1 repo. Any major hurdles/roadblocks that I'm missing?

Are contributions are welcome? If I get this working should I make a PR to add this? or should it be a separate repo?

[PeterMitrano]

^ This was me, I was using our shared lab account :)

[moriarty]

I'm not sure, but we'd welcome PRs if you do get it working.

The idea behind this big PR: #34

Was to get this repo more in sync with another repo we've been working on and then having all the robotiq grippers in one place, and we would welcome the 3f gripper too we just don't have one physically.

[moriarty]

CC @kineticsystem thoughts/opinions?

[PeterMitrano]

I'm planning to start by just in-place updating things from 2f to 3f, but I would like to contribute this back once I get that working. There seems to be quite a lot of abstraction/structure in the code that I don't immediately understand how to use. Would someone be able to explain briefly what the intention was and what the names mean? Why "factory" and why "default_*"?

[kineticsystem]

The idea is to have those two repo merged into one.
https://github.com/PickNikRobotics/ros2_epick_gripper
https://github.com/PickNikRobotics/ros2_robotiq_gripper
There is a lot of code in common in these two repos, literally the same code. We want to merge the two repos, have each gripper specific code in its own package, and all the common code in a third package. We should do that first before adding an any extra gripper.

The idea behind all those abstractions is testability. Each code layer can be tested in isolation without connecting to the hardware. This diagram may help you understand how all the abstractions are combined.
https://github.com/PickNikRobotics/ros2_epick_gripper/blob/main/docs/class_diagram.png

When you see something that start by default_ it means it is the default implementation for a given interface.

[kineticsystem]

Unfortunately, testing a hardware interface in isolation is impossible because it is a concrete class. For this reason, I added a factory to create a driver and plug it into the hardware interface. We can mock the factory and make the hardware interface believe it is connected to hardware while it is not. The Default Driver returned by the Default Factory can also be used in isolation, without ROS, and in fact is used on its own inside some test executables in the hardware_test package. These tests are used to check id the hardware is properly configured.

If you need more information we can setup a meeting, I think it is easier to guide you through the code.

[kineticsystem]

One last thing. If you look at the diagram
https://github.com/PickNikRobotics/ros2_epick_gripper/blob/main/docs/class_diagram.png
DefaultSerial, Serial and MockSerial, they are all common code between the two grippers, and they are used to implement the serial communication.

[PeterMitrano]

Thanks Giovanni! So when merged, default_driver_factory would be renamed to 2f_driver then we'd also have 3f_driver and epick_driver?

Do you think merging the 2f and epick repos will happen in the next month or two? I will be working with this 3f code for a little while, so I could help get all three in the same repo.

[kineticsystem]

We could rename them or keep the same names and use the namespaces to distinguish them. They already live in different namespaces.

I would like to have them merged sooner rather than later; I do not think it is a difficult task.

If you follow the structure of this repo and reuse the classes for the serial communication, we can drop your code easily into the merged repo.

Hopefully, the only code that will differ will be the driver, which is specific to your hardware. It is important that your code is as testable as the existing one. We already provided tests for the serial communication; you only have to test your hardware interface and driver and provide a CLI to test the actual hardware.

If you would like me to drive through the code, let me know.

[PeterMitrano]

Ok, I'll base mine of the epick one then. If someone makes a PR to merge epick into this repo then please tag me so I can see how it looks

[PeterMitrano]

Here's my working draft, now based on the epick repo.

[moriarty]

Cool,
Yes I think it would be great to get them all merged together.
We're using the e-pick and 2f-85 and it would be nice to keep everything in one place and share the maintenance overhead.

Based on #40 and a slack msg from @eholum someone is also working on the Hand-E gripper support.

[PeterMitrano]

Question for you all -- how do you think I should be support "modes" and "mode changing" in ros2 control? Do I need to write a custom "controller" that provides the ROS topics/services for setting and getting modes? I was also considering just putting that directly in the driver for simplicity. I don't think the standard controllers and state/command interfaces are useful for custom modes like the robotiq 3f gripper has. How would y'all do it?

[moriarty]

I haven't gotten to play with the 3f gripper nor am I familiar with it's custom modes but I'd probably discuss it with @MarqRazz and on roscontrol.slack.com

[PeterMitrano]

Oh cool I didn't know there was such a thing -- does someone have to add me? I'm not sure how to join.