Industrial Robot Driver, Ur driver? Abb driver?

[guolongHrg]

In fact, I find the industrial robot driver specification at  http://wiki.ros.org/Industrial/Industrial_Robot_Driver_Spec, which says all the industrial robots want to use ros frame need to adhere this specification, but ur robot did not adhere this specification exactly, and I compare the driver with abb_driver and funac_driver and motoman_driver.   And ur modern driver is not supported the robot controller firmware 3.4 and bigger, and we changed it, now works well.

Is someone also find the same problem? And now I want to know if I want to write the ros driver for ourselves arm robot, we want to follow the ur robot , which is easier for us , but  someone say that follow the motoman or abbs is better.

Is someone has some suggestion?

thanks very much.  

email: 690193240@qq,com

[Shaun Edwards]

The UR driver was written before the driver spec was put in place.  We adopted the UR driver as it was since it was widely used.  I'm curious what about the UR drive is "better".  Even though it differs from the ABB/Motoman drivers, it doesn't prevent one from easily switching between robot vendors.

-Shaun

--
You received this message because you are subscribed to the Google Groups "swri-ros-pkg-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to swri-ros-pkg-d...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Shaun Edwards

[guolongHrg]

Tanks very much, now I understand why the UR driver is differ from the Motoman or ABB's driver. 

We thought the UR driver is easier not "better", which is easier for understand and easier for writing a same driver like that, in UR driver way , there is noting to do with the controller, only write the code at the side of ros. We test the UR driver at 12.5hz which moves quite smoothly.

And ABB and Motoman driver is much complex, which need write the code both the robot controller and ros interfaces, and my workmate thought this is the right way to driver the robot in this way, which is "better", in real time control, and adhere the ros-i driver specification.

Which confused me and quite not sure how to do next.

在 2017年4月26日星期三 UTC+8上午9:32:56，Shaun Edwards写道：

[Shaun Edwards]

OK...  The ROS-I specification merely describes the ROS API.  There is another library (not a standard), industrial robot client (http://wiki.ros.org/industrial_robot_client ), that can be leveraged for writing new drivers.  If you use this library, then you only have to write the controller side.  I highly recommend this approach as it reuses code on the ROS side and the controller side implementation is not that difficult.  One caveat is that industrial robot client doesn't leverage ROS control (the new/preferred library for integrating motion control)  However, it could easily be adapted to do so.  ROS Control also support some level of real-time control (if done correctly).

-Shaun

[guolongHrg]

Thanks very much, I find the ABB and Motoman driver also using the industrial robot client library, and I find the MotoRos doc and will learn the code about it.But is there any suggestion that adapt the industrial robot client with ROS Control? I have no idea about this by now. And I think the level of the real-time at controller implementation side is higher than the ROS implementation side, is that right ,or something wrong?  thanks again.

在 2017年4月26日星期三 UTC+8上午10:18:47，Shaun Edwards写道：

[Brett Hemes]

Shaun, somewhat related... maybe you could offer some guidance here.

We have made some progress on creating a new support package for Mecademic's Meca500 robot with the aim to eventually publish as a ROS-Industrial repo.  Next on our list is the driver itself and we are currently evaluating the various design options.  For some context, the robot out of the box uses a very simplistic queued waypoint execution paradigm (waypoints are queued in the order the are received and executed first-in-first out) with the interpolation handled robot-side by the integrated controller based on the motion command chosen.  The robot streams its state over a socket as formatted ASCII text (similar to UR but with ASCII).  We plan to investigate whether any custom interfacing is possible.

Assuming a custom interface is NOT possible it is not immediately obvious to me if the existing ROS-I suggested paradigms are appropriate.

1. With result to the industrial robot client, the robot can not handle simple messages and I feel like we would be overriding (almost) everything.
2. With respect to a ros control approach, I don't know which if any existing controller would be appropriate with the robot performing its own interpolation on queued waypoints.
   

Am I correct in my above concerns? and
In general I prefer the ros control approach, however I think the robots capability will result in a trajectory downloading approach and I don't know how/if this works within the ros control ecosystem.

Thanks,

Brett

To unsubscribe from this group and stop receiving emails from it, send an email to swri-ros-pkg-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Shaun Edwards

--
You received this message because you are subscribed to the Google Groups "swri-ros-pkg-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to swri-ros-pkg-dev+unsubscribe@googlegroups.com.

[G.A. vd. Hoorn - 3ME]

On 4-5-2017 17:33, Brett Hemes wrote:
> Shaun, somewhat related... maybe you could offer some guidance here.

[..]

> Assuming a custom interface is NOT possible it is not immediately obvious
> to me if the existing ROS-I suggested paradigms are appropriate.
>

> 1. With result to the industrial robot client, the robot can not handle

> simple messages and I feel like we would be overriding (almost) everything.

> 2. With respect to a ros control approach, I don't know which if any

> existing controller would be appropriate with the robot performing its own
> interpolation on queued waypoints.

I'm not Shaun, but just a note on ros_control layering on-top of other
controllers: there are 'forwarding controllers' in ros_control that
actually /require/ a lower-level controller to do all the interesting bits.

The idea with those is to still allow such setups to integrate with the
whole ros_control stack, ie: hw interface, controllers and then a
joint_trajectory_controller (if needed).

While (probably) not as performant as an actual low-level/high bw
interface to a robot controller, this would seem to allow you to
integrate this particular controller.

How useful that then still is I don't know. It's questionable how well
the controller(s) (all of them involved) will be able to execute your
trajectory fi.


Gijs

[Brett Hemes]

Sorry Gijs,  wasn't trying to exclude you :)  Thanks for the answer.  The notion of a forwarding controller is interesting.  Performance aside, would this ultimately be compatible with moveit and joint trajectory action?

[G.A. vd. Hoorn - 3ME]

On 4-5-2017 17:51, Brett Hemes wrote:
> Sorry Gijs, wasn't trying to exclude you :) Thanks for the answer. The
> notion of a forwarding controller is interesting. Performance aside, would
> this ultimately be compatible with moveit and joint trajectory action?

yes. It's basically a 'regular' ros_control controller.

So anything that you could normally layer on top of that should work.

re: moveit: as soon as you have a FollowJointTrajectory action server
MoveIt can talk to that. In ros_control, that would be offered by the
joint_trajectory_controller.


Gijs

[Brett Hemes]

OK, excuse my ignorance here... still learning.

From what I understand it will be possible for me to use ros_control for my driver by using the positional version of the joint_trajectory_controller (position_controllers/JointTrajectoryController).  My robot-specific hardware_interface will take the produced commands (joint positions) and then compose a corresponding ASCII command to stream out to the robot (that will then get queued and executed via the robot's internal controller).

Do I then control the command rate (joint commands to the robot) within the driver node by how fast I execute the read()/update()/write() loop?  I am still a bit confused here... I guess I pick a tx rate that is fast enough to preserve the required accuracy but not so fast that I choke the robot's controller...

It seems I can use the kuka_rsi_hw_interface as a template and modify the hardware_interface for the Meca500 (i.e., change read() and write() functions to comply with the ASCII serial protocol of the Meca500).  Then I will end up with a position_controllers/JointTrajectoryController that can be remapped appropriately (i.e., to get /joint_trajectory_action etc. as in your convenience launch file).

Thanks for the help Gijs, I have to say I am finding the documentation for ros_control(lers) is a bit tough to navigate...

Brett