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

Complete global localization with gps and fused sensor data #269

Open
wants to merge 1 commit into
base: user/nico-palmar/odom-coord-frames
Choose a base branch
from

Conversation

nico-palmar
Copy link
Contributor

I was having huge problems with fusing the global data... literally most of last term. Turns out that changing from using the default gazebo world fixed it... so as you can see I've changed it so that we are not just launching the default gazebo world when we call the gazebo launch file.

The coordinate frames are now correctly set up in sim. Essentially, we have the map -> odom transform (in this PR) as well as the odom -> base_link transform (in my last PR). Below is a video, where you can see the map and odom frames.

Screencast.from.2024-05-20.03.52.17.PM.webm

For more context here, I've shown the TF tree and how the coordinate system of the rover is set up below.
Screenshot from 2024-05-20 15-53-43

This shows the transforms that I am talking about. Essentially, we are doing state estimation here, by having a odom -> base_link estimate done with the continuous data sources (the IMU and wheel odometry), as well as the global estimate of map -> odom being done by all data sources (GPS, IMU, and wheel odometry). State estimation allows us to use a probablistic estimate of our environment, a dynamics model for our robot, and update our beliefs based on sensor data. We use the local estimate to generate continuous estimates (since wheel odometry and IMU do this), but these continuous data sources drift (to clarify it's not actually continuous, just running at very high frequency of data capture).

To account for this, we use a GPS for global localization, which corrects for the drift in the other sensors, but runs at a much lower frequency (so the data coming from the GPS is not continuous, it is more discrete).

@nico-palmar
Copy link
Contributor Author

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.

1 participant