Are we concerned about tf performance about marine_ros_conventions_discussion HOT 5 OPEN

As I understand it, tf2 introduced static transforms to improve tf tree performance (based on the roscon talk on tf2). For dvl/adcp beams or sensors in fixed positions, the load due to tf2 should not be very high, since they would only be latched once at the start of the node. Sensors like a mechanical scanning sonar with a tf for the scan angle could be more of a concern.

I haven't used tf2 extensively yet, so I have not run into problems. Does anyone have further experience to add?

from marine_ros_conventions_discussion.

So we have used tf2 extensively with Sentry. Static TFs improve performance of the TF tree, but still use the same API-- in particular, there's no way to get a fully-static TF without connecting to all the dynamic TFs.

More importantly, adding a TF frame per beam just gets confusing. A Reson 7215, requires adding several hundred TF trees. Even if the computational overhead is reasonable-- not to mention memory use-- that becomes a pretty major complexity overhead on developers. We've generally adopted the convention of "1 instrument frame per sensor" to try and manage that complexity creep.

We probably also need to be clear on what should get a TF vs. what should use a pointcloud. Presumably these discussions have happened before with various laser sensors.

from marine_ros_conventions_discussion.

In the current suggestion, planar multibeam sonars have a single tf and an angle relative to the zero position of the multibeam tf (similar to the existing LaserScan.msg). The message assumes that rotation only occurs around one axis, and thus the position of a single beam relative to the sensor frame can be conveyed through a simple enough text description that can be included in a standardized message. A clear order for enumeration in an array exists.

For ADCP,/DVL, and possibly also multibeams that don't have all beams in the same plane I am not aware of a message that could be used as a reference. For point cloud, the polar data would need converting to cartesian. Do point clouds make sense in the case of a whole profile of return intensities or velocities? Which sensor data may need analyzing on a per beam basis further down the line? Are there any other sensors where this question may come up?

from marine_ros_conventions_discussion.

Good points. I go back to this question of "what we're trying to solve." I concur that pointclouds don't make sense in the case of profiles. It's literally another issue, but that sounds like a pretty solid argument to split profiling sonars that return a geometry from imaging sonars that return images.

Incidentally, we have some message types for sidescan and others I'd like to throw up as an example. What's the preferred way to do that?

from marine_ros_conventions_discussion.

Incidentally, we have some message types for sidescan and others I'd like to throw up as an example. What's the preferred way to do that?

An immediate solution would be to create an issue to discuss them, and link the message type (assuming it is in your public repo). Otherwise, since this is a repo directly for development of messages, I think directly adding alternative messages or new messages for discussion would be good.
It appears I don't have the rights to add you to this repo, I just emailed @narcispr for this.

from marine_ros_conventions_discussion.