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

simulated odometry leads to poor map (bag attached) #488

Closed
BrannonKing opened this issue Aug 22, 2017 · 4 comments
Closed

simulated odometry leads to poor map (bag attached) #488

BrannonKing opened this issue Aug 22, 2017 · 4 comments

Comments

@BrannonKing
Copy link

I've been struggling to use simulated odometry with the current code (current as in a number of builds from the past 30 days). My Cartographer builds from last year seem to work better in that regard. I still get very good maps with CeresScanMatcher+Laser+IMU. I also (not in real time) get good results with OnlineRealTimeScanMatcher+Laser. I've attached my bag and config files to reproduce the "shaky" map from my odometry. I would appreciate it if someone could help me clarify whether my odometry data is complete junk or the transforms are wrong or whether the bug lies somewhere else. I have attempted to reduce the odometry influence with the weights, but they don't seem to affect the final output.

bag.zip

@jihoonl
Copy link
Contributor

jihoonl commented Aug 24, 2017

Could it be relevant to cartographer-project/cartographer#467?

@BrannonKing
Copy link
Author

BrannonKing commented Aug 24, 2017

It's true that the changes to incorporate odometry into the pose extrapolator could be related, but I don't think the odometry has worked right for several months -- pre "extrapolator" times. In thinking about this further, it may be that my odometry is just too frequent for Cartographer. I've been bringing it in at 90 to 100 Hz. It could be related to the Cartographer issues dealing with high-frequency data causing velocity estimates to go bad. I've previously used 66Hz odometry without a problem, though.

I'm not a ROS1 bag expert. Is there some easy way to play that bag whilst reducing the odometry down to 10Hz? Wouldn't I need to aggregate the odometry that is there somehow?

If our odometry comes more frequently than the laser, does Cartographer aggregate it?

@jpapon
Copy link
Contributor

jpapon commented Aug 31, 2017

You can do something like this to produced an odometry topic throttled to 50hz: "rosrun topic_tools throttle messages /odometry 50.0 /odometry_throttle" if you're using the online node. Offline, you'd have to either just run the bag with this running and record it, or use something along the lines of the code in the rosbag cookbook to create a new bagfile which has every n odometry messages dropped.

@BrannonKing
Copy link
Author

I've tracked down most of my odometry issues and written them up here: cartographer-project/cartographer#534. I'm certain it's not a problem with the ROS node portion.

SirVer added a commit to SirVer/cartographer_ros that referenced this issue Oct 17, 2017
SirVer added a commit to SirVer/cartographer_ros that referenced this issue Nov 7, 2017
@SirVer SirVer mentioned this issue Nov 7, 2017
8 tasks
doronhi pushed a commit to doronhi/cartographer_ros that referenced this issue Nov 27, 2018
…ject#488)

Also removes the no longer used range data from trajectory nodes
in 2D.
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

No branches or pull requests

3 participants