Moveit planning execution

[marcoesposito1988]

No description provided.

[carlosjoserg]

Did you checked the new launch file and how it can be used in the readme? I believe you can do pretty much the same with that file.

In case I'm wrong, would you consider placing it in the single_lwr_launch package? I'd like to leave the single_lwr_moveit as close to what the setup assistant creates as possible.

[marcoesposito1988]

I completely agree that the functionality of single_lwr_launch makes it redundant, but this file is a part of the ROS-I standard and many of my launch files depend on it.

See: http://wiki.ros.org/Industrial/Tutorials/Create_a_MoveIt_Pkg_for_an_Industrial_Robot#Update_Configuration_Files at point 4

[carlosjoserg]

I see. Ok, let me review it, but then you need to update the single_lwr_example tutorial to explain where that file comes from as well.

In any case, you shouldn't be using the single_lwr_example package in your apps!

Maybe I didn't described well the new structure. The whole point of it is that the kuka lwr packages are only model and hw (lwr_controllers is just a plus), and that users should follow the single_lwr_example tutorial to create their own package. For instance, I'm sure you don't have the robot mounted on a red box!

So, If you create your package, we can reference it in the main readme, as I did with our Vito robot, but then it would be more of a complete subsection like:

Projects using the kuka lwr packages

• Vito robot
• Marco's robot
• etc

[carlosjoserg]

Because the robot_state_publisher subscribes to /joint_states, where nothing will be published in this case. A more general way to do it is:

<node name="joint_state_publisher" pkg="joint_state_publisher" type="joint_state_publisher">
  <param name="use_gui" value="$(arg gui)"/>
  <rosparam param="source_list">[/lwr/joint_states]</rosparam>
</node>

So, in case you have more devices, you can put them all there and have a single /joint_states with all devices. Check this one

[marcoesposito1988]

Thanks a lot! Now it makes sense :)

[carlosjoserg]

Would you consider the comments and re-PR? (remember to update the tutorial)

[marcoesposito1988]

This is where our views differ ;) usually any robot supported by ROS-Industrial can be used out of the box. In many cases (probably the majority) manipulators are fixed to a table or to some supporting surface, so it is usual to provide a working configuration where the robot is "floating in space".

More complex cases can be easily handled by including the robot into a larger xacro; of course, this is possible only as long as the URDF is modular enough. I still think that we can have a simpler structure and accomodate all the needs related to using the arm in a composed robot.

I would really like to hear @gavanderhoorn 's opinion regarding this. Would the actual structure be ok for acceptance into the ROS-I umbrella?

---

Marco Esposito
Research Assistant

Computer Aided Medical Procedures (CAMP)
Technische Universität München
Institut fuer Informatik I16
Boltzmannstr. 3
85748 Garching b. Muenchen, Germany
campar.in.tum.dehttp://campar.in.tum.de

E-Mail: marco.esposito@tum.demailto:marco.esposito@tum.de
Phone: +49 89 289 19403

---

From: Carlos J. Rosales notifications@github.com
Sent: Saturday, June 6, 2015 9:19 AM
To: CentroEPiaggio/kuka-lwr
Cc: Esposito, Marco
Subject: Re: [kuka-lwr] Moveit planning execution (#23)

I see. Ok, let me review it, but then you need to update the single_lwr_example tutorial to explain where that file comes from as well.

In any case, you shouldn't be using the single_lwr_example package in your apps!

Maybe I didn't described well the new structure. The whole point of it is that the kuka lwr packages are only model and hw (lwr_controllers is just a plus), and that users should follow the single_lwr_example tutorial to create their own package. For instance, I'm sure you don't have the robot mounted on a red box!

So, If you create your package, we can reference it in the main readmehttps://github.com/CentroEPiaggio/kuka-lwr/blob/master/README.md, as I did with our Vito robothttps://github.com/CentroEPiaggio/vito-robot, but then it would be more of a complete subsection like:

Projects using the kuka lwr packages

• Vito robot
• Marco's robot
• etc

Reply to this email directly or view it on GitHubhttps://github.com//pull/23#issuecomment-109542473.

[carlosjoserg]

This is where our views differ ;)

I know ; )

I still think that we can have a simpler structure

That's what the single_lwr_example is for indeed.

I still have three more points in my defense:

1. All are configuration files. One package is generated automatically by the setup_assistant, and the other two are very simple, only requires for an user to write a launch file and the robot definition (with the corresponding configuration files).
2. I don't know much about other robots, but in the case of the kuka, it is extremely important to know the configuration if you plan to use the joint impedance strategy. There are two ways to deal with a different configuration from the horizontal fixed table you mention, which is either changing the gravity vector or the $ROBROOT variable. I strongly recommend the latter. And this variable should be equal to the origin block you pass in the robot definition, which I find a nice method to be aware of that.
3. I do really think that it is the user that should configure the MoveIt! package, no matter how simple the scenario is, to make the user aware of the environment, groups, joints, chains he/she wants to plan for. It is more of a middle-level app-specific package to me, and the setup_assistant is very user-friendly.

Just forwarding the question:

I would really like to hear @gavanderhoorn 's opinion regarding this. Would the actual structure be ok for acceptance into the ROS-I umbrella?

[gavanderhoorn]

I would really like to hear @gavanderhoorn 's opinion regarding this. Would the actual structure be ok for acceptance into the ROS-I umbrella?

@marcoesposito1988 @carlosjoserg: I'm currently travelling, I'll get back to you some time this week if that is ok.

[marcoesposito1988]

@gavanderhoorn: sure, have fun!

On 09.06.2015 14:23, G.A. vd. Hoorn wrote:

I would really like to hear @gavanderhoorn
<https://github.com/gavanderhoorn> 's opinion regarding this.
Would the actual structure be ok for acceptance into the ROS-I
umbrella?

@marcoesposito1988 https://github.com/marcoesposito1988
@carlosjoserg https://github.com/carlosjoserg: I'm currently
travelling, I'll get back to you some time this week if that is ok.

—
Reply to this email directly or view it on GitHub
#23 (comment).

[marcoesposito1988]

@carlosjoserg, @gavanderhoorn: hope everyone had good holidays 😁 unfortunately I'm back to work already.

So how should we proceed with this?

[carlosjoserg]

@marcoesposito1988 Sorry for the very late response on this.

My suggestion here was only to not repeat launch code, and make the most of the launches available within the package. But up to you, if you think like this is better, I'll merge it rightaway.

[carlosjoserg]

Initially this PR was about how to have the launch files in the single lwr example folder so they were in accordance with the ROS-I specs, but it seems some commits that are also part of other PR's jumped in, and I don't see clearly what is what now... so I'm afraid I'm going to close it so I can merge #46, and if so, we can add the required launch files later.