Fix: Correct motor control logic in cmdVelCallback function

[anurag-choudhury]

This PR resolves an issue in the cmdvel_callback function where the second motor was not being controlled correctly, causing improper motion of the robot.

Problem:

• The previous implementation only partially controlled the second motor, leading to one-sided movement.
• The logic for combining linear and angular velocity to compute motor speeds was not functioning as expected.
• Solution:
• Updated the cmdvel_callback function to compute the left and right motor speeds correctly based on the robot's linear and angular velocity:
• Linear velocity (linear.x) contributes equally to both motors for forward/backward motion.
• Angular velocity (angular.z) introduces differential speeds to the motors to enable turning.
• Ensured the correct behavior in both open-loop (power control) and closed-loop (RPM control) modes.

Impact:

• Fixes hardware behavior by ensuring both motors respond appropriately to combined linear and angular velocity commands.
• Improves overall motion control and accuracy in hardware tests.
  Testing:
• Validated on physical hardware:(ROBOTEQ FBL2360TE)
• Forward motion (linear.x > 0) moves both motors at equal speeds.
• Turning (angular.z ≠ 0) results in differential motor speeds.
• Stopping (linear.x = 0, angular.z = 0) halts both motors.
• Tested in both open-loop and closed-loop modes.

Additional Notes:

• Logs added for better debugging of motor commands.
• Ready for feedback or additional improvements as needed.

Checklist:

• Code tested successfully on hardware.
• Logging added for debugging.
• Documentation and comments updated for clarity.

[CJdev99]

Thanks for the PR! What controller are you on?

[anurag-choudhury]

well i am using diff_driver controller on ROBOTEQ FBL2360TE motor driver , another commit i have to make in this pull req for the opposite direction rotation when teleoperating just put the "-" sign before the calculation value..
also another issue i am getting in this package is odometry seems to be fine but in real world the laser scan are moving as the bot moves, i am currently working on the odom calculation by myself using the encoder ticks per meter , lets see if that works or not