SHARE
TWEET

Untitled

a guest Feb 23rd, 2019 69 Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  1. Regarding the SDF frame semantics, I have some thoughts based on my ongoing work in creating a dartsim plugin for ign-physics. We might want to consider a tweak to the frame URI scheme.
  2. Instead of:
  3. # Link in the same model
  4. ../link/link_name
  5.  
  6. # Link in a different model
  7. /model/model_name/link/link_name
  8. we could have
  9. # Link in the same model
  10. link://link_name
  11.  
  12. # Link in a different model
  13. link://model_name/link_name
  14. This extends pretty nicely to other types, for example collision objects:
  15. # Collision object in the same link
  16. collision://collision_name
  17.  
  18. # Collision object in the same model
  19. collision://link_name/collision_name
  20.  
  21. # Collision object in a different model
  22. collision://model_name/link_name/collision_name
  23. The scheme for visual would be the same as collision, and the scheme for joint would be the same as link.
  24. We would know which field in the URI refers to what type of name, because each type scheme (link, joint, collision, etc) has a pre-defined depth within the hierarchy of entity types.
  25. I think this would give users the following advantages:
  26. They don't need to worry about the distinction between a prefix of "/" or ".."
  27. They don't need to mix types and names within the URI scheme, which (at least to me) feels inconsistent and confusing
  28. In many (all?) cases, the URI will be shorter
  29.  
  30. Then on the API side, instead of just passing along this string, it would be helpful for developers if we provide an API that says:
  31. What type of object is being referred to
  32. A vector of strings where each element is the name for a progressively deeper level of the scope
  33.  
  34. We could also consider having some special schemes. For example:
  35. # Refer to the parent joint of the current link/joint (might be ambiguous in some model structures)
  36. parent://joint
  37.  
  38. # Refer to the parent link of the current link/joint/collision/visual (for links and joints, this might be ambiguous in some model structures)
  39. parent://link
  40.  
  41. # Refer to the parent model of the current link/joint/collision/visual
  42. parent://model
  43.  
  44. # Refer to the child joint of the current link/joint (this might be ambiguous in some model structures)
  45. child://joint
  46.  
  47. # Refer to the child link of the current link/joint (for links, this might be ambiguous in some model structures)
  48. child://link
  49.  
  50. # Refer to the world frame. Note: there's no need for ://
  51. world
RAW Paste Data
We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the Cookies Policy. OK, I Understand
 
Top