-
Notifications
You must be signed in to change notification settings - Fork 132
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactoring sensor parsing #84
base: master
Are you sure you want to change the base?
Conversation
This PR goes along with ros/urdfdom_headers#22. |
83b7de4
to
8546aa0
Compare
8546aa0
to
1f913ce
Compare
1f913ce
to
c5a59f0
Compare
c5a59f0
to
5445b12
Compare
@scpeters @clalancette Would be really great to get some feedback on this nearly two-years-old PR - I just rebased nth time. |
- According to http://wiki.ros.org/urdf/XML/sensor, the parent's link name isn't an attribute 'parent_link_name', but an attribute 'link' in the <parent/> element - Gracefully handle missing <parent> element (instead of segfaulting)
- moved function declarations into new header files (instead of repeating them in .cpp files) - export symbols of link.h and pose.h - and install those files as well (to be re-used by other software)
- parse sensor-specific content with a SensorParser (extension point) - implemented parseCamera() and parseRay() as SensorParsers (in visual_sensor_parsers.*) - added unittest test_sensor_parsing
5445b12
to
c704f3f
Compare
@clalancette, another 2.5 years passed w/o progress on this. Is there any chance this can get merged? |
Move basic attribute parsing routine to utils.h
This is required for parsers loaded via pluginlib to avoid premature unloading of the lib.
c704f3f
to
998df17
Compare
This PR is an attempt to rework sensor parsing towards more modularity as requested e.g. in #28. My guidelines were the following (according to the previous discussions in #82 and #28):
udf::ModelInterface
. Particularly, I didn't put the list of parsed sensors into that data structure as suggested in use SensorBase class as base class for sensors #28. The rationale is the following: TheModelInterface
defines the kinematic structure of the robot, which is kind of universal and doesn't require specific data types (other than the existing ones) to describe it. On the other hand, there is a whole universe of sensors out there, each requiring its own data type and parser. So sensors are obviously highly domain-specific and we will need a plugin concept to handle them in a generic fashion.<sensor>
tags in the URDF. This generic parser handles common fields as defined in the originalSensor
class. In order to handle the multitude of potential sensor descriptions, I propose to pass application-specific sensor parsers to that method via a map from sensor type to the associated parser instance.pluginlib
mechanism of ROS. However, asliburdfdom
should be ROS-agnostic, corresponding functions are provided in theurdf
package only (Sensor parsing urdf#5).<sensor>
. This maintains backward compatibility to potentially existing ray and camera sensor descriptions:<sensor>
tag.identical
sensor type names in the future, we might need a mechanism to explicitly specify a parser from a specific package.Accordingly, these commits:
VisualSensor
toSensorBase
(previously only two sensor types could be handled, camera and ray).parseCamera()
andparseRay()
functions into appropriate parser classes, derived from a new interface class,urdf::SensorParser
.