Target poses are not loaded in the right frame

[jonazpiazu]

The poses loaded from the pointcloud file are not correctly related to the kinematic_base_frame.

In a previous version of the code, the getSampledMesh function was loading the pointcloud and transforming it to the correct frame, doing something like:

geometry_msgs::TransformStamped tf = buffer.lookupTransform(req.fixed_frame, req.object_frame, ros::Time(0), ros::Duration(5.0));
transform = tf2::transformToEigen(tf.transform);

pcl::PointCloud<pcl::PointNormal> transformed_cloud;
pcl::transformPointCloudWithNormals(cloud, transformed_cloud, transform.matrix());

That part is lost in the current version.

However display of the markers is still correct because when adding the markers, the frame is actually used:

auto marker = utils::makeInteractiveMarker(id, db[i], kinematic_base_frame_, marker_scale_, heatmap_colors.row(i));

When doing the calculations, target_poses_ is used, which has not gone under any frame transformation. So even if the display of the poses is correct, the calculations are not.

[marip8]

Per the README and the target_pose_generator interface documentation, the target waypoints produced by the target_pose_generator interface implementations are expected to be relative to the robot kinematic base frame. This is a change that was introduced as a part of the update to version 1.0.0

You can still use the workflow of creating a point cloud using PCL mesh sampling and loading that point cloud into the reach study via the point_cloud_target_pose_generator. The only difference is that the point cloud needs to be relative to the kinematic base frame of the robot. This can be done in a number of ways:

1. Moving the origin of the sampled mesh to the kinematic base frame
2. Manually applying a transformation to the point cloud before/after saving it (e.g., pcl_transform_cloud, etc.)
3. Creating a new ROS-enabled point_cloud_target_pose_generator which can load a point cloud relative to an arbitrary location and transforming it using TF to the kinematic base frame

I use option 1 in the reach_ros demo, but I could see option 3 being potentially useful as well and it wouldn't be difficult to create

[marip8]

Closing; addressed in above comment and in linked PRs