Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Skip laserscans with no corresponding tf transform #313

Closed
wants to merge 3 commits into from
Closed

Skip laserscans with no corresponding tf transform #313

wants to merge 3 commits into from

Conversation

ghost
Copy link

@ghost ghost commented Feb 8, 2017

Copy link
Contributor

@mgruhler mgruhler left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you also add the sleep (1s) after the initialization of the transform listener, as proposed in the issue.

Also, please investigate (in simulation) what happens if you set the frequency of this node to something higher than 10 Hz.

ROS_DEBUG("now project to point_cloud");
projector_.transformLaserScanToPointCloud("/base_link",vec_laser_struct_.at(i).current_scan_msg, vec_cloud.at(i), listener_);
projector_.transformLaserScanToPointCloud("base_link",vec_laser_struct_.at(i).current_scan_msg, vec_cloud.at(i), listener_);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could you please make this a parameter, while you are at it?

@ghost
Copy link
Author

ghost commented Feb 8, 2017

Frequency was already 100Hz. Tried also with 15Hz and it works. Should I add the param to the YAMLs of all robots?

@mgruhler
Copy link
Contributor

mgruhler commented Feb 8, 2017

@mig-em yes, please do that.

@fmessmer
Copy link
Contributor

fmessmer commented Feb 9, 2017

could we also investigate #248 and #249 while @mig-em is on it?
(At least check and report whether the issues are still an issue 😉)

@mgruhler
Copy link
Contributor

mgruhler commented Feb 9, 2017

@mig-em Please do as commanded ;-)

vec_laser_struct_.at(i).current_scan_msg.header.stamp, ros::Duration(3.0)))
{
continue;
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please correct indentation

@benmaidel
Copy link
Contributor

@mig-em @ipa-mig isn't 15Hz a bad idea? See your comments here: ipa320/cob_robots#367

I think we should switch to https://github.com/iralabdisco/ira_laser_tools because they seem to have a better implementation. I've already used their implementation once and it worked quite well.

@mgruhler
Copy link
Contributor

mgruhler commented Feb 9, 2017

@ipa-bnm to avoid misunderstandings: @ipa-nhg reported in #268 some problems with a rate higher then 10Hz. This should not be made the default :-)

The comment about the parameter is only to add the new parameter to the yamls...

@ghost
Copy link
Author

ghost commented Feb 10, 2017

So should I adapt the synchronisation part by using the TimeSynchronizer filter and investigate https://github.com/ipa320/cob_driver/issues/249 or better use the ira_laser_tools?
If I understand it right the rate param will become obsolete by using the filter.

@fmessmer
Copy link
Contributor

I'd say we should evaluate ira_laser_tools and - if it solves all our problems - use it!
If not, fix issues in current scan_unifier...

@fmessmer
Copy link
Contributor

Well, if ira_laser_tools works for us, we might want to "take over" the package and copy/move it to an ipa320 repo...as it is not released...License is TODO 😉

@mgruhler
Copy link
Contributor

if ira_laser_tools is actually working good, "taking it over" would be a good idea. But I'd say we try to get in contact with the developers and see how to proceed. Last commit was Oct. 2015 for that matter...

@mgruhler
Copy link
Contributor

@ipa-bnm would this be worth investigating on cob4?

@benmaidel
Copy link
Contributor

@ipa-mig yes, we can/should test this on cob4 as soon as a new hardware is available

@fmessmer
Copy link
Contributor

Well, would #257 have solved #268 already?

I guess we should keep #248 and #249 out of this PR...as it is separate and needs more testing.
But, I'd like to finalize/accept/close #313, #257 and #268...
@mig-em @ipa-mig @destogl

@ghost
Copy link
Author

ghost commented Feb 22, 2017

I tried the ira_laser_tools and they seem to work but https://github.com/ipa320/cob_driver/pull/257 and https://github.com/ipa320/cob_driver/issues/268 are not fixed (there is still the "Lookup would require extrapolation into the past." error and they use tf1).
ira_laser_merger

In this screen you see raw3-3 scans (red, green) and the unified scan (yellow)

@fmessmer
Copy link
Contributor

fmessmer commented Feb 22, 2017

Is the following summary correct?
@ipa-mig @mig-em @ipa-bnm

cob_scan_unifier:

ira_laser_tools

  • has LookupTransform error
  • uses tf1
  • merges scans correctly (both sim and real sensor?)
  • release issue as we are not maintainer...

@benmaidel
Copy link
Contributor

Just for completeness.
There is also the possibility to use a combination of https://github.com/ros-perception/laser_assembler and https://github.com/ros-perception/pointcloud_to_laserscan to achieve a merged scan.

@ghost
Copy link
Author

ghost commented Feb 23, 2017

Additionally the parameters of the ira_laser_tools should be adapted.
Maybe the LookupTransform error should be fixed in the driver of the scanners, or is there a point in sending out scans without according transforms to base_link?

if (!listener_.waitForTransform(frame_, vec_laser_struct_.at(i).current_scan_msg.header.frame_id,
vec_laser_struct_.at(i).current_scan_msg.header.stamp, ros::Duration(3.0)))
{
continue;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ipa-mig @mig-em
Well, here we silently skip a scan that cannot be transformed. Should we at least notify in some way?
e.g. ROS_ERROR_STREAM("Not using scan during unification: " << vec_laser_struct_.at(i).current_scan_msg.header.frame_id,);

@fmessmer
Copy link
Contributor

fmessmer commented Mar 1, 2017

@ipa-mig FYI

As discussed with @mig-em, we will try a message_filter-based implementation before merging this PR

@mgruhler
Copy link
Contributor

mgruhler commented Mar 1, 2017

good idea.

@fmessmer
Copy link
Contributor

fmessmer commented Mar 9, 2017

message filter implementation is in #324
In case #324 works, this PR is obsolete

@fmessmer
Copy link
Contributor

https://github.com/ipa320/cob_driver/pull/324 is the proper way to solve #268

@fmessmer fmessmer closed this Mar 16, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[cob_scan_unifier] LookupError on start up
3 participants