Recommend Topic and Frame Names and Namespaces for AVP
The following discussion from !160 (merged) should be addressed:
-
@cvasfi started a discussion: (+9 comments) If we use matching topic names, then same param file can both be used for the simulation and real data replay. However there's an incompatibility issue here in regards to the frames :
I think this is incorrect semantically for the time being. The velodyne node currently has some inline transforming that it does, putting things into the
base_link
frame. (!160 (comment 291127151))The ground classifier expects points in a z-up frame, which is sort of what
base_link
gives, but there are absolutely no guarantees fromvelodyne_front
. !160 (comment 291127123)So the issue is that most of the applications are set to operate in
base_link
frame and don't have any internal/external logic to apply static transforms from the urdf file to adjust their data. This should prevent us from using the same config file in multiple places.I see few possible solutions/workarounds:
- Set the lgsvl sensor configuration to output point clouds in
base_link
frame by adjusting the transform part. - Create one set of parameters for using velodyne nodes and another set of parameters solely for simulations.
- Implement a node that transforms the point clouds to a common frame.
Thoughts?
- Set the lgsvl sensor configuration to output point clouds in
Outcomes from the online meeting with @esteve, @christopher.ho, @gowtham.ranganathan, and @JWhitleyWork:
-
Create document providing guidelines and recommendations for topic and frame naming and namespacing !196 (merged) -
For sensors used in the AVP demo, implement the topic and namespacing recommendations #333 (closed) -
For the lidar perception pipeline used in the AVP demo, implement the topic and namespacing recommendationsWill be done as part of integration testing. -
For the lidar localization pipeline used in the AVP demo, implement the topic and namespacing recommendationsWill be done as part of integration testing.
Given that the perception pipeline already uses base_link
as the common frame and that all nodes in the perception pipeline currently assume a common frame for incoming lidar data, wait for the implementation of #328 (closed) which will be used on each of the lidar inputs to transform them into base_link
prior to fusion. This decision can be re-visited at a later date if computational load or other factors become problematic.