Motor's torque and RPM is not suitable for automatic control

[dsryzhov]

Hi Jack,

In this and several other issues I plan to share my experience from last two weeks.

Starting from the most worst thought.

This unexpensive motors does not suit for application of automatic control. They are too fast for home usage. And their have to small torque for automatic control.

For my my motors max rotaton is 21 rad per second. It's 3.34 rotation per second. Or 200 rotation per minute (RPM) With this max RPM speed of the car is 0.68 m/s Max angular velocity of my car is 11.5 rad / s

Because of the motors small torques they star to rotate only afte PMW is higher some threshold. As a result minumum speed of my car is 0.45 m/s Minumum angular velocity of my car is 8 rad/s

When disks with 20 holes is used for rotation sensors we can receive wheel' angular velocity estimation every 27 ms (for max speed).

I think it would be correct to use 27 ms as a period for automatic control. The same frequenciy as for angular velocity estimation. In my experiments I used 20 ms for control period.

When motors rotating with minimum speed car will move

• in right direction : 0.009m (about 1 sm)
• in angular direction 0,16 rad = 9,16 grad

as a result of such fast rotation it's very hard to make orientation with greater accuracy than 9,16 grad as a result of low torque it's very hard to rotate precisely over small angles during linear motion to a goal position. it's possible to rotate for 90 grad with 9,16 precision (10%). But it's very hard to rotate to 10 grad trying to correct motion Because of motors big RPM oscilattion will start near goal orientation.

All this conclusion are not theoretical but from my real world experience of last two week.

I think about changing my motors to these one

Please correct me if I am not right with my conclusions.

Regards, Dmitry

[dsryzhov]

I also don't want to change motors ) So trying to think more.

Now I starting understand why navigation2 dwb2_controller uses arcs as trajectories but no to rotate to goal and move to it.

This strategy (rotate and move) is used in pure_pursuit_controller. I've used as it has more simple controll strategy than dwb_controller. see pure_pursuit_controller implementation in my repo

Now I understand that pure_pursuit_controller is more complicated to implement in practice. Because it's very hard to rotate precisely especcialy when there is a contorol latency.

I assume now that moving via arcs is the right strategy because

1. it does not assume to rotate via precise angles. It only needs to update stable wheels angular velocities (via PID control). PID control can be implemented on ESP in real time (without control latency)
2. I assume that less frequency for position control can be used. Because we need only to set motion via correct arc and don't need to update it frequently

DWB controller assumes robot kinematics restrictions. (they occurs from motor restrictions also). One of the restriction is a minimum radius of arc that robot can move. It's defined by maximum\minimum angular velocity of robot' wheels. For my motors the minumum arc radius 33 cm. Also min\max acceleration should be defined from experiments.

DWB controller publish cmd_vel command than contains linear and angular velocities. It should results in stable motion over an arc.

From them w_l and w_r are calculated. Based on them PWM are set for motors. I've already implemented PID control to adjust motors PWM based on sesor measurements to obtain precise angular velocities of wheels.

I've tested it for straight motion. Works great. Now I undestand that PID control will result in correct motion via arcs also.

Robot kinematics parameters should be set correctly via dwb parametes. In this case we will receive only possible cmd_vel that will not result in PWM value greater max (1) or less values (defined by minimum wheel'angular velocity)

Will try to adjust dwb_planned parameters and test it one more time. If control latency will create problem I will try to implement simple control strategy for position control on ESP32.

Regards, Dmitry

[dsryzhov]

In fact I am not right in the comment above about pure_pursuit_control strategy. I've described my modification of algorithm to more simple strategy : rotate precisely and after that move. This my reductiction occurs not implementable.

Originally pure_pursuit_control algorithm also moves robot via arcs folowing global path. Every control phase pure pursuit controller selects point on the global path on the predefined distance threshold from current position.

Based on the selected goal pose it calculates arc parameters that should move robot to this point on the cureent control cycle. But it's not always possible. If needed angular_velocity greater max_angular_velocity, the latest is used. In this case robot will rotate a litle to the goal pose and on the next control phase new arc will be selected. On the next control phase new goal pose will be selected new arc will be calculated and motion updated.

Fot pure_pursuit_controller

• desired_linear_velocity

• max_angular velocity for car moving with desired_linear_velocity

• distance threshold for selecting goal_position on the path

• desired_linear_velocity

desired_linear_velocity = 0.5(min_speed+max_speed) for my car desired_linear_velocity = 0.5 (0.45 + 0.68) = 0,56 as 0.68 - is a maximum speed with no load, I will use desired_linear_velocity 0,53

• max_angular_velocity for the arc

car max_angular_velocity should be selected with the restriction for the result wheels angular velocities to be inside region [min_angular_vel, max_angular_vel]

with a desired_linear_velocity = 0.53 max possible angular velocity for my car will be 1,2 rad/s with this value left wheel angular velocity will be equal to the smallest possible value and right wheel angular velocity will be equal to maximum possible value or vice versa depending on rotation direction

• distance thresold goal_pose selection

Fot pure_pursuit_controller to work correctly distance threshold should be selected comparable with robot min radius arc.

For my robot this radius 33 cm. If 2R=66 cm is used for distance threshold when selecting next goal pose on the path robot will be able to move to this goal_point from any current orientation.

I think less values can be used assuming that when folowing a path robot orientation is nearly the same with the path orientation.

I think distance threshold = R will be Ok.

Will try all these assumptions

[dsryzhov]

implemented pure_correct pursuit_control strategy on esp32 tested it, sending to esp32 /hadabot/goal_pose it works! it really moves by arc and get to goal_position.

Now rotation and linear motion occurs at the same time. Because of this there is no problem to rotate to pricise angle. rotating during linear motion solves low torque problem!

[jackpien]

Yes - 21 radians per second is a bit too fast for the inherent latency in the architecture. The motors in the Hadabot kit, with the 6v battery pack, have a max 12 radians per second turn rate.

In any case, thanks for all the data points. Will close the issue.