ros_control requirements
Hi
Required info: Distro: Kinetic, Ubuntu 16.04 The robot is running on a gaming laptop and brings up kinect2_bridge, roboclaw_node and the rplidar_node and sends data over home wifi. I view the data on a remote PC via RVIZ.
Most of my experience up to this point has been with simulated robots and gazebo. I have gone through the tutorials on making a real robot and have a fully built bot IRL. It teleoperates fine and I can make maps, though my odometry appears to suffer from inaccuracy. I am trying to eliminate issues that might be causing it, such as simply not having configured my robot properly.
I have read through the wiki pages on the navigation stack and I would like to better understand at what point ros_control becomes necessary in a robot build please. I am referring to this diagram: 
.
My robot has two motors with quadrature encoders being driven by a roboclaw motion control board. it uses the custom roboclaw_node which subscribes to cmd_vel and publishes odom plus some motor status messages. It has its own PID control built in.
At what stage would the roboclaw_node appear in the attached diagram? I am not sure if I am missing something from my build. As mentioned, at present I am teleoperating the robot in order to make maps. I am not navigating yet.
This is the urdf representation of my real robot 
Now If that were in gazebo, I would put libdiffdrive in the .gazebo file and set the front caster to have zero friction and gazebo would take care of creating robot movement, which is reflected in RVIZ. However now of course, RVIZ only has the drive wheel encoder odometry to inform its position. Is RVIZ really giving me an accurate representation of movement if there is no model to inform it how the three wheels, 2 x drive plus 1 x caster, interact?
Is ros_control and RobotHW always needed in every build? Or does the roboclaw node effectively take care of everything?
