No joint properties displayed for "non-Chain" joints

[pbeeson]

Some URDFs (actually most all I've tried) seemed to have their joints either grouped as a Chain by urdf_editor or not. Those that do, have thier joint properties show up, those that do not have no joint properties.

So there are (related) two issues here: 1) Some joints aren't being found in Chains. 2) Those joints are listed at the top level of RobotModel on the left tree structure, and are not displaying joint properties.

On item #1, how/why exactly are "Chains" being deduced? Chains are an SRDF convention, but not a URDF convention. However this is being done, it does not seem to be correct.

On Item #2, this probably goes away if Item #1 is appropriately handled.

An example with the Jaco arm URDF is below (the seeming pause in the first half of the video is because the window recorder ignores the file select popup).

https://www.dropbox.com/s/kuyblyjq9kimeoc/Screencast%202016-04-05%2010%3A42%3A23.mp4?dl=0

[gavanderhoorn]

I've seen this as well, just hadn't had time to report it with a procedure to reproduce. It's an issue on urdfs where there are branches in the tree starting from the base_link, such as on robots with parallel links (which use mimic joints, obviously).

As to how chains are deduced: @Levi-Armstrong, can you comment?

[pbeeson]

@Levi-Armstrong In another project, I just got through creating a large URDF/SRDF parsing class. I can offer help on this if needed.

[gavanderhoorn]

Additional note: on urdfs where this happens, the 'out of chain' joints also don't get cleaned up after loading another urdf, or clicking New.

[pbeeson]

In PR#59, link transforms still show in 3D window after clicking New too. I think 'New' no longer cleans up well. One fix submitted via PR #67 stops seg fault on New but shows behaviours above.

[pbeeson]

@Levi-Armstrong because of the above URDF issues, the one uncovered by #69, and the ones discussed in #26, I think it's clear that the parsing or transformation into local data structures needs some work. I will be at SRI in Ca this week but might have time in the evenings to try and apply my urdf parsing knowledge to this problem to fix the current issues above. #65 is probably starightforward. #65 is probably a bit more work to handle tree urdfs with lots of branches. #26 might be the biggest change in that it was agreed that links are probably the best way to show a tree, not joints. I'll know more when I look into it. If you have time this week to tackle any of this, let me know and I'll defer to you if needed.

[gavanderhoorn]

I have a proposal deadline to make, but I'll fix some of the outstanding issues tonight (my tonight).

The parsing is actually quite alright, it's just the TreeView that doesn't get populated properly. Ideally I'd like to use a more MVC approach, and we might end-up with that, but for now I've got some fixes for the TreeView and some other (minor) issues that should bring things to a workable state.

The above is the bulk of #69. The TF PR (#70) will probably not gain a whole lot from fixing #69: parsing the urdf is actually done by liburdfdom, which should be able to deal with even complex urdfs like the PR2. There is currently no custom parsing code in the application, just some object translation and the parent-child relationships are still maintained in the URDF data model, so #70 should (and does) use them from there. Parsing them into properties does not change these, so I'm pretty certain there is something else going on which will not be changed by fixing #69.

As to #26: that is difficult right now as the UI doesn't properly show the tree structure. Once that is merged in (I have the code ready) it should be a lot simpler, although dealing with the underlying data structure(s) won't be.

[gavanderhoorn]

One more comment: I can actually understand why @Levi-Armstrong chose to list all links in a flat list: for large models, using an actual tree structure will quickly cause the tree to run out of space, and you'll spend a lot of time opening and closing subtrees.

A flat list is actually pretty ok to work with, although it doesn't represent the tree structure very well (and thus makes things like #26 hard to do).

[gavanderhoorn]

@pbeeson: would it be ok to close this issue, now that #73 is merged?

The tf issues (also reported in #69) seem to be separate issue.

[pbeeson]

Yes.

[gavanderhoorn]

Thanks 👍.