AustinDeric / yak

yak (yet another kinfu) is a library and ROS wrapper for Truncated Signed Distance Fields (TSDFs).
MIT License
29 stars 12 forks source link

terminate called after throwing an instance of 'tf2::LookupException' #18

Closed aadityasaraiya closed 6 years ago

aadityasaraiya commented 6 years ago

Hi!

I am Aaditya Saraiya and I am currently working on the Google Summer of Code 2018 project with ROS Industrial under the mentorship of @Levi-Armstrong.

I want to use the yak package with my project for 3-D reconstruction with a Kinect mounted on a robotic manipulator. I tried the roslaunch yak launch_xtion_robot.launch command after launching the RViz planning/execution file, when I get this error.

terminate called after throwing an instance of 'tf2::LookupException'
what():  "ensenso_sensor_optical_frame" passed to lookupTransform argument source_frame does not exist.

I am currently using a simulated Kinect from Gazebo. I tried changing the topic names to match with the topic names from my package but that didn't seem to solve the issue. Can you please guide me on how to remove this error as well as how I should start off using this package? Some hints on what parameters I should change just to start off would be very helpful.

Edit: Have just added the tf tree for reference frames1.pdf

Thanks in advance, Aaditya Saraiya

aadityasaraiya commented 6 years ago

Update:

So after viewing the tf tree I realised that the ensenso_sensor_optical_frame did not exist. After making that change in the kinfu_server.cpp file, I am receiving the following error

terminate called after throwing an instance of 'tf2::LookupException'
  what():  "volume_pose" passed to lookupTransform argument target_frame does not exist.

while in fact when viewing the tf tree, the volume_pose frame does exist. So that's a bit weird.

schornakj commented 6 years ago

An overarching issue is that lots of important parameters are hardcoded, so some of the nodes are expecting to see a specific robot and sensor configuration that's not completely represented in the launch file. It also looks for some robot configuration data that's set up by the MoveIt Setup Assistant. The package was developed on the robot from the Godel blending demo, so most of the parameters point at frames and other things from there. In this case from your first comment, ensenso_sensor_optical_frame should be changed to the frame at the origin of the depth image.

Are you also running the other launch file for octomap reconstruction and running the nbv_planner node? volume_pose is the center of the TSDF volume, and it's supposed to be moveable by dragging some handles in Rviz. I think that the transform from the base_link frame is set and updated in volume_tf_broadcaster.cpp, so if you can't see volume_pose I'd start by checking there.

aadityasaraiya commented 6 years ago

@schornakj Thanks for the response. I will make the change regarding changing ensenso_sensor_optical_frame to the depth frame.

I wasn't running the nbv_planner node, so I will try running the same and report back what I get. I realized that about volume_tf_broadcaster.cpp and I will have a look at it to search for a potential issue.

Regarding the interactive volume thing in RViz, I am currently simulating objects in Gazebo. @Levi-Armstrong suggested that I could use gl_depth_sim instead, however, I have stuck to Gazebo as of now.

Thanks again.

Edit: Running the nbv_planner node doesn't make a difference.

aadityasaraiya commented 6 years ago

@schornakj So I analyzed it further. First of all, there were warning regarding my tf tree not being proper, which was solved after changing parameters in the world_to_base_publisher node parameters in Line 4 of the launch_xtion_robot.launch file.

On certain trials, the node suddenly starts working with successful tracking and planning. While sometimes it shows the following error:

terminate called after throwing an instance of 'tf2::LookupException'
 what():  "volume_pose" passed to lookupTransform argument target_frame does not exist.

On some 3-4 occasions it showed the following error (time values used to be different in the error):

Unable to transform object from frame 'map' to planning frame '/world' (Lookup would require extrapolation at time 367.223000000, but only time 367.323000000 is in the buffer, when looking up transform from frame [map] to frame [world]).

So, according to this, it's definitely some time-related issue because of which the transform isn't available when tf::lookupTransform is being performed in Line 26 in the kinfu_server.cpp program. I have tried increasing the time in the tf::waitForTransform but it doesn't help. Any thoughts on why this could be happening? I have attached the new tf tree as well.

frames2.pdf

Thanks!

aadityasaraiya commented 6 years ago

Hi!

So the issue was occuring because the node used to terminate with the error message when the volume_pose frame was not available. However, with the given pull request, I have added exception handling which allows the node to continue as soon as the frame becomes available.