robot_localization

Need to understand this package, which is an implementation of the Kalman Filter.

https://docs.ros.org/en/melodic/api/robot_localization/html/index.html

“All state estimation nodes track the 15-dimensional state of the vehicle: $(X,Y,Z,roll,pitch,yaw,X\dot{},Y\dot{},Z\dot{},roll\dot{},pitch\dot{},yaw\dot{},X¨,Y¨,Z¨)$.

This made me wonder, why isn’t angular acceleration part of the state?

• https://aviation.stackexchange.com/questions/98496/why-do-we-measure-translational-accelerations-but-angular-velocities-in-an-imu-a

Also, ee

Resources

• ROSCon 2015 Hamburg: Day 2 - Tom Moore: Working with the robot localization Package
  • This is ROS1, but the knowledge is applicable

So there are 4 very important variables

        map_frame: map              # Defaults to "map" if unspecified
        odom_frame: odom            # Defaults to "odom" if unspecified
        base_link_frame: base_link  # Defaults to "base_link" if unspecified
        world_frame: odom           # Defaults to the value of odom_frame if unspecified

In the case of MIT-PITT-RW

        map_frame: map              # Defaults to "map" if unspecified
        odom_frame: ltp            # Defaults to "odom" if unspecified
        base_link_frame: base_link  # Defaults to "base_link" if unspecified
        world_frame: ltp           # Defaults to the value of odom_frame if unspecified

The world_frame parameter specifies in what frame you want to estimate the position of your robot. What made clear was this github issue.

What is the point of the world-frame?

The world_frame parameter specifies in which coordinate frame you want to estimate your position, i.e., whether you want to compute a map→base_link transform or an odom→base_link transform. Most people use odom unless they are fusing absolute pose data, e.g., GPS. The value of the world_frame parameter must match either the odom_frame or the map_frame parameter. Source

Still a little confused on how EKF works when using the map frame??

• like why does it care about the odom frame if we are using the world frame?

It says

  #     3b. MAKE SURE something else is generating the odom->base_link transform. Note that this can even be another state
  #         estimation node from robot_localization! However, that instance should *not* fuse the global data.

Ah i see, my confusion is resolved here.

What the odom and map filter instances are doing is creating transforms from odom→base_link and from map→base_link, respectively. tf represents your transforms as a tree, though, so we can’t have two parents to base_link. To get around this, the map instance of ekf_localization_node looks up the transform from odom→base_link that the odom instance of the EKF is generating, and uses that transform, along with its own (internal, unpublished) map→base_link transform, to generate a map→odom transform. This means you can still transform from map→base_link in other nodes that may require it.

So that is why a transform must be published from odom->base_link, by cnovention more. Like something will already be publishing odom->base_link, so the map->base_link is simply a correct of what odom->base_link says.

navsat_transform_node

The navsat_transform node converts the GPS coordinates (lat/lon/alt) into a local coordinate system using a projection method, typically transforming them into UTM coordinates or another metric-based system.