First of all, usually the "command" to give to any robot is a publisher geometry_msgs/msg/Twist
geometry_msgs/Vector3 linear
geometry_msgs/Vector3 angular
OR geometry_msgs/msg/TwistStamped
std_msgs/msg/Header header
geometry_msgs/msg/Twist twist
which essentially tells to robot to follow a reference velocity in all 6 degrees of freedom:
$\vec{v}_{linear} = \left(\dot{x}~\dot{y}~\dot{z} \right)^T$ $\vec{v}_{angular} = \left(\dot{roll}~\dot{pitch}~\dot{yaw} \right)^T$
any rigid body has. The ROS teleop keyboard for example publishes Twist-Messages. Convention(!) is the topic name cmd_vel for this Twist or StampedTwist message.
Now of course, you need to understand this is the reference(!) to a low-level controller, which will try and follow this reference velocity. So, the actual robot might move differently (due to control errors or kinematic constraints, especially non-holonomic constraints).
What is usually fancifully called Sensor Fusion is a simple State Observer of which there are a couple of well-known ones: The Luenberger/State Observer which is described in the linked Wiki above, and three Kalman Filter:
Standard Kalman
Extended Kalman (EKF)
Un-Scented Kalman (UKF)
which essentially all work by correcting prediction error. The scope of the answer is too small to go into details, but I invite you to read about those concepts in the provided links, as they will clear things up.
Now this is a scheme of any observer.
Here's a translation in "Robotic Terms":
Plant = Robot
Reference Signal = Twist/StampedTwist
Controller = Low-Level Controller
Output = Sensor Data (Gyro, IMU etc.)
Observer = Observer (Kalman, Luenberger etc.)
The output of your Observer is the State Estimate - which usually for robots means the estimated current position and velocity (relative to a fixed frame - usually called odom).
I sincerely hope this clears it all up. And here's what it looks like "inside" the Kalman Filter:
which - again - minimizes prediction error by correcting iteratively.