Ask Your Question
0

What is up with the PointCloud msg type?

asked 2020-11-04 09:11:53 -0500

Hakaishin gravatar image

There was ROS, with PointCloud, then they added PointCloud2 which I don't understand why add a version number into a single message, it's not been done for other ones. Now we have ROS2, and I would assume we have PointCloud? But it seems it is still PointCloud2? Wasn't the switch to ROS2 a chance to leave the version number out of the messages? So is the normal pointcloud type in ROS2 PointCloud2? As it was in ROS?

edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted
0

answered 2020-11-04 13:36:22 -0500

tfoote gravatar image

PointCloud2 is the recommended format for a long time. (Over a decade)

The new name was chosen and the old message kept around to not break existing users.

Switching the name between ROS 1 and ROS 2 would be possible, but that would cause extra pain when migrating code. PointCloud2 has long been the name and the consistency and stability are much more valuable than the "cleanliness" of renaming it. Especially if we were to rename it to an already existing definition.

We've officially decided to remove it in future releases in the Foxy API review: https://github.com/ros2/common_interf...

edit flag offensive delete link more
1

answered 2020-11-04 10:17:39 -0500

Well, these two message types are very different from one another:

> rosmsg show sensor_msgs/PointCloud
std_msgs/Header header
  uint32 seq
  time stamp
  string frame_id
geometry_msgs/Point32[] points
  float32 x
  float32 y
  float32 z
sensor_msgs/ChannelFloat32[] channels
  string name
  float32[] values

vs.

> rosmsg show sensor_msgs/PointCloud2
std_msgs/Header header
  uint32 seq
  time stamp
  string frame_id
uint32 height
uint32 width
sensor_msgs/PointField[] fields
  uint8 INT8=1
  uint8 UINT8=2
  uint8 INT16=3
  uint8 UINT16=4
  uint8 INT32=5
  uint8 UINT32=6
  uint8 FLOAT32=7
  uint8 FLOAT64=8
  string name
  uint32 offset
  uint8 datatype
  uint32 count
bool is_bigendian
uint32 point_step
uint32 row_step
uint8[] data
bool is_dense

Maybe just adding a 2 at the end wasn't the best choice of name, but honestly, I think it's as good as any other, because it's just that, a name. Between the two it should also be relatively obvious in which way the second version is better: it's more compact.

Regarding the question of dropping the 2 when moving to ROS2 I'd like to ask: why? Right now, interoperability between ROS1 and ROS2 is alleviated by the fact -- I think it's a fact, but I'm not an expert -- that many message definitions are valid in both versions. Quickly looking at the migration guide and the ROS 2 interface design, it seems that PointCloud2 is a valid ROS 2 message definition without modification. So isn't it nice to keep the ability for ROS1 and ROS2 systems to exchange PointCloud2 messages?

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

2 followers

Stats

Asked: 2020-11-04 09:11:53 -0500

Seen: 149 times

Last updated: Nov 04 '20