Good day folks,
I’m running our magni(s) at 0.14 m/s linear (fairly slow), and after testing the turning angual movements with teleop_twist_keyboard, I’ve noticed the lowest angular turn I can do is around 0.028. ie. If I publish to cmd_vel a 0.025 (for angular z), it will have zero impact on magni (it will keep moving straight).
Is there a way to allow for a more sensitive input? We’re trying to do very fine adjustments to keep magni moving as straight as possible, and require a lower fine tune. Is this possible?
Thanks,
Kris
Probably not the best idea, but you can use dynamic reconfigure to change the wheel radius multipliers in the motor node, which will let the robot veer ever so slightly to the left and right depending on which wheel you define as larger.
It’s not exactly intended to be used this way but I think that’s the only way you’ll be able to do it right now.
I will look into why this limit happens. That is in the area of 1.6 deg per second rate and as such is not felt to be an ‘extremely low’ rate. It is a very mild rate. Anyway, I’ll dig in a bit.
On the wheel multipliers, they were not designed to be a realtime control so I’m not sure how often we re-evaluate and use new values. I have also not looked into for some time where that multiplier is applied but I suspect you would be also impacting odometry. Hold off on that till we discover root cause for you perhaps.
Thanks Mark, look forward to your response.
It can all be recreated using the teleop_keyboard app. I had understood that the angular-Z value, ultimtaley changed the set point of magni as far as guidance goes. If this was the case, I wouldn’t expect there to be any lower limit. (ie. If I sent 0.01 three times, that would be the same as sending 0.03 once).
Cheers,
Kris
I am able to see the sort of thing you are seeing.
What you describe is the effect of motor speed resolution at the level of the MCB firmware.
The MCB firmware is sent integer values for speed control. A single count for speed control is on the order of 0.02 meters per second. (these are not exact, just basic ballpark numbers for illustration). At a linear speed of 0.14M/Sec the motor controller gets a count of about 12 for right and left motor. If you set angular (using e and c keys) to a value of around what you found of 0.025 range then one motor can get a count of 12 and the other a count of 11.
So you are seeing the resolution quantization if our motor controller.
This resolution limit pre-dates my history with the motor controller so I think what you are discussing is more on the order of an enhancement to how we do our control at the level of the MCB. It is not an unreasonable request although it has not come up yet in the past.
This is a very good find and I thank you for pointing out this limitation. I am the right person to grasp this issue and recognize how it came about.
You can see this yourself if you were to pull the ubiquity_motor code into catkin_ws/src with a git clone and then add these debug lines to MotorHardware::writeSpeedsInRadians().
Add these if you want to see what I am saying just after left_speed and right_speed are set.
if ((left_speed != 0) || (right_speed != 0)) {
ROS_INFO(“DEBUG: radSpd: %5.3f %5.3f in motSpd: %d %d”, left_radians, right_radians, left_speed, right_speed);
}
If you are not familiear with what to do from there to make this code active I can elaborate.
Then when you run the code these lines will come out (at a high rate) when motor speed is non-zero and you can view them from command line like this from /home/ubuntu
tail -f .ros/log/latest/rosout.log | grep radSpd