So the most important thing to keep in mind when looking at ROS-based designs is that it's meant to be very modular. This hopefully simplifies the task of automotonously controlling a robot into smaller problems that are a little easier to solve, so the problem goes from "autonomously controlling a robot" to "sensing the robot's position in the environment", "moving the robot", and "figuring out where to move the robot based on its position". "Sensing the robot's position" is broken into "calculating wheel odometry", "reading from the IMU", "calculating visual odometry", and "combining all the data to get an accurate robot pose (ROS's term for position and orientation)" "Moving the robot" is broken into "calculating the commands to send to the ESCs", "sending teleop commands", "letting teleop override the autonomous controls" and "sending the commands to the ESCs over CAN" "Figuring out where to move the robot" is broken into "figuring out how to move the robot to a new pose" and "figuring out the next pose to move the robot to"
Unfortunately these don't quite map to packages, although I guess if you were really tried to you could.
Packages are basically just containers for making programs that will run as ROS nodes, along with launch files that let you easily specify how to run the ROS nodes, because generally there's parameters and plumbing you need to do to get the nodes configured correctly, and to get them to communicate with each other.
Many of these steps are at least partially done using ROS-provided packages, so they're only mentioned in package manifests, which list a package's dependencies, and launch files, which are ideally what actually run when you start up the robot.
When you run roslaunch <some-package> <some-launchfile>, it'll open up that launch file, and run all the nodes specified in there, using the parameters specified, connecting subscribers and publishers as specified.
It'll also run other launch files that are included in the launch file, which is how you start all the systems on the robot using one launch file.
Launch files are pretty important so I'd recommend reading the documentation on them.
lk_base does (or would've done) all the low level communication with peripherals, such as the CAN bus to talk to all the ESCs and the serial to the Arduino to whatever that was supposed to be connected to.
This package does the "calculating wheel odometry", "calculating the commands to send to the ESCs", "sending the commands to the ESCs over CAN", and "reading from the IMU" (not currently implemented).
To ensure close to real time motor control, this package uses ROS's controller packages to provide the feedback loops for each of the actuators on the robot.
These are a little convoluted and require some C++ programming, but in the end they're configured somewhere and subscribe to a bunch of topics that you can use to control them.
One of these, the diff_drive_steering or whatever it's called, also spits out wheel odometry data.
lk_navigation eponymously handles anything related to navigation.
The launchfile includes a ukf_localization node that does all the sensor fusion-related stuff using an unscented Kalman filter.
You don't need to know what an unscented Kalman filter is, you just need to know to configure this node correctly and to check its output to see if it's track the robot's position fairly accurately.
All the navigation is done using another one of ROS's prepackaged nodes, move_base.
This takes in the point cloud and odometry data, and a set of topics for sending goals, and publishs \cmd_vel steering commands to move the robot closer to the goal it's sent while hopefully avoiding obstacles.
This also includes rtabmap_ros, which is the flagship SLAM node for ROS as far as I know, at the time I was writing the code for it.
This essentially generates visual odometry, which should ideally be the most accurate representation of the robot's position that we have.
lk_control only contains the command multiplexer; the README is fairly inaccurate, and a lot of what's mentioned there has been moved into lk_base.
Basically this node solves the problem of switching between autonomous and teleop modes; it takes in commands from both autonomous and manual sources, and decides which ones it should forward to the controllers to actually guide movement.
I think right now it basically accepts autonomous commands until it receives a teleop command, and then it'll ignore autonomous commands and only forward teleop ones.
If you guys want to keep using this package, it's vital to update it whenever the control scheme changes, like when an actuator's added.
lk_teleop provides a small program that can be run remotely that can talk to the ROS nodes running on the robot.
The exact configuration is kind of annoying and hopefully it's written down somewhere, otherwise I'd expect you guys to take a day or two trying to figure it out again.
It's pretty simple, but at the same it does use some kind of advanced programming ideas.
It uses Linux's joystick interface to get the commands from an XBox One controller plugged into it, and then just generates messages for the right topics to execute those commands.
The details are here if you want more info about it: https://www.kernel.org/doc/Documentation/input/joystick-api.txt
I've been kind of ignoring this in the previous paragraphs to simplify things, but a lot of the nodes mentioned about rely on having an accurate TF model of the robot to function.
These let it know where various sensors are relative to the frame of the robot, so that the data from these sensors can be transformed into proper frame of reference, and it's also maybe used for calculating the wheel base, along with mapping point cloud data from the Zed into the robot's frame of reference.
This is provided by lk_description, and is used with the tf data published by the different joint controllers to ensure every component has an accurate view of the robot.
sirdigsalot was going to have all the high-level logic for the robot.
It'd talk to the nodes packaged in lk_navigation and lk_control to send commands to the different actuators, and it'd monitor a bunch of topics, like its position in the arena and the state of some of the actuators, to figure out what it'd do.
I'd strongly recommend against trying to use a finite state machine (FSM) to do this.
FSM's are very easy to mess up, and hard to debug, so I came up with a different approach; basically run all the logic on a separate thread.
Each function call would block until it's completed, and the code would be much similar to normally written code than a FSM machine would be.
To do this you need to write a lot of small functions that correspond to each smaller action that needs to be completed, like a function to send a command to move_base and wait for the robot's position to get within 5% of where it was meant to be, or return with an error code if it doesn't reach that position in some amount of time, or a function that starts up the bucket ladder and returns either immediately or when it gets up to speed.
can_talon_srx_ros was just a bridge to get communication across the CANbus.
It doesn't have any nodes, it's a C++ library that was going to be used by lk_base to talk to the motor controllers.
It looks like CRTE already really an official library to do this that you guys already found, so definitely use that over this one.
orb_slam is just an alternative to rtabmap. I think it ended up being a lot less accurate than rtabmap so you can probably remove it or just not use it.
zed-ros-wrapper is just SteroLab's ROS package for the ZED camera.
It generates all the point cloud stuff