Set up localization

[juliaschatz]

The two navXs, wheel odometry, Decawave, and Aruco info should be combined in an EKF to get an accurate position estimate. There is some preliminary work done for this already in the repo. The core of this will be an ekf_localization_node from robot_localization. Recommended reading: http://docs.ros.org/melodic/api/robot_localization/html/index.html Simple explanation of Kalman filter: https://www.bzarg.com/p/how-a-kalman-filter-works-in-pictures/

[juliaschatz]

Main ticket for Localization milestone.

[JWCS]

See repo/src/bigrdigr_control/config/, there are two files ekf_params.yaml and ekf_map_params.yaml. In ros, there are 3 (main) reference frames: robot base_link/base_footprint (the "point" representing the robot), the 'world' frame (where the origin is in your map, ex, a corner of the room, or the trough/field), and the 'odom' frame (this starts out at where the robot starts out). Basically, all continuous data, like wheel odometry/rotation and imu tries to make a frame transformation (an offset + rotation) from the robot to the 'odom' frame, so the robot only moves in continuous space. Then there is something that finds out where the robot is in the 'map' frame, and computes the transformation from 'map' to 'odom'. For example, for indoor (with lots of walls) localization (with some sort of depth cloud or laser scan data) is 'amcl', which has this nice picture: https://wiki.ros.org/amcl#Transforms For outdoor navigation, or in general, you use 2 ros robot_localization (r_l) ekfs: one takes in odometry & imu to compute where you are in the odom frame, then another takes "jumpy" gps/decawave/amcl whatever data and that data to publish a map->odom frame transformation. That's what each of the two config files are for. They should be moved to the more appropriate place, but it made (r&d prototyping) "sense" to put them there last year (we were rushing). For more on frames: https://www.ros.org/reps/rep-0105.html