search

osrf / subt

This repostory contains software for the virtual track of the DARPA SubT Challenge. Within this repository you will find Gazebo simulation assets, ROS interfaces, support scripts and plugins, and documentation needed to compete in the SubT Virtual Challenge.
Other
305 stars 98 forks source link

Transform from X2_1/base_link/imu_sensor to X2_1/base_link is unavailable #120

Closed osrf-migration closed 5 years ago

osrf-migration commented 5 years ago

Original report (archived issue) by Sophisticated Engineering (Bitbucket: sopheng).

We were using the imu-data in Gazebo9 without problems. Now in Ignition we get the Error

“Transform from X2_1/base_link/imu_sensor to X2_1/base_link was unavailable”.

Any hints how to solve this?

osrf-migration commented 5 years ago

Original comment by Alfredo Bencomo (Bitbucket: bencomo).

Are you testing with the latest Docker image?

https://hub.docker.com/r/nkoenig/subt-virtual-testbed

osrf-migration commented 5 years ago

Original comment by Alfredo Bencomo (Bitbucket: bencomo).

osrf-migration commented 5 years ago

Original comment by Sophisticated Engineering (Bitbucket: sopheng).

No, I tested with the tunnel-circuit branch which I recently updated, I think on Saturday.

I also tried to use the new docker image. The tunnel and the robot spawned, but I don’t understand how to use my nodes in this environment. Is there a description how to do it?

osrf-migration commented 5 years ago

Original comment by Sophisticated Engineering (Bitbucket: sopheng).

Sorry, but I don’t understand it. I would expect to have two docker containers, one with the subt code containing the tunnel and the robots and another one with my code (which I wrote based on the subt-seed example) containing the nodes to control the robot, navigate and find artifacts. How to I build the second container and how does the communication work between the two?

osrf-migration commented 5 years ago

Original comment by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

“Transform from X2_1/base_link/imu_sensor to X2_1/base_link was unavailable”.

I can't reproduce this error. Can you give more information on what steps you followed to get to this state?

It sounds like your problems are not exactly related to TF and the real problem is that you can't setup the simulation. If you have questions about setting up docker, I suggest you open a new issue for that with specific questions.

You said that at some point "The tunnel and the robot spawned". Are you able to go back to that setup so we can debug the TF issue? Could you check TF on RViz and let me know which ones are missing? Also, did you see any error messages printed out when you launched simulation?

osrf-migration commented 5 years ago

Original comment by Arthur Schang (Bitbucket: Arthur Schang).

What does your TF tree look like? I just checked with the most up to date version and got the following:

osrf-migration commented 5 years ago

Original comment by Sophisticated Engineering (Bitbucket: sopheng).

Thank you very much for your feedback.
For me the TF tree looks not bad:

The problem occurs in the localization node. Here the complete first lines:

[ WARN] [1563827173.117525065, 1066.787000000]: Detected jump back in time of 1.56383e+09s. Clearing TF buffer.
[ WARN] [1563827173.131819206, 1066.793000000]: Could not obtain transform from base_link to X2_1/base_link. Error was "base_link" passed to lookupTransform argument source_frame does not exist.
[ WARN] [1563827173.225551134, 1066.815000000]: Transform from X2_1/base_link/imu_sensor to X2_1/base_link was unavailable for the time requested. Using latest instead.
…

In Gazebo 9 it worked but in Ignition it does not work any more. Research in the internet gives also statements that it could be a timing problem.

osrf-migration commented 5 years ago

Original comment by Arthur Schang (Bitbucket: Arthur Schang).

Sophisticated Engineering (sopheng)

A jump of that much time is typically indicative of something you’re running not using sim_time. Make sure you set use_sim_time to true in your launch file or something akin to “rosparam set use_sim_time true”

osrf-migration commented 5 years ago

Original comment by Sophisticated Engineering (Bitbucket: sopheng).

Thank you very much for the advice. Unfortunately it does not solve my problem. I added the parameter in my launch-file but still the messages occur.

In a second attempt I checked the parameter directly after starting the tunnel world (with spawning my robot):

:~/workspace/subt_seed_ws$ rosparam get /use_sim_time
true

After some attempts I got many messages like these:

ESC[33m[ WARN] [1563915818.701178137, 6.801000000]: Detected jump back in time of 0.003s. Clearing TF buffer.ESC[0m
ESC[33m[ WARN] [1563915818.706968957, 6.816000000]: Detected jump back in time of 0.001s. Clearing TF buffer.ESC[0m
ESC[33m[ WARN] [1563915818.709302017, 6.802000000]: Detected jump back in time of 0.014s. Clearing TF buffer.ESC[0m
ESC[33m[ WARN] [1563915818.718298978, 6.816000000]: Detected jump back in time of 0.018s. Clearing TF buffer.ESC[0m
ESC[33m[ WARN] [1563915818.732165092, 6.802000000]: Detected jump back in time of 0.035s. Clearing TF buffer.ESC[0m
ESC[33m[ WARN] [1563915818.769012807, 6.842000000]: Could not obtain transform from base_link to X2_1/base_link. Error was "base_link" passed to lookupTransform argument source_frame does not exist.
ESC[0m
ESC[33m[ WARN] [1563915818.770330282, 6.840000000]: Detected jump back in time of 0.002s. Clearing TF buffer.ESC[0m
ESC[33m[ WARN] [1563915818.785496980, 6.840000000]: Detected jump back in time of 0.004s. Clearing TF buffer.ESC[0m
ESC[33m[ WARN] [1563915818.859838999, 6.840000000]: Could not obtain transform from base_link to X2_1/base_link. Error was "base_link" passed to lookupTransform argument source_frame does not exist.
ESC[0m
ESC[33m[ WARN] [1563915818.861674419, 6.840000000]: Detected jump back in time of 0.006s. Clearing TF buffer.ESC[0m
ESC[33m[ WARN] [1563915818.879973618, 6.850000000]: Detected jump back in time of 0.001s. Clearing TF buffer.ESC[0m
ESC[33m[ WARN] [1563915818.891442905, 6.853000000]: Transform from X2_1/base_link/imu_sensor to X2_1/base_link was unavailable for the time requested. Using latest instead.
ESC[0m
ESC[33m[ WARN] [1563915818.901706298, 6.853000000]: Detected jump back in time of 0.001s. Clearing TF buffer.ESC[0m

Something must have changed in Ignition because the same code still works in Gazebo 9.

Do you have another idea?

osrf-migration commented 5 years ago

Original comment by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

Error was "base_link" passed to lookupTransform argument source_frame does not exist

Are you asking for base_link instead of X2_1/base_link somewhere?

osrf-migration commented 5 years ago

Original comment by Addisu Z. Taddese (Bitbucket: azeey, GitHub: azeey).

Could the issue be related to the error message "Could not obtain transform from base_link to X2_1/base_link. Error was "base_link" passed to lookupTransform argument source_frame does not exist"? The other error just says it was unavailable for the time requested, but it continues to use the latest transform. This error says there's no "base_link". Is your code expecting a frame called "base_link"?

osrf-migration commented 5 years ago

Original comment by Sophisticated Engineering (Bitbucket: sopheng).

I cannot find a position where only base_link is used. Would base_link be valid in the Gazebo 9 environment?

osrf-migration commented 5 years ago

Original comment by Addisu Z. Taddese (Bitbucket: azeey, GitHub: azeey).

I just ran the Gazebo 9 environment, but I didn't see base_link. Can you inspect your TF tree in the Gazebo 9 environment to see if it's being broadcast by a node? tf_monitor might be useful.

osrf-migration commented 5 years ago

Original comment by Arthur Schang (Bitbucket: Arthur Schang).

[ WARN] [1563827173.117525065, 1066.787000000]: Detected jump back in time of 1.56383e+09s. Clearing TF buffer.

Is very different from

ESC[33m[ WARN] [1563915818.785496980, 6.840000000]: Detected jump back in time of 0.004s. Clearing TF buffer.ESC[0m

It looks like sim time is helping to me but you have another issue.

ESC[33m[ WARN] [1563915818.859838999, 6.840000000]: Could not obtain transform from base_link to X2_1/base_link. Error was "base_link" passed to lookupTransform argument source_frame does not exist.

Are there multiple publishers for that tf? This is typically an error you get whenever the tf tree is being broken by multiple tf publishers. l. You could also be using a legacy static transform (make sure all of your static transformers are tf2, not tf) and that could be causing some of the jumping back in time as the transform is on both tf and tf_static.

Also, judging from Addisu’s comment that he cannot find that publisher in Gazebo 9, you might be publishing it in a launch file and Ignition Gazebo might be publishing it as well.

osrf-migration commented 5 years ago

Original comment by Sophisticated Engineering (Bitbucket: sopheng).

I also do no see a frame called base_link in Gazebo 9.

RESULTS: for all Frames

Frames:
Frame: X2_1/base_link published by unknown_publisher Average Delay: 0.00224051 Max Delay: 0.013
Frame: X2_1/center_left_headlight_link published by unknown_publisher(static) Average Delay: 0 Max Delay: 0
Frame: X2_1/center_right_headlight_link published by unknown_publisher(static) Average Delay: 0 Max Delay: 0
Frame: X2_1/chassis_link published by unknown_publisher(static) Average Delay: 0 Max Delay: 0
Frame: X2_1/front_L_camera_beam published by unknown_publisher(static) Average Delay: 0 Max Delay: 0
Frame: X2_1/front_L_camera_mount published by unknown_publisher(static) Average Delay: 0 Max Delay: 0
Frame: X2_1/front_R_camera_beam published by unknown_publisher(static) Average Delay: 0 Max Delay: 0
Frame: X2_1/front_R_camera_mount published by unknown_publisher(static) Average Delay: 0 Max Delay: 0
Frame: X2_1/front_camera_L published by unknown_publisher(static) Average Delay: 0 Max Delay: 0
Frame: X2_1/front_camera_L_optical published by unknown_publisher(static) Average Delay: 0 Max Delay: 0
Frame: X2_1/front_camera_R published by unknown_publisher(static) Average Delay: 0 Max Delay: 0
Frame: X2_1/front_camera_R_optical published by unknown_publisher(static) Average Delay: 0 Max Delay: 0
Frame: X2_1/front_left_wheel_link published by unknown_publisher Average Delay: 0.000338608 Max Delay: 0.006
Frame: X2_1/front_mount published by unknown_publisher(static) Average Delay: 0 Max Delay: 0
Frame: X2_1/front_right_wheel_link published by unknown_publisher Average Delay: 0.000338608 Max Delay: 0.006
Frame: X2_1/imu_link published by unknown_publisher(static) Average Delay: 0 Max Delay: 0
Frame: X2_1/left_headlight_link published by unknown_publisher(static) Average Delay: 0 Max Delay: 0
Frame: X2_1/left_lateral_led_link published by unknown_publisher(static) Average Delay: 0 Max Delay: 0
Frame: X2_1/mid_mount published by unknown_publisher(static) Average Delay: 0 Max Delay: 0
Frame: X2_1/navsat_link published by unknown_publisher(static) Average Delay: 0 Max Delay: 0
Frame: X2_1/rear_center_led_link published by unknown_publisher(static) Average Delay: 0 Max Delay: 0
Frame: X2_1/rear_left_wheel_link published by unknown_publisher Average Delay: 0.000338608 Max Delay: 0.006
Frame: X2_1/rear_mount published by unknown_publisher(static) Average Delay: 0 Max Delay: 0
Frame: X2_1/rear_right_wheel_link published by unknown_publisher Average Delay: 0.000338608 Max Delay: 0.006
Frame: X2_1/right_headlight_link published by unknown_publisher(static) Average Delay: 0 Max Delay: 0
Frame: X2_1/right_lateral_led_link published by unknown_publisher(static) Average Delay: 0 Max Delay: 0

All Broadcasters:
Node: unknown_publisher 100.286 Hz, Average Delay: 0.00128956 Max Delay: 0.013
Node: unknown_publisher(static) 1e+08 Hz, Average Delay: 0 Max Delay: 0

‌

We are using the robot_localization node that is part of the Simulationsystem itself. I now recognized that in our Gazebo 9 installation we are using an older version of it:

dpkg -l | grep localization
ii ros-melodic-robot-localization 2.6.2-0bionic.20181117.185056 amd64

In the docker container installation we are using the newest stable version:

ii ros-melodic-robot-localization 2.6.4-0bionic.20190601.021007 amd64

On the website itself I found some issues that sound like the problems we have here, but for me its not exactly clear:

pull-request: Fix issue with tf_prefix and the base_link frame_id #465 ; Issue: tf_prefix not added to base_link #464

This latest fix seem not to be in the newest stable version, so it is not used in ignition.

Have you ever tried to use this node in ignition?

osrf-migration commented 5 years ago

Original comment by Arthur Schang (Bitbucket: Arthur Schang).

Yes, I have used the robot_localization package before and to get it to work properly I had to go in and add an additional parameter for the base_link frame to be read from my configuration file. Before we jump to that, can you explain to me what you’re trying to do as there might be a better solution or you can just use a static transform to patch your tree together for now.

osrf-migration commented 5 years ago

Original comment by Sophisticated Engineering (Bitbucket: sopheng).

We are trying to use the imu data an the velocity from the wheels to get the current position of the robot.

osrf-migration commented 5 years ago

Original comment by Arthur Schang (Bitbucket: Arthur Schang).

There is an odometry topic already published, are you pursuing a Z-position component to feed into your mapping algorithm/for localization at this level or do you just not want to use the odometry topic? Either way, you can configure the robot_localization package to work around in the current tf tree structure.

osrf-migration commented 5 years ago

Original comment by Sophisticated Engineering (Bitbucket: sopheng).

Does this odometer topic already take into account the imu data? Or how does it work?

osrf-migration commented 5 years ago

Original comment by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

Does this odometer topic already take into account the imu data? Or how does it work?

No IMU data, it just takes wheel angles as input. You can see the calculation here.

osrf-migration commented 5 years ago

Original comment by Sophisticated Engineering (Bitbucket: sopheng).

As I also need z-coordinate, i would guess that i need imu data. So how to do this? (I used robot localization for that, which currently does not work)

osrf-migration commented 5 years ago

Original comment by Arthur Schang (Bitbucket: Arthur Schang).

It depends on the mapping algorithm as to whether or not you want to feed in Z-data as part of your odometry solution. If you are using Cartographer 3D then it requires IMU separately and thus you would want to feed in just 2D wheel odometry and let it combine it with IMU itself for a 3D position within that 3D map.

‌

If you absolutely need to feed in 3D odometry into your mapping algorithm or for something else, you should use the robot_localization package and adjust a parameter file (i.e. https://github.com/cra-ros-pkg/robot_localization/blob/melodic-devel/params/ekf_template.yaml) to meet the current system configuration. If you’re having tf issues with robot_localization, try adjusting the parameters on lines 63 to 66 in the file I just linked.

osrf-migration commented 5 years ago

Original comment by Sophisticated Engineering (Bitbucket: sopheng).

Thank you very much for the hints. Unfortunately I do not get it working again in ignition. I copied the config file from the link you provided and ma a few corrections:

With this config I get:

ESC[33m[ WARN] [1564224051.052771970]: X acceleration is being measured from IMU; X velocity control input is disabledESC[0m
ESC[33m[ WARN] [1564224051.131209794, 1119.569000000]: Detected jump back in time of 1.56422e+09s. Clearing TF buffer.ESC[0m
ESC[33m[ WARN] [1564224051.306029533, 1119.616000000]: Transform from X2_1/base_link/imu_sensor to X2_1/base_link was unavailable for the time requested.
Using latest instead.
ESC[0m
ESC[33m[ WARN] [1564224051.315756897, 1119.618000000]: Could not obtain transform from X2_1 to odom. Error was "odom" passed to lookupTransform argument t
arget_frame does not exist.
ESC[0m
ESC[33m[ WARN] [1564224060.295261914, 1121.616000000]: Transform from X2_1/base_link/imu_sensor to X2_1/base_link was unavailable for the time requested.
Using latest instead.
ESC[0m
ESC[33m[ WARN] [1564224060.298219244, 1121.618000000]: Could not obtain transform from X2_1 to odom. Error was Could not find a connection between 'odom'
and 'X2_1' because they are not part of the same tree.Tf has two or more unconnected trees.
ESC[0m
ESC[33m[ WARN] [1564224067.850246668, 1123.619000000]: Transform from X2_1/base_link/imu_sensor to X2_1/base_link was unavailable for the time requested.
Using latest instead.
ESC[0m
ESC[33m[ WARN] [1564224067.854237181, 1123.620000000]: Could not obtain transform from X2_1 to odom. Error was Could not find a connection between 'odom'
and 'X2_1' because they are not part of the same tree.Tf has two or more unconnected trees.
ESC[0m
ESC[33m[ WARN] [1564224076.006562626, 1125.350000000]: Failed to meet update rate! Took 0.075000057000000008856ESC[0m

…

I’m confused.

osrf-migration commented 5 years ago

Original comment by Arthur Schang (Bitbucket: Arthur Schang).

The odom complaints are due to you have an unconnected odom transform as shown in your tf tree here: https://bitbucket-assetroot.s3.amazonaws.com/repository/8ze6Mjd/152623770-tf-tree.png?Signature=leiVJzIoDDaLzBKX23YP60EBwi8%3D&Expires=1564406792&AWSAccessKeyId=AKIAIQWXW6WLXMB5QZAQ

‌

I think you should read through issue #91, figure out what is disconnecting your odom transform and create a static transform for it to fix your tf tree or ensure that your wheel odometry is being published with a tf and that this tf is present in your tf tree.

osrf-migration commented 5 years ago

Original comment by Sophisticated Engineering (Bitbucket: sopheng).

Unfortunately your link does not work (Request has expired).

I don’t understand why I have to define a transform from odom to the robot-frame. I would expect this from the localization node. For me this seems to work so in Gazebo 9:

Is there something special or new in the newer version that I have to define to get the connection between odom and X2_1/base_link?

osrf-migration commented 5 years ago

Original comment by Sophisticated Engineering (Bitbucket: sopheng).

Meanwhile the localization works but not always.

After startup the connection between odom and X2_1/base_Link is available:

After a few seconds it is not available any more and odom is unconnected:

And after some more seconds the connection is available again:

‌

Does this have to do with a performance issue? This would explain why the localization is now displaying some valid data as the simulation environment is meanwhile much faster but there are still messages regarding transform problems:

Transform from X2_1/base_link/imu_sensor to X2_1/base_link was unavailable for the time requested. Using latest instead.

Is there a problem using robot_localization with ignition?

osrf-migration commented 5 years ago

Original comment by Addisu Z. Taddese (Bitbucket: azeey, GitHub: azeey).

I see that you're using the odom frame in your robot_localization configuration. Can you try X2_1/odom instead?

Also it might be useful to set the debug parameter of robot_localization to true to get more insight as to what is missing.

osrf-migration commented 5 years ago

Original comment by Sophisticated Engineering (Bitbucket: sopheng).

I also tried using X2_1/odom and thought due to this change it now works, but in fact it then also worked with the odom frame. So something different has changed to make it work (performance?). And with X2_1/odom similar errors occur. And why is it working sometimes and sometime not?

osrf-migration commented 5 years ago

Original comment by Arthur Schang (Bitbucket: Arthur Schang).

You should just make a static transform (of 0,0,0,0,0,0) from X2_1/base_link to X2_1 if you are treating them as the same thing or set instances of “X2_1/base_link” to be “X2_1” in robot_localization config if you do not wish to use a static transform. If X2_1/base_link and X2_1 are not the same thing then you have another problem on your hand.

osrf-migration commented 5 years ago

Original comment by Sophisticated Engineering (Bitbucket: sopheng).

I now also tried to use X2_1 instead of X2_1/base_link. The output is similar of both options. The odometry results seem valid but in both options there are still messages "Transform ... was unavailable for the time requested. Using latest instead."in the log files.

I also run the localization with the debug parameter. Then the log file showed messages like:

...
[33m[ WARN] [1565438731.822415025, 9.560000000]: Failed to meet update rate! Took 0.10000000000000000555
[0m[ WARN] [1565438733.002642152, 9.868000000]: Failed to meet update rate! Took 0.072000000000000008438
[0m[ WARN] [1565438733.373291626, 10.012000000]: Failed to meet update rate! Took 0.044000000000000004385
[ WARN] [1565438733.390044359, 10.012000000]: Transform from X2_1/base_link/imu_sensor to X2_1 was unavailable for the time requested. Using latest instead.
[0m[ WARN] [1565438733.679964076, 10.144000000]: Failed to meet update rate! Took 0.056000000000000001166
[0m[ WARN] [1565438733.821935257, 10.196000000]: Failed to meet update rate! Took 0.088000000000000008771
[0m[ WARN] [1565438733.956878303, 10.248000000]: Failed to meet update rate! Took 0.068000000000000004885
[0m[ WARN] [1565438734.038600618, 10.284000000]: Failed to meet update rate! Took 0.048000000000000000999
[0m[ WARN] [1565438735.937489155, 10.904000000]: Failed to meet update rate! Took 0.064000000000000001332
[0m[ WARN] [1565438736.055531413, 10.960000000]: Failed to meet update rate! Took 0.10000000000000000555
[0m[ WARN] [1565438736.183821717, 11.020000000]: Failed to meet update rate! Took 0.084000000000000005218
[0m[ WARN] [1565438736.452442930, 11.136000000]: Failed to meet update rate! Took 0.13200000000000000622
[ WARN] [1565438736.813637325, 11.316000000]: Failed to meet update rate! Took 0.21600000000000002531
[ WARN] [1565438737.155631213, 11.468000000]: Failed to meet update rate! Took 0.2000000000000000111
[0m[ WARN] [1565438737.239775758, 11.508000000]: Failed to meet update rate! Took 0.052000000000000004552
[0m[ WARN] [1565438739.885316244, 12.012000000]: Transform from X2_1/base_link/imu_sensor to X2_1 was unavailable for the time requested. Using latest instead.
[ WARN] [1565438741.384833695, 12.324000000]: Failed to meet update rate! Took 0.056000000000000001166
[0m[ WARN] [1565438743.218208144, 12.672000000]: Failed to meet update rate! Took 0.044000000000000004385
[0m[ WARN] [1565438743.342314219, 12.744000000]: Failed to meet update rate! Took 0.096000000000000001998
...

So in debug mode additional messages “Failed to meet update rate!” occurred. And the “Transfrom unavailable” message occurs every 2 seconds! Still there seems to be a performance issue every 2 seconds but the localization seems to work.

I will close this issue because the localization works for now and will open a new issue regarding the perfomance issue every 2-seconds.

osrf-migration commented 5 years ago

Original comment by Sophisticated Engineering (Bitbucket: sopheng).

Localization works, new issue will be created for the perfomance problem every 2-seconds.