search

gkjohnson / urdf-loaders

URDF Loaders for Unity and THREE.js with example ATHLETE URDF Files open sourced from NASA JPL
https://gkjohnson.github.io/urdf-loaders/javascript/example/bundle/index.html
Apache License 2.0
469 stars 121 forks source link

Add support for floating, planar joint types #281

Closed EzraBrooks closed 2 months ago

EzraBrooks commented 9 months ago

Closes #8

WIP, need to add an example (and debug any issues said example ends up having)

EzraBrooks commented 9 months ago

I'm headed out on vacation for a week but handing this branch over to my team for testing with mobile bases, so hopefully there'll be a good example case soon to iron out any bugs and showcase the capability here :)

gkjohnson commented 9 months ago

I'm headed out on vacation for a week but handing this branch over to my team for testing with mobile bases, so hopefully there'll be a good example case soon to iron out any bugs and showcase the capability here :)

Sounds good - once the PR is marked as "ready for review" I can provide comments!

EzraBrooks commented 8 months ago

sorry for the wait here; we're still working out some issues with the backend we were going to use this with! will get this finished up as soon as I have it working for us :)

Abishalini commented 8 months ago

@gkjohnson Would it be okay to add the rotational component for the planar joint? Adding this here for more visibility - https://github.com/gkjohnson/urdf-loaders/pull/281#discussion_r1542174640

EzraBrooks commented 3 months ago

Hi Garrett, we've decided to stay the course on 3DoF planar joints, which is what ROS expects (even though I agree with you that it's kind of a silly expectation). I'm closing this PR in favor of our fork. Thanks so much for your work on this library and for your help along the way!

gkjohnson commented 3 months ago

@EzraBrooks was there a blocker on updating the URDF spec? From some links you've sent before and other references I've seen since it does look like planar joints do generally (for some reason) include a third twist component and I think I've come around a bit since previous discussions. I'm just trying to reconcile the differences in the spec with how people are using things (which is the more important piece). It's unfortunate that parts of interchange documentation get left behind while software changes are made to get something working but it is looking like the documentation is the "wrong" thing here.

gkjohnson commented 2 months ago

I'm going to go ahead and merge this rather than contribute to the fragmentation I'm seeing in the community - I'm seeing that the spec is likely not the "source of truth" in these cases but rather an afterthought, unfortunately. Likewise the current implementation is structured so that the X, Y translation are the first arguments so the function will ignore the rotation component meaning it will work in either case.

Sorry for the delay in coming around on this.

gkjohnson commented 2 months ago

Just published in v0.12.2