search

tue-robotics / ed_navigation

ED interface to the base navigation modules
2 stars 4 forks source link

rgbd plugin should not be a plugin #29

Open PetervDooren opened 2 years ago

PetervDooren commented 2 years ago

@ar13pit and @MatthijsBurgh, I would like to pick this up and turn this functionality into something like http://wiki.ros.org/depthimage_to_laserscan except: user can specify in which plane their virtual laser exists User can specify a range of heights which will read as a laser point.

I think this would also need to be separated from the rgbd interface to be more accessible

What are your thoughts on what this unit should contain?

MatthijsBurgh commented 2 years ago

As we are working to reduce (de)serialization it should either be a nodelet or work with RGBD. I think it should be possible to create both interfaces. In which we can use the nodelet on the robot and the RGBD client in simulation.

When using a laser message, a lot of more calculations are needed. As you need to calculated the origin of the virtual sensor. Which should be able to reach all desired points. So one point can not occlude another point. Also you will need to publish the frame as well. I think this is an undesired change.

User can specify a range of heights which will read as a laser point.

What do you mean with this one?

PetervDooren commented 2 years ago

The main reason I would advocate for a ROS topic interface for this thing is to make it more accessible to other users. We can of course still make a nodelet and an rgbd interface for it.

A laser message does indeed come with some more complications. publishing another frame does not bother me much, but there is indeed the question of whether points can obscure eachother. We could keep the pointcloud interface we have now. The thing I like about the laser message is that you keep the semantics of which points are next to eachother, and where the center of the sensor is, which will inform you of the blind spots in your data.

With specifying the height I mean that currently we are able to specify a minimum z height to filter out the floor. Essentially we only consider points with a height between 0.2 and infinity. I would allow users to also set the upper bound here.

MatthijsBurgh commented 2 years ago

The nodelet would use the ROS topics. But by running it as a nodelet, you eliminate some (de)serialization. The nodelet could be wrapped to get a standalone node.

Setting a max height is indeed a good idea.