search

UbiquityRobotics / ubiquity_motor

Package that provides a ROS interface for the motors in UbiquityRobotics robots
BSD 3-Clause "New" or "Revised" License
24 stars 23 forks source link

Need better resolution on motor speed in order to have better app control of path #129

Closed mjstn closed 2 years ago

mjstn commented 3 years ago

A customer has complained that his app cannot control a path smoothly on a Magni and I have determined this is because the resolution of the speed control bits we send the MCB is too course to allow smooth control of a path by an app or nav package. An app is not able to control very gentle rotations on the order of under 2 degrees per second with todays firmware.

If we wanted to solve this issue a significant task to take on would be to allow the speed values sent to the MCB to be on the order of integers that were 10x or more in value for the same given end speeds we use.

Today 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. (roughly). 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.

To resolve this issue we would have to have a new speed command only used if firmware were above some given version. This new speed message still would use 2 packed 16-bit integer values but the scale of units would be such that a value of lets say 16 times larger would be used for any given speed. So for this example of 0.14M/Sec today using a setting of 12 the new speed control message would use something like 192 and in that way minimal resolution on angular rotation would improve 16x

dorkamotorka commented 3 years ago

I think you made a great point. One thing for breadcrumb is that minimal linear and angular velocities depend also upon the payload that is on the robot.

I would propose for Gen6 to have some kind of mass/force sensors such that we could determine the payload on the robot and have our configuration parameters dependent upon that.

This would indeed come in useful maneuvering since the Motor Controller PIDVs need to be different. All the other parameters such as minimal velocities should stay the same, since the Motor Controller should still be able to handle it with updated PIDV values.

MoffKalast commented 3 years ago

I mean, it's definitely something to implement but I have some doubts regarding what it would actually fix in practical terms. After all it did take a customer to figure it out after years of selling the robot. It's not like our localization is good enough for this to be the bottleneck when trying to move around accurately.

mjstn commented 3 years ago

Thanks for the inputs so far. I mostly wanted to make all 3 'team leads' be aware of this because I think it has sort of come up but not really had root cause be identified. Aisle mode also 'waddles' along with obvious corrections slowly happening and that too may be due to this granularity.

mjstn commented 2 years ago

I feel this is best pushed out to Gen6 because it would have significant risk of breaking things (badly) and it has very little real benefit right now.

closing this now so we remain 'realistic' in what we try to improve on current platform of Magni