tool0: ROS-I vs industrial controllers (discussion)

[gavanderhoorn]

The tool0 frame is supposed to provide a standardised point of attachment for urdfs describing tools [1]. According to @shaun-edwards, the original intent of the text in [1] was to align the urdf tool0 frame with the toolframe of the actual robot (ros-industrial/abb#32), which should result in the base_link->tool0 transform to be equal to the values the robot controller reports (in cartesian world coordinates).

It appears not all urdfs (and corresponding xacros) have been setup like this (see @Samsagax in ros-industrial/abb#31 and ros-industrial/fanuc#54 fi).

Three possible options for dealing with tool0 links:

1. ignore any toolframes on the controller (just attach tool0 with a (0, 0, 0, 0, 0, 0) frame to the previous link)
2. add additional frames (as suggested in ros-industrial/abb#32) to keep with ROS(-I) guidelines regarding frame orientation [link to guidelines needed]
3. just orient every tool0 such that they align 100% with the toolframes of the respective manipulators (in a default setup; custom toolframes will always require updated urdfs)

An additional (but related) issue is the discrepancy between the origin of the World Coordinate frame in many industrial controllers (often at the intersection of the first 2 axes) and the origin of the coordinate system attached to a robot in a urdf (which is often at the bottom of the base_link).

The goal of this issue is to gather opinions about possible solutions and to arrive at a clear guideline which can be used to update existing urdfs, as well as to make sure that future contributions avoid the same mistakes.

[gavanderhoorn]

Personally, I prefer option 3. It incurs the least amount of overhead (no additional frames), is the least confusing (only one tool0, and it is identical to the default toolframe of the real manipulator) and in combination with a properly located origin of the base_link this would allow a 1-to-1 correspondence between ROS transforms and data from the industrial controller.

Issues with backwards compatibility can be addressed by exploiting the tick-tock approach (deprecate in release X, remove in release Y).

[Samsagax]

As @gavanderhoorn said I would go for the 3rd option. As an intermediate solution (In favor of deprecating then removing) I would add that additional frame so there is a version of the manipulator's URDF that always match the controller frames.

For the base problem I would take the same approach: add an additional base link corresponding to the attachment of the robot to the ground. I know ABB robots always had the same configuration for frames, the world, base and wobj0 are set (in the default setting) to the center of the circle on which mounting screws are, and it's coincident with the first axis.

The advantage of having always a coincident frames between URDF and controller is (besides less confusion) that it will allow to synchronize frames in the controller with ROS nodes (let's say we can correct a Work Object in the controller with a sensor data), and use the controller capabilities in some way, for example adding support for some force control loop.

@gavanderhoorn the link is: http://wiki.ros.org/Industrial/Tutorials/Create%20a%20URDF%20for%20an%20Industrial%20Robot#Prepare_CAD_Models there is a suggestion to that guideline when creating CAD models.

[gavanderhoorn]

@Samsagax wrote:

For the base problem I would take the same approach: add an additional base link corresponding to the attachment of the robot to the ground. I know ABB robots always had the same configuration for frames, the world, base and wobj0 are set (in the default setting) to the center of the circle on which mounting screws are, and it's coincident with the first axis.

For Fanuc I've been adding a wc_link in between the base_link and link_1, placing the origin of joint_1 at the proper distance of that wc_link. The transform between wc_link->tool0 then gives me the exact same translation and rotation for the EEF as the controller (taking any user- and toolframes into account, and provided all other joint transforms are correct).

[shaun-edwards]

I'm in agreement with option 3. All URDFs should have a tool0 that exactly matches the robot tool0(in pose). As for backwards compatibility, we can approach it on a case by case basis (there aren't too many bad cases out there). For example, in the case of ABB, the URDF's will be replaced with the new directory structure and naming conventions. As part of this change (post Hydro), we will update the tool0's. As we did with the motoman meta-package, the old URDFs (with the wrong tool) will remain for a single release, (thus remaining backwards compatible). If we would like to add special tool0's to these legacy URDF's, I'm OK with that, but it won't be a priority. The worst case would be when a package adheres to the new directory structure and has an incorrect tool0. In this case, we should probably correct the tool0 (creating minor headaches for those with existing systems) and add a legacy_tool0, so that they can easily update their code to either the new frame orientation (preferred) or search and replace with the legacy tool0.

As for a standard 'base' frame I think this is also important and we should stick with nomenclature that is similar across robots. As @Samsagax said, their is typical 3 frames:

• base - this varies across controllers, but is somewhere close to the base of the robot. This is important to represent in our URDF
• world - for most systems this is typically the same as base. Only in multi-robot systems does this typically change. Since our URDFs are limited to single robots, we shouldn't have to worry about this frame
• object - for most systems this is the frame in which most robot points are taught. This is independent of robot geometry and doesn't have a place in the URDF.

So, the only important frame is base. Can we come up with a common name for this?

@gavanderhoorn, why did you choose wc_link?

[gavanderhoorn]

@shaun-edwards wrote:

So, the only important frame is base. Can we come up with a common name for this?

@gavanderhoorn, why did you choose wc_link?

well, base_link already carries a special meaning in ROS, so that cannot be used (well we could, but it would involve some fiddling with the Z-coordinate of link_1, as base_link is supposed to be on groundlevel AFAIK).

wc == world coordinate, as Fanucs use a world (your base), user (your object), tool (which seems to be missing from the list) frame hierarchy. I added the wc_link to some robots, which allowed me to do tf_echo wc_link tool0, giving me the transform to my EEF in world coordinates.

I've only done this locally, so I can easily implement whatever we agree upon.

[shaun-edwards]

How about base0. This would imply that it is related to tool0 (in this case, the tool0 position in base0 is what is reported by the robot).

[gavanderhoorn]

base0 could work, although it implies that there can be a base1. Most robots cannot change the base frame, so there can't be a base1. I'm a bit low on inspiration right now, what about just using base?

Another alternative might be a little closer to what @Samsagax suggested: add some kind of indication that those links / frames are manufacturer specific. I'm not suggesting we should actually pre/suffix the mfg name, but we might name the frames such that it is clear that they are not some random addition 'by us'.

Perhaps something like mfg_base, mfg_flange (although base is a coordinate origin, and flange is an actual phyisical entity). Any tool frames defined on the robot controller could then be attached to the mfg_flange (which would otherwise be between tool0 and any eef link).

[shaun-edwards]

I'm hesitant to prefix with mfg, since it would imply that tool0 should also be prefixed. It sounds like we can agree on a common name of base.

Originally I thought something called flange would be useful for easily swapping end-effectors between robots (assuming an orientation convention), but it turns out in practice that most flanges are different and thus require an adapter plate. The addition of the adapter plate alters the geometry enough that every flange to end-effector transform ends up being different. For this reason, it doesn't turn out to be that useful. It just turns out to be an unused transform.

[Samsagax]

Maybe we should stick to naming conventions on each manufacturer. For example: all tools in any ABB manipulator is a transformation with respect to tool0 and the base frame is called Base and is not movable (at least isn't moved from it's default in practice).

[shaun-edwards]

I'd like to avoid manufacturer specific names. Frame names are pervasive in code/parameters. If we use manufacturer specific names then it will make it harder to port code between different vendors.

[gavanderhoorn]

@Samsagax: as @shaun-edwards mentions, we should avoid adding in mfg / model specific names at all costs, as that would completely remove the benefits of using abstractions in the first place.

I do think though that it might make sense to consider tool0 as the 'flange' of sorts: any actual tool frames (as defined on the controller), would be transforms from tool0 to the actual TCP. That is why I suggested removing the 0 suffix.

[gavanderhoorn]

@shaun-edwards wrote:

I'm hesitant to prefix with mfg, since it would imply that tool0 should also be prefixed.

Well yes, that was the idea. As both of these frames are determined by the manufacturer (ie: at design time) and cannot be changed by users (the tool0 frame would then be at the flange position fi, in any case always the starting point for an actual - controller - tool frame).

It sounds like we can agree on a common name of base.

Not sure, base is a bit vague. Base of what?

Originally I thought something called flange would be useful for easily swapping end-effectors between robots (assuming an orientation convention), but it turns out in practice that most flanges are different and thus require an adapter plate. The addition of the adapter plate alters the geometry enough that every flange to end-effector transform ends up being different.

Exactly, which is what toolframes are used for, AFAIK. If something like a flange would exist, a sufficiently detailed URDF of an actual tool could actually be used to derive the flange->TCP transform, which could then also be used to setup a toolframe on the controller itself.

[shaun-edwards]

We could add the prefix mfg to tool0 and base but would create a lot of work to port these changes to existing URDFs and keep things backwards compatible. My preference is to stick tool0 to avoid this work. This would also mean sticking with the somewhat ambiguous base name.

I'm not sure how realistic it is to derive a transform from URDF geometry. Furthermore, TCP transforms are not necessarily from the flange. Some are relative to the spherical wrist intersection of the last 3 axes.

[gavanderhoorn]

@shaun-edwards wrote:

We could add the prefix mfg to tool0 and base but would create a lot of work to port these changes to existing URDFs and keep things backwards compatible. My preference is to stick tool0 to avoid this work. This would also mean sticking with the somewhat ambiguous base name.

While backwards compatibility isn't too difficult, I see your point with the added work.

Out of curiousity then though: why does tool0 have the 0 suffix right now? Was it intended to allow there to be more than 1? And: why not base0 then?

I'm not sure how realistic it is to derive a transform from URDF geometry.

I'd say it is certainly possible, especially if the URDF was created based on something like a solidworks assembly. It would probably need some kind of extension to the URDF model, or some special link / joint though. But it wasn't meant as a justification, just something I thought of.

Furthermore, TCP transforms are not necessarily from the flange. Some are relative to the spherical wrist intersection of the last 3 axes.

Sure. But I'd expect tool0 to be relative to that as well then. Otherwise having the link doesn't make much sense either.

[shaun-edwards]

Out of curiousity then though: why does tool0 have the 0 suffix right now? Was it intended to allow there to be more than 1? And: why not base0 then?

Most robots have several tools that can be defined. Tool0 is the default and I wanted to allow people to add (via xacro) their customized tool frames as well while still being able to compare them to tools stored on the controller. As for base, there can be more than one base frame, but they typically call them object frames. The difference between tool and base/object is really just the side of the kinematic chain the frame happens to be on.

[gavanderhoorn]

Most robots have several tools that can be defined.

Ok, as I assumed. I mentioned a common flange as that is where for Fanuc fi the toolframes are relative to.

As it seems we won't get any more contributions, lets vote on the use of base.

To clarify, this would then be a frame between base_link and the first link of the actual manipulator.

[shaun-edwards]

I think it should be relative to base_link, but should we require it to be in between? Does it make a difference? What if link_1 was still relative to base_link?

[gavanderhoorn]

It would seem to me to be the most logical place for it: then you can do transforms from base -> tool0, which would give you the 'world coordinates' of the toolframe. A transform between base_link and base would give you the distance between the mounting point of the robot and the origin of its coordinate system.

As for the actual transforms themselves: it doesn't matter, but the resulting structure (ie: from base to tip) would be more intuitive if it didn't first go back to base_link, then up to tool0.

[Samsagax]

Wouldn't it be easier just to put the base_link as it is in the controller? We would avoid duplicity in that case, as most robots have their base coordinate system aligned with the first joint and translated only in one direction (this is true for ABB manipulators at least)

Joaquín Ignacio Aramendía

[gavanderhoorn]

@Samsagax: that was the initial idea, problem is that ROS (at least in some parts, and AFAIK) implicitly assumes that base_link is the link of the robot with 'the world'. This to me is a conceptual issue: the origin of the coordinate system is not at groundlevel.

Additionally (more of a practical thing): to make the base_link -> tool0 transform identical to the carthesian pose reported by the controller would require changing the link length between base_link and link_1. This would require us to update all origins of the visual and collision elements.

[Samsagax]

I would preffer the effort of changing the frames once than the clutter of having 2 transformations with obscure names. It would add to the manipulator agnosticity also. I volunteer to do part of the work if that is the case.

[shaun-edwards]

If only every robot vendor put their base frame in a logical spot. I believe the fanuc frame (the reason we started this discussion) is at the intersection of the first two joint axes. Actually this makes sense from a robot DH parameter perspective, but not from a building up a URDF perspective.

base_link is typically positioned at the logical position. There is a good reason to keep it where it is. Also, from a backwards compatibility standpoint, moving the base link would break a lot of URDFs that use that frame.

[gavanderhoorn]

@shaun-edwards: correct on the location of the base frame (and the DH relation). +1 on the base_link as logical position.

[Samsagax]

Really it doesn't matter where the base frame is as long as the manipulator transformation matches the ROS transformation. So we must put both base_link and tool0 exactly as the manufacturer defined them. We can then add as many work/tables/bases as we want. Maybe the ROS infrastructure should account for that flexibility or it will never launch as a real industrial solution. I'm whiling to contribute hard to that effort if I'm able to.

Joaquín Ignacio Aramendía

[shaun-edwards]

To come to some conclusion on this, here is the summary:

• Requirements:
  • tool0 shall match exactly the tool0 defined by the robot controller
  • base shall match exactly the base defined by the robot controller
  • base_link shall be positioned in the logical base position (oriented by convention, z-axis up, x-axis forward)
  • The transform between base and base_link can be defined in any way, as long as the transform is fixed between the two (i.e. not across a movable joint). The preference is for the base to be defined relative to base_link
  • The transform between the last robot link and tool0 can be defined in any way, as long as the transform is fixed between the two.
• Optional:
  • The MoveIt kinematic chain should be defined between base_link and tool0 (to match legacy configs). In reality MoveIt and any other packages should be able to perform the appropriate transformations between reference frames

[Samsagax]

+1. Excelent @shaun-edwards

[gavanderhoorn]

@shaun-edwards wrote:

• tool0 shall match exactly the tool0 defined by the robot controller

In orientation as well as position.

• base_link shall be positioned in the logical base position (oriented by convention, z-axis up, x-axis forward)

Being the at the 'bottom' of the first mesh.

• The MoveIt kinematic chain should be defined between base_link and tool0 (to match legacy configs). In reality MoveIt and any other packages should be able to perform the appropriate transformations between reference frames.

So it doesn't necessarily have to be part of the kinematic chain?

[shaun-edwards]

• The MoveIt kinematic chain should be defined between base_link and tool0 (to match legacy configs). In reality MoveIt and any other packages should be able to perform the appropriate transformations between reference frames.

So it doesn't necessarily have to be part of the kinematic chain?

I don't think we should make this requirement unless there is a good reason. I can't think of any.

[shaun-edwards]

The results of the discussion have been added to the tutorials (urdf and moveit config). Thank you @gavanderhoorn and @Samsagax for your comments.