Is there already a good to way to avoid bizarre dependency like above? Or if there isn't, what we can do to amend this?
I thought we may want to create a sensor description package, maybe somewhere close to its driver. For example for Kinect it may be like in [freenect_stack](https://github.com/ros-drivers/freenect_stack/) (need more discussion for the specific location of course).
Also available on Gazebo are some sensors' `SDF`s, which cannot reversibly be used in ROS AFAIK. So IMO this can't be an option.
Here is the conclusion that I like from Jack O'Quin
> For most devices, I think it makes sense to distribute the foo_description as a separate package in the same repository as the foo_driver.
> * They get released together, so they remain in sync with support for new models, etc.
> * Their dependencies remain separate.
> * They can be installed on different machines, useful if the driver can run on a small headless controller.
> Of course, some generic drivers, like camera1394 or usb_cam, have no idea what the actual device looks like. There are thousands of IIDC or USB camera models. I suppose they could provide a generic box with a lens, but what's the point? That could legitimately go somewhere else.
For commonly-used sensors like the Kinect or SICK laser scanners, I wholeheartedly agree with having a description package I can install and use without needing to bring in an entire robot description.
I made a PR to `openni_camera` to add `openni_description` package. https://github.com/ros-drivers/openni_camera/pull/58. Review is welcomed.
Essentially this package only contains a xacro for Kinect. I'm afraid this setting may be a bit of overkill, but not entirely sure. Let's see.
Hi...While URDFs are a useful and standardized format in ROS, they are lacking many features and have not been updated to deal with the evolving needs of robotics. URDF can only specify the kinematic and dynamic properties of a single robot in isolation. URDF can not specify the pose of the robot itself within a world. It is also not a universal description format since it cannot specify joint loops, and it lacks friction and other properties. Additionally, it cannot specify things that are not robots, such as lights, heightmaps, etc.