search

RobotCasserole1736 / RobotCasserole2022

RobotCasserole team 1736 Rapid React 2022 software
MIT License
4 stars 2 forks source link

Tune Drivetrain Closed-Loop for Wheels #42

Closed gerth2 closed 2 years ago

gerth2 commented 2 years ago

Set up the azmth in test mode with the function generator to be type zero (constant, 0 command)

Set up the wheels in test mode with the function generator to have a 0.15 Hz sine wave. Start fairly slow on the amplitude, maybe 1/10th of the robot's speed. zero offset.

Set the robot in a place where it can drive forward and reverse in a clear path

Set all Drivetrain Module Wheel gains to zero.

Run the robot in test mode, disabling between each run

Start with kS. Make this as big as you can without seeing robot motion. This parameter represents the minimum voltage to overcome static friction. It should be close to zero, but not exactly zero.

Move on to kV. This should be something slightly higher MAX_V/MAX_SPEED. It represents the nominal voltage required to achieve a commanded speed. Its value is primarily the result of the physics of the motor (hence the provided value above), but also encompases the inefficiencies in the gearbox and the wheel/carpet interaction.

Move on to kP. Set this as high as you can get without oscillation or uncontrolled jittering.

Currently, the drivetrain motors are inverted on the left side. This seemed to work experimentally.... but my quick tests showed they actually should be inverted on the right side. I am not sure why this is. There is a chance the feed-forward calculation in the RealTalonFX class is missing a -1.0, and the motor inversions need to all be swapped? This will be most noticeable when you bring in kP, if it appears to be fighting the feed forward and making things worse.

gerth2 commented 2 years ago

For the math-inclined, in closed loop, motor output is calculated via the following equation:

V_motor = kS * sign(Des_Vel) + kV * Des_Vel + kP * (Des_Vel - Act_Vel)

Des_Vel comes from the driver or the autonomous routine or the function generator.... wherever. It just represents how fast the motor ought to be spinning.

Act_Vel is measured by a sensor internal to the motor.

The first two terms are the "feed forward" portion, as the only depend on the Desired velocity, and no measurement. the Last term is the "Feed back" portion, because it involves Act_Vel too (which, in turn, implies the effects of the voltage on the robot are "feed back" into the control algorithm in the next loop).

gerth2 commented 2 years ago

A kD and kI term are also available, but I"m hoping they stay at zero. kD might be needed to help reduce overshoot or oscillation induced by a large kP in certain situations.

If we're not quite hitting the target, sometimes kI can help.... but I'd recommend first fiddling with kV - bumping it up slightly should have a similar effect to adding nonzero kI.