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

TF data from ignition does not follow REP 105 #91

Closed osrf-migration closed 5 years ago

osrf-migration commented 5 years ago

Original report (archived issue) by John Rogers (Bitbucket: jgrogers).

The original report had attachments: frames.pdf, frames.pdf

As per REP 105 https://www.ros.org/reps/rep-0105.html

TF should go from map → odom → base

What we have is:

X1 → X1/base_link, the parent of the base frame is a frame called “X1” with the identity transform.

I think I can work around this for now due to the frame ID flaw in the odometry message, by adding a new frame “base_link” such that

X1/odom → base_link → X1 → X1/base_link

but this is probably not desirable. “X1” is also the parent of the wheel locations of the robot, so it is probably meant to be X1/base_footprint

osrf-migration commented 5 years ago

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

See pull request #177. Let me know if I did something wrong.

osrf-migration commented 5 years ago

Original comment by Alfredo Bencomo (Bitbucket: bencomo).

osrf-migration commented 5 years ago

Original comment by John Rogers (Bitbucket: jgrogers).

Hmm, I’m trying this fix out on the hello world Cartographer system and it isn’t working as well as letting Cartographer make its own X1/odom → X1 TF.

I think that we should provide the odometry message, but not broadcast TF on odometry frame from Ignition, as more sophisticated approaches would combine IMU and odometry data with a filter.

Sending it from Ignition provides another obstacle to overcome to switch to an integrated IMU/odometry frame since the “X1” frame is parented by ignition’s odometry frame.

This means that if we want to send a new frame we have to deal with constant TF errors due to multiple parenting.

If we do want to provide an odometric frame, we could reverse the parent/child relationship so the “X1/odom” frame from ignition is a child of the X1 frame (and invert the transform) to give the user access to this frame but without blocking them from implementing their own.

In short, I propose to either comment out line 60 in subt_ros/src/pose_tf_broadcaster.cpp or switch lines 42 - 49 to invert the transform and flip the frames. It would also be nice to name the odom frame something like ignition_odom to allow the user to define their own frame and use the name “odom”

osrf-migration commented 5 years ago

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

To confirm, can I just decline pull request #177?

osrf-migration commented 5 years ago

Original comment by John Rogers (Bitbucket: jgrogers).

Yes, that should work

osrf-migration commented 5 years ago

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

If this issue fixed, or is there still something we should do?

osrf-migration commented 5 years ago

Original comment by Sarah Kitchen (Bitbucket: snkitche).

I haven’t been able to get cartographer running correctly since switching over to ignition (error messages are either no X1/map or disconnected trees, with no connection between X1/map and X1/base_link). I haven’t posted to this thread yet because I haven’t been able to determine yet if it’s related to the deviation from REP-105 yet or not. If so, I could either continue posting comments here, or make a new issue - your preference. John Rogers (jgrogers) , if you were able to run cartographer with X1 with X1_SENSOR_CONFIG_4, do you mind sharing your lua configuration? Thanks.

osrf-migration commented 5 years ago

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

Sarah Kitchen (snkitche) Cartographer is working on the SubT Hello World repository on the “ignition” branch. Documentation has not been updated but the lua configuration is present in the repository on the branch. (https://bitbucket.org/jgrogers/subt_hello_world/commits/branch/ignition)

osrf-migration commented 5 years ago

Original comment by Sarah Kitchen (Bitbucket: snkitche).

Arthur Schang (Arthur Schang) , thanks I’ve cloned your ignition branch and am trying to run the following:

Terminal 1:

ign launch -v 4 virtual_stix.ign robotName1:=X1 robotConfig1:=X1_SENSOR_CONFIG_4

Terminal 2:

roslaunch helloworld_subt_launch helloworld-ign.launch

With errors and warnings of the following type:

[ WARN] [1562686798.884227893, 101.462000000]: W0709 11:39:58.000000 11804 tf_bridge.cc:52] Lookup would require extrapolation into the past.  Requested time 90.050000000 but the earliest data is at time 91.461000000, when looking up transform from frame [X1/base_link/imu_sensor] to frame [X1]
[ WARN] [1562686798.884300216, 101.462000000]: W0709 11:39:58.000000 11804 tf_bridge.cc:52] Lookup would require extrapolation into the past.  Requested time 90.050000000 but the earliest data is at time 91.461000000, when looking up transform from frame [X1/base_link/imu_sensor] to frame [X1]
[ERROR] [1562686799.471079435, 101.650000000]: Extrapolation Error looking up robot pose: Lookup would require extrapolation into the past.  Requested time 90.623000000 but the earliest data is at time 91.649000000, when looking up transform from frame [X1/base_link] to frame [map]

[ WARN] [1562686799.512097470, 101.662000000]: W0709 11:39:59.000000 11804 tf_bridge.cc:52] Could not find a connection between 'X1' and 'base_link' because they are not part of the same tree.Tf has two or more unconnected trees.
[ WARN] [1562686800.116323704, 101.863000000]: W0709 11:40:00.000000 11804 tf_bridge.cc:52] Could not find a connection between 'X1' and 'base_link' because they are not part of the same tree.Tf has two or more unconnected trees.

Are these the same kinds of complaints you guys saw (as indicated by your commit message)?

I’m also getting these errors from the ignition terminal:

[ERROR] [1562686764.351808883]: Client [/X1/move_base] wants topic /X1/points to have datatype/md5sum [sensor_msgs/PointCloud/d8e9c3f5afbdd8a130fd1d2763945fca], but our version has [sensor_msgs/PointCloud2/1158d486dd51d683ce2f1be655c3c181]. Dropping connection.
[ERROR] [1562687005.015042569]: Client [/X1/move_base] wants topic /X1/points to have datatype/md5sum [sensor_msgs/PointCloud/d8e9c3f5afbdd8a130fd1d2763945fca], but our version has [sensor_msgs/PointCloud2/1158d486dd51d683ce2f1be655c3c181]. Dropping connection.

I’m also attaching my tf trees from view_frames. Notably, I have base_link->X1->X1/base_link. Is this expected behavior? Is this issue related at all to Issue #100 (#100)?

Here is the roswtf output:

Loaded plugin tf.tfwtf
Loaded plugin openni2_launch.wtf_plugin
No package or stack in context
================================================================================
Static checks summary:

No errors or warnings
================================================================================
Beginning tests of your ROS graph. These may take awhile...
analyzing graph...
... done analyzing graph
running graph rules...
... done running graph rules
running tf checks, this will take a second...
... tf checks complete

Online checks summary:

Found 1 warning(s).
Warnings are things that may be just fine, but are sometimes at fault

WARNING The following node subscriptions are unconnected:
 * /rviz:
   * /X1/projected_map_updates
   * /X1/map_updates
 * /X1/move_base:
   * /X1/move_base/cancel
   * /X1/scan
   * /X1/move_base_simple/goal

Found 2 error(s).

ERROR The following nodes should be connected but aren't:
 * /X1/move_base->/X1/move_base (/X1/move_base/global_costmap/footprint)
 * /ignition->/X1/move_base (/X1/points)
 * /X1/move_base->/X1/move_base (/X1/move_base/local_costmap/footprint)

ERROR Different number of openni2 sensors found.
 * 0 openni2 sensors found (expected: 1).
osrf-migration commented 5 years ago

Original comment by John Rogers (Bitbucket: jgrogers).

Lets see if Arthur Schang (Arthur Schang) can check into the TF tree issues you are having. This does look like what I was seeing in issue #100. I think the decision was made to keep the bare “X1” frame in there. Does it work after a few seconds, or do you keep getting the TF errors forever?

Good catch on the sensor_msgs/PointCloud vs sensor_msgs/PointCloud2 issue. I put both the synthesized planar lidar scan as well as the point cloud into the move base for local navigation, and it looks like only the planar lidar is working, which should be sufficient. Arthur Schang (Arthur Schang) can you remove the point cloud component from the move_base yaml files (costmap_common.yaml)?

osrf-migration commented 5 years ago

Original comment by Sarah Kitchen (Bitbucket: snkitche).

TF issues persist forever.

Re: the sensor_msgs, could you alternatively replace PointCloud with PointCloud2 in costmap_common.yaml to resolve the issue?

osrf-migration commented 5 years ago

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

Alright, so we were not getting this issue when building Ignition from source so I went ahead and built up another image from the debs. Unfortunately due to how I configured my docker linking I can’t revert. The good news is I’m encountering the same issue as you now so I can work on fixing it.

I’ll ping you back in a few whenever I get this resolved. I think it is related you default options opening a certain package that bogs down tf and ends up with enough delay to result in extrapolation errors.

osrf-migration commented 5 years ago

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

Sarah Kitchen (snkitche) it looks like the chief problem here is that on the ignition branch we’ve been testing on the /<robot_name>/odom topic has been updated to have /<robot_name>/odom → /<robot_name>/base_link whereas the debian install still has /<robot_name>/odom → /base_link which is creating a mess of your TF tree. (please check to confirm this is an issue for you by echoing your /<robot_name>/odom topic and checking frame_id and child_frame_id)

I can push up a fix for you but it would be working in reverse so let’s see if Nate has any pointers on how to update.

Nate Koenig (Nathan Koenig) how do we get this update on the debian install of subt?

osrf-migration commented 5 years ago

Original comment by Sarah Kitchen (Bitbucket: snkitche).

Thanks, for /X1/odom, I have

frame_id: “X1” (robot name)

child_frame_id: “base_link”

FWIW, I’m still using the catkin_ws installation, not Docker yet.

osrf-migration commented 5 years ago

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

I checked on the Ignition source install image this morning and it worked for me due to the correct topic frame_id on odom. It seems the default branch for Ignition Gazebo is about ~200 commits behind the development branch. I suppose unless you want to install Ignition from source you’ll have to wait. If you’re unable to do that I can commit a launch file that will work for you.

osrf-migration commented 5 years ago

Original comment by Sarah Kitchen (Bitbucket: snkitche).

I can't transition my controller to ignition until I can get cartographer working. We will need the solution to this issue available in the subt docker in particular - I don't need it resolved on my machine. Can you provide a subt docker with the ignition Dev branch installed from source?

osrf-migration commented 5 years ago

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

Sarah Kitchen (snkitche) try pulling down from the ignition branch again (commit 435b3e91baf5bba330a270135d2b07262ebee3d9) and run that. Let me know if it works/doesn’t work (for cartographer).

osrf-migration commented 5 years ago

Original comment by Sarah Kitchen (Bitbucket: snkitche).

That url leads toa 404. I assume you mean jgrogers/subt_hello_world/commits, instead of osrf/subt/commits?

I’ve pulled that commit, and cartographer does appear to be working now with helloworld-ign.launch. However, I am attaching a new frames.pdf, because there still may be frame issues that could cause problems in other areas. E.g. map->X1->X1/base_link->base_link? And the disconnected X1/front_camera_optical->X1/X1/front_camera_optical

Thanks, Arthur!

osrf-migration commented 5 years ago

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

Yes, I did mean the commit hash on the subt_hello_world. The disconnected portion of the TF tree is an artifact from some perception testing that’s s till WIP.

I’m glad cartographer worked for you, good luck with getting your controller working!

osrf-migration commented 5 years ago

Original comment by Malcolm Stagg (Bitbucket: malcolmst7).

Adding <node pkg="tf2_ros" type="static_transform_publisher" name="static_base" args=" 0 0 0 0 0 0 base_link X1"/> from helloworld-ign.launch works for me too for getting a robot moving again (thanks!).

Because of the global /base_link frame though, I expect there will be problems getting 2 or more robots running for local development. Do you have any idea of when this will be fixed in the default branch for a docker install? Or if I were to build subt from source, which branch should be used where /base_link is removed?

osrf-migration commented 5 years ago

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

I’m glad you got it working! Following up on your questions:

  1. Ignition source install the biggest difference is https://bitbucket.org/ignitionrobotics/ign-gazebo involving the development branch ign-gazebo2 (I suspect after they merge this branch back in we’ll see it fixed in the deb install)
  2. You will (should) not have shared TF data at all for submission because each robots will be run in network isolation with the only communication being over the documented API.
osrf-migration commented 5 years ago

Original comment by Hector Escobar (Bitbucket: hector_escobar).

Could you update the instructions of the subt_hello_world to have the most up to date branches? And also add instructions for generating it with catkin locally?

Thanks

osrf-migration commented 5 years ago

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

Hector Escobar (hector_escobar) working on updating the documentation right now. I can add instructions for making it work with catkin locally but under the assumption that you’ll be using the Ignition simulator. I’ll ping you back here whenever it’s finished.

osrf-migration commented 5 years ago

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

Hector Escobar (hector_escobar) I just finished updating the documentation instructions over at https://bitbucket.org/jgrogers/subt_hello_world/wiki/Home

Please let me know if you run into any issues and I’ll try to get them worked out ASAP.

osrf-migration commented 5 years ago

Original comment by Malcolm Stagg (Bitbucket: malcolmst7).

Thanks Arthur! Re your point (2), that makes sense, so I guess the /X1/odom → /base_link → /X1 shouldn’t be a blocking issue in cloudsim where the isolation is enforced. I haven’t tried controlling multiple robots in Ignition yet, but I’m assuming when I try to run that locally (where this isolation isn’t strongly enforced) there could be issues due to:

/X1/odom → /base_link → /X1

/X2/odom → /base_link → /X2

Anyway, I’ll try building from source and can see if I can get things running locally with the updated frame IDs. Really appreciate your help!

osrf-migration commented 5 years ago

Original comment by Hector Escobar (Bitbucket: hector_escobar).

Thanks for updating it.

For the docker version:

The Docker file downloaded using

wget https://bitbucket.org/jgrogers/subt_hello_world/raw/1720cbf96a17811a83b2b545d6fea5181c84b780/catkin_base_ws/docker/Dockerfile

needs these packages added

ros-melodic-move-base-msgs \ ros-melodic-image-geometry \ ros-melodic-vision-msgs

to compile properly. And the following instructions should be preceded by

cd ~/subt_docker/subt_hello_world/ (since the run.bash is the newly obtained and not the one under ~/subt_docker/)

./run.bash subt_extended ${PWD}/subt_hello_world/catkin_base_ws ${PWD}/subt_hello_world/catkin_build_ws

Finally, when running the first example, on the second screen (roslaunch helloworld_subt_launch helloworld.launch), I get this messages and the vehicle doesn’t move.

Correction:

I get these messages

‌

osrf-migration commented 5 years ago

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

Thanks for pointing out the difference in run.bash, the default subt one used to work but they had removed some functionality so I had to revert and save it to the repo. I’ll add to the instructions. I’ll also update the Dockerfile and link to Dockerfile correctly in the instructions.

The logical_camera_projector package should not be run. Pull the latest commit from the ignition branch. I had some changes made last night that I didn’t commit until the EOD so you might not have gotten those. If you are not running on Ignition build from source you will need to uncomment line 27 in “robot.launch” as it is necessary to psuedo-fix the TF tree. Mapping should then work, whether or not move_base works for wall following goals will probably depend on TF timing. I’ll see if I can just leave that TF in on the next commit or if it interferes with anything from Ignition source build.

I appreciate working through all of that, I didn’t get the opportunity to stand it all back up myself yet so I figured there might be a few small package errors. The run.bash one is pretty big given the change in run.bash from gazebo install → ignition install so good job catching that! I’ll post here again whenever I’ve made the aforementioned updates, please let me know if anything looks out of place.

The wiki and repository have been updated.

osrf-migration commented 5 years ago

Original comment by Neil Johnson (Bitbucket: realdealneil1980).

I was able to get the subt_extended docker image running . I just had to install one more package in docker (ros-melodic-move-base). The ground vehicle enters the tunnel and goes about 50 feet before turning into the wall and getting stuck. But, thanks for putting together these packages in the subt_extended container. There’s some very helpful stuff in there.

osrf-migration commented 5 years ago

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

Checking in to see if there are additional requests or problems.

osrf-migration commented 5 years ago

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

osrf-migration commented 5 years ago

Original comment by Alfredo Bencomo (Bitbucket: bencomo).

osrf-migration commented 5 years ago

Original comment by Alfredo Bencomo (Bitbucket: bencomo).

Resolving this since teams might have already adapted to the way things are for tunnel circuit and worked around by using cartographer as suggested here. Feel free to open a RFE (Request-for- Enhancement) for Urban though.

osrf-migration commented 4 years ago

Original comment by Alfredo Bencomo (Bitbucket: bencomo).