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.