Make example MoveIt 2 configuration package(s) available

[gavanderhoorn]

MoveIt 2 is non-trivial to configure.

Especially when not using ros2_control, as almost all available documentation and examples assume ros2_control is being used.

We give some hint(s) in the README (Usage - With MoveIt), but that's really rather minimal, and assumes an already working MoveIt 2 configuration package has been created, and just needs to be modified for use with MotoROS2.

Providing an example, known good configuration package would help users set up something for their own / other robots.

[gavanderhoorn]

Note: while the default would probably be Python launch files, XML based launch files are still supported, and might be easier to understand.

Python launch files can quickly become very complex, especially since they don't directly get executed, but model a declarative description of what launch_ros should start when invoked.

[ted-miller]

@aaron-levan, did you keep any of your previous work on this topic?

[Aaron-Levan]

@Aaron-Levan, did you keep any of your previous work on this topic?

No, I had everything in a VM that is, unfortunately, no longer with us...

[gavanderhoorn]

I keep putting this on my TODO, but it's too long already ..

I have working package(s) for my GP25 + TSL1000, but it's for / from a very old version of MoveIt and not really suited for distribution.

[Skoven]

Hi,

We have a GP25 in our lab that we have managed to get the MotoRos2 driver running on it. So far we don't have a working Moveit Config for it. Is there any news on this topic, or has anyone else to managed to put together their own Motoman Ros2 Moveit Configs?

Best Regards Jens Skov Damgaard

[gavanderhoorn]

Unfortunately I haven't had time to look into this yet.

It shouldn't be too much work to put something together, but as I have a basic setup working, it hasn't been a priority for me so far.

The main thing to keep in mind is ros2_control is not used at all, so the majority of the .yaml the MoveIt Setup Assistant generates relating to the driver interface will not be usable. I typically just remove it and replace it with what is needed, which is a single action server client configured with the correct joint names.

I'll see if I can dig that out and post it here later.

[drolleigh]

Hello, I have a simple moveit 2 config package for a Motoman gp25-12. I have motoROS2 successfully installed on the YRC1000 controller, and it is publishing the joint states that match the prepended group name. And it is broadcasting TFs with R1 as the namespace. The TFs appear to be accurate to the physical state of the robot.

How do I make the moveit 2 launch files talk to motoROS2 on the robot controller?

Any help is appreciated, -D

[gavanderhoorn]

We have some info in Usage - with MoveIt. Would that be enough?

Note that MoveIt will not care about TF. It ignores it completely for basic usage.

[akashjinandra]

We are more wondering, what moveit files need to be launched. With ROS 1 we had followed the example of planning execution launch that was provided by the ROS industrial group: http://wiki.ros.org/Industrial/Tutorials/Create_a_MoveIt_Pkg_for_an_Industrial_Robot?action=AttachFile&do=view&target=moveit_planning_execution.launch.txt. I'm wondering now if there is a similar setup for motoros2. The MSA(moveit setup assistant) generates many files, but we aren't sure which one to launch when running with real robots.

[gavanderhoorn]

I keep saying I'll try to make something available, but due to time constraints, I never get to it.

So I can't / don't want to promise anything, but I'll again try to look into it.

As I wrote above: the majority of the output of the MSA, at least when it comes to configuring the the driver interface can be ignored, as it's all ros_control focused.

[jimmy-mcelwain]

I've been working on this the past few days. I have a mostly functional package for my GP12. I will continue working on it and upload a draft hopefully early next week. Would that be something that should be pushed to a new branch on this repo? Or should I put it elsewhere? I am using the support package from here with a few small edits (prefix and joint names)

[gavanderhoorn]

Would that be something that should be pushed to a new branch on this repo?

no, it's not related to the driver so we should not host it here.

I'd suggest creating a repository for it on your personal account for now. Then after we test it, we can transfer it to yaskawa-global and reference it in our documentation.

[jimmy-mcelwain]

I have a some questions for you @gavanderhoorn.

Earlier I was running into a problem where MoveIt2 wasn't working because there was no defined transform between world and base_link. So I created a mock /tf_static publisher in the launch file that published all zeros for the world -> base_link transform and got it working, but I am trying to find a real solution before I post anything here.

My problem is that in /tf, we are publishing world -> base, base -> flange, etc. and we have no way to locate base_link within MotoROS2 to my knowledge, particularly since the urdf files that define that transform are not being stored in an accessible place.

According to your documentation, the frame hierarchy should be like this, base should be a child of base_link but I don't see any way to link world -> base_link. In reality, we are calculating everything from base, but having that be the parent of base_link breaks convention.

Maybe more notably, the documentation says here that base must be fixed to it's parent frame. But since we are publishing a non-fixed world -> base and not world -> base_link and base_link -> base, it seems like that rule is being broken already.

I wish that I could have a hierarchy like world -> base (non-fixed), base -> base_link (fixed), base_link -> link_1(non-fixed), etc., but that is apparently not allowed. What should I do here?

[gavanderhoorn]

Just making sure we're talking about the same things: the base frame described in the candidate REP you link is not Yaskawa's Base frame.

As to the TF frames published by MotoROS2: those don't get used by MoveIt.

Where does world come from? Is it a link in a URDF / XACRO you're using? It's not part of any of the models I'm aware of.

I wish that I could have a hierarchy like world -> base (non-fixed), base -> base_link (fixed), base_link -> link_1(non-fixed), etc., but that is apparently not allowed. What should I do here?

can you clarify why you wish you could have that frame hierarchy?

[jimmy-mcelwain]

I believe that I misunderstood the way that external axes are handled in MotoROS2, so you can ignore part of what I said. I had an unnecessary world -> base_link virtual joint in my srdf. I thought that we would need to read the world -> base TF that was being published in MR2 to position the robot (essentially a transform from Yaskawa base frame to Yaskawa robot frame). But now I have been told that external axes will be included in the urdf and essentially treated as part of the robot. But I still have concerns/I am uncertain how to do some things.

I have an updated version of my package here. I slightly changed the urdf from your repo to update the naming convention so joint_1_s -> group_1/joint_1 and link_1_s -> group_1/link_1 so it will be a bit easier for users who stick with the default joint names in MR2 to deal with, but otherwise it should work with the motoman_gp12_support and motoman_resources packages from your repo. I am able to move the robot using MoveIt2 by setting joint angles and executing motion in Rviz.

My first problem is that I am getting a error in Rviz when I open it through my launch file. When I run

ros2 launch motoman_gp12_moveit2_config demo.launch.py

I get

Frame [group_1/base_link] does not exist under Global Status: Error > Fixed Frame

If I go to Global Options, the only available Fixed Frame settings are those published on TF (e.g. world, r1/base, r1/flange, etc.). If I create a static transform world -> base_frame in my launch file, the error goes away. Here is an example of another launch file that does this. To be clear, it still moves properly if I set joint angles even if the error is active.

Another concern is that if I look at the position of tool0 in Rviz, it is offset by 0.45 meters in the z direction (the distance between base_link and base) compared to how it appears on the pendant. Additionally the orientation of tool0 appears to be incorrect, though I may just be reading it wrong. I was wondering if that would be problematic if a cartesian position is commanded.

Some of these problems may be Rviz configuration problems, I am not sure. I know that the moveit.rviz on my repo gets immediately "outdated" upon launching it. I'll keep on looking into the problems, but if you have any suggestions please let me know. Thanks.

[jimmy-mcelwain]

I had a misunderstanding regarding robot_state_publisher. I found this discussion comment by you @gavanderhoorn which cleared things up for me. Like the author of that discussion, I thought that robot_state_publisher was unnecessary. I thought that it was part of ros2_control, and since we are publishing robot_status that we didn't need it. I should have looked more into it and realized that robot_state_publisher is unrelated to robot_status.

I have since updated my repo and I now have a robot_state_publisher node in my launch file. This clears up many of my problems. I also added a warehouse_ros_sqlite configuration which at least stores robot states properly.

My only real concern at this point is that the position of tool0 in rviz is 0.45m off in the z-direction. I know that this is because rviz is describing the position relative to base_link and not base, but it could be a little confusing and could perhaps cause problems.

Here is my repo. I'm going to write instructions on how to configure the repo for different robot models. I am also not planning on hosting the motoman_gp12_support or motoman_resources on that repo in the future. But for now I think that the contents of motoman_gp12_moveit2_config are ready.

[jimmy-mcelwain]

I have an example package for both GP12 and HC10DTP and a pretty detailed setup guide at jimmy-mcelwain/motoros_moveit2_config_packages. I have never written a MoveIt config package, so if somebody could take a look and see if it is good, I would appreciate it.

Also, I know that the old ros-industrial/motoman repo had the support and config packages in the same repo. Is that something that we want to have again? Or should we host the support and config packages in separate repos? If we want separate repos, do we want to just host one 'example' config package? Or should we host more config packages as they come up?

[ted-miller]

@jimmy-mcelwain I'll plan to go through your readme on Monday.

Also, I know that the old ros-industrial/motoman repo had the support and config packages in the same repo. Is that something that we want to have again? Or should we host the support and config packages in separate repos?

Personally, I don't see any reason to separate them.