ros-controls
Feature Request: Add Boolean Parameter to Switch Traction Joint Velocity Units Between rad/s and m/s
I noticed that in the tricycle_controller, the control unit for the traction_joint velocity is in radians per second (rad/s), which also applies to the corresponding speed in the AckermannDrive. This is problematic because many trailers modeled after this controller input speed in meters per second (m/s), leading to inconsistencies and potential errors in control.
Solution: I propose adding a boolean parameter use_wheel_vel_in_rad_ to allow switching between using rad/s and m/s for the traction joint velocity. When use_wheel_vel_in_rad_ is set to false, the controller should interpret the speed inputs in m/s instead of rad/s. This would provide greater flexibility and ensure compatibility with various trailer models that use m/s as their speed unit.
tricycle_controller.cpp
line 91
auto_declare<bool>("use_wheel_vel_in_rad", use_wheel_vel_in_rad_);
line 207-209
if(!use_wheel_vel_in_rad_){
Ws_write = Ws_write* wheel_params_.radius;
}
Hello!
Can you give some examples of these trailer models?. I'm just not sure about the convention with m/sec because ultimately the lower level hardware mostly support the rad/sec than m/sec as it depends on the radius of the wheel it is attached to.
What do you think?
Hello!
Can you give some examples of these trailer models?. I'm just not sure about the convention with m/sec because ultimately the lower level hardware mostly support the rad/sec than m/sec as it depends on the radius of the wheel it is attached to.
What do you think?
For example, in a trailer like the one below, the unit of speed for control commands sent via can bus protocol is m/h, because of the speed sensor that is included with the car, I think maybe m/s would be a good choice, but of course, what you are saying is very much for most of the low level hardware is rad/s. So this is just a suggestion.
Got it. What would be the feedback from the wheels? Will it be in m/sec as well?
Got it. What would be the feedback from the wheels? Will it be in m/sec as well?
The input and feedback from the can bus is actually in m/h and deg for wheel speed and steering respectively, but I have converted this to m/s and rad in the hardware interface converts them to m/s and rad. for wheel speed I think maybe m/s is a bit more intuitive in this model.
I don't think that changing the unit for a revolute joint defined in the URDF to m/s is a proper way of solving this. Why not just converting them inside the hardware component, if the custom hardware wants m/s for commanding via CAN? Then you still work with a valid description on the ROS-side, including simulators etc.
I agree with @christophfroehlich it doesn't sound right to me as well. The best option is to handle it at the HardwareComponent Level
I don't think that changing the unit for a revolute joint defined in the URDF to m/s is a proper way of solving this. Why not just converting them inside the hardware component, if the custom hardware wants m/s for commanding via CAN? Then you still work with a valid description on the ROS-side, including simulators etc.
Ok, I have another question then with the linear and angular velocities posted with NAV2 to the topic cmd_vel for robot navigation, I also need to convert the linear velocities to wheel revolutions rad/s right?
no. The controller (diff_drive, or tricycle in your case) calculates the wheel speed from the twist command using the kinematics of the robot.
Maybe this is the solution for your case: If your trailer excepts already a twist as input instead of the wheel speeds, then you can write a simple forward command controller accepting a twist message and your hardware component, which exposes these two inputs (linear velocity, angular velocity).