Like with anything in engineering, you first need a good definition of what "success" (or "done") means. SLAM running how fast? Under what particular lighting and environmental conditions? Using what kind of processing power, what kind of weight, driving what kind of chassis, with what kind of battery lifetime?
Then, you need to break the problem backwards into sub-components, and establish parameters for those components.
Then, you need to go looking for solutions that exist to fulfill each of the tasks of those components.
It seems like you're going to other way -- "Here's a pile of parts, what can I build with this?"
That's okay for exploratory investigation, and creativity (a box of Legos!) but it's a bit harder to hit any PARTICULAR goal using that method.
So, to build "forward" like you're attempting to, you still need a way to monitor what's going on. Thus, you want to make sure that your development platform (the computer on the robot) has some kind of monitor, or remote access. X Windows over WiFi might work. A 10" LCD on the robot with a wireless keyboard/mouse may work, if it's easy to read from where you need to be to monitor.
Once you can measure and inspect everything, then it's a process of adding each component from the bottom, poking it with expected stimuli, and making sure it performs as expected.
Screw wheels to motors, and connect encoders and motor drive to motor controller. Send commands to motor controller -- do the wheels move as you expect them to?
Add a ROS program to drive your robot. Make sure it connects to the overall ROS system on the control computer. Add a component for driving the motor controllers. Make your program send the appropriate command to make the motors move half a foot. Does the robot move half a foot?
This will also make you familiar with how different processes/modules within a ROS system communicate using the ROS message bus topics.
Then, add a ROS module to read the Kinect data and display it on the monitor. Does it look okay? Can you read this from your control program?
Keep adding bits and pieces, verifying that each piece performs in the way you expect. Ideally, also verify what the piece does when you drive it outside its "sweet spot" or when it loses control or gets a bad command -- saftey is important!
