PR2 URDF not loaded correctly

[akgoins]

There is an issue with how some models are loaded. For the test case of the PR2, the joint chain tree is not loaded properly and results in a rather flat looking tree.

This is what it currently looks like:

And this is what it should look like (loaded using urdf_tutorial display.launch)

[gavanderhoorn]

This seems like a duplicate of #65?

The problem does not seem limited to the PR2 model.

[pbeeson]

Actually, Issue #65 is probably a symptom of the larger problem that some URDFs are not being properly loaded.

[gavanderhoorn]

True, but I'd rather not have multiple issues documenting symptoms. #65 is essentially the first one that reported the incorrect behaviour of the application, so I'd like to propose to keep #65, and perhaps merge the contents of this one into it.

I cannot do that (github doesn't support it), so if @akgoins could repost his comments there?

[gavanderhoorn]

An update: the fact that the tree is flat doesn't affect the actual parent-child relationships between links and joints. I suspect the issue reported in the OP is caused by something else.

[pbeeson]

The problem isn't with the flat list of links, it's that the chain of
joints isn't displayed properly for urdfs with more than one chain (some
are tree some are flat). @swhart115, who is working on the drag and drop
in#48, and I have discussed this thoroughly and think we have a solution
that makes drag and drop and visualization as a flat list or tree better.
On Mon, Apr 11, 2016 at 9:48 AM G.A. vd. Hoorn notifications@github.com
wrote:

An update: the fact that the tree is flat doesn't affect the actual
parent-child relationships between links and joints. I suspect the issue
reported in the OP is caused by something else.

—
You are receiving this because you commented.

Reply to this email directly or view it on GitHub
#69 (comment)

[gavanderhoorn]

It may look like it, but there is no concept of a 'chain' anywhere in the code at the moment. It's just a name for the first default tree item.

But I'm interested to see what you guys have come up with.

[gavanderhoorn]

@akgoins: the changes in #73 should fix at least the displayed tree. No improvement for the TF issue though.

[gavanderhoorn]

@akgoins: would it be ok to close this issue now that #73 is merged? Afaict the TF problems are a separate issue, and #73 fixed the incorrect tree layout.

[gavanderhoorn]

@akgoins in #70 (comment):

The problem with the frames not showing up correctly for the PR2 has to do with the joint limits. If the joint limits are (-N,N), then the robot is visualized with the joint at 0. If the joint limit is (0,N) or (-N, 0), then the robot is visualized with the joint set to midscale. This can be seen by running roslaunch urdf_tutorial urdf_display model:=<dir>/pr2.urdf gui:=true. The gui shows some of the joint values at a non-zero start state. The TF publisher currently assumes that all joint values are set to zero. We will need to add some sort of mechanism that can set each joint to its appropriate value for correct visualization.

Which seems to be the root cause of the unexpected location of the TF frames in the PR2 model.

[gavanderhoorn]

This issue reported two problems:

1. some TF frames are in unexpected locations when viewing the PR2 model in the visualizer
2. the link/joint tree in the treeview is not structured as expected when comparing it to RViz

Problem 2 was solved with #73, but did not influence problem 1.

A likely root cause of problem 1 was found while working on #70 (see previous comment), but it's not caused by "loading the PR2 incorrectly": the urdf is loaded correctly, it's the visualisation that differs from what tools like RViz show.

I'll create a new ticket for the TF frame issue, and close this one.

[gavanderhoorn]

Continued in #100.