Mismatch of reference current and uboard current

Hi, I noticed that at direct current control, the actual current differs from the reference current. I run the uboard and motor with kp and kd set to zero in order to set a constant current without using the uboard-pd-controller. The setup is a flywheel disc attached to the actuator (mass 0.658 kg, inertia 0.00741 kg m^2, radius 0.150 m). This leads the actuator and a mounted inertia mass to accelerate. When reading Iq from the data stream coming from the uboard-PC communication, I noticed that with increasing velocity, the actual current decreases. This is unexpected because I have set a constant reference current. I also notice a very strong noise up to 80% of the reference current. The attached plot shows this behavior.

Can anyone explain this behavior? Is this a build-in friction compensation (which does not make sense because friction should increase with higher velocity)? Or is there a velocity limit implemented in the motor driver? Why is there such a strong noise at the current?

Best and thank you very much
Ferdinand

Hello @ferdinand-wood,

There are numerous phenomena that could explain this, and they are all related to the way the motor is controlled.
My best guess is that the FOC is not able to track at high velocity. To regulate the Iq current, the FOC algorithm needs to know the position of the rotor and generate sinusoidal current in phase with it. Even if Iq_ref is constant, since the frequency of the current phases depends on the velocity, there are bandwidth limits of these methods related to PWM frequency, encoder filtering delay, control cycle etc.

To operate at high velocity, we need to switch from FOC position control to open loop velocity control. This is what is done in most of the Quadcopter drones for examples. Here the phase frequency is directly proportional to the desired velocity and do not depend on rotor position.

For our robotic applications, we are generally not interested in high velocity, but in position, velocity and torque control as low speed with maximum efficiency, and this is what the FOC offers.

Are you interesting in high speed rotation, or was this more for identification of your actuation?

Also, know that we are working on a new version of the uDrivers that should offer higher bandwidth for the FOC.

Hopes this helps,
Thomas.

1 Like

Hi Thomas, thank you for the response. This sounds reasonable. Another idea we had was that is related to the current limitation of the power supply. Although the current limitation of the power supply is 13 Amps, it still might cut the very high current peaks that occur at high velocity.

The attached plot shows the measured current consumption with the same experiment (constant current control), but with different current limits from the power supply. It might give a hint that the current drop happens earlier when the current limitation is lower. What do you think about this?

We did the experiment for identification purposes so we are not planning to such use high velocity at the robot.

Best
Ferdinand

You are right, the power supply limits can also explain this. If current clipping is happening on the power supply, the input voltage will decrease. Note that the maximum velocity of the motor is also related to input voltage.

Many thanks @thomas.flayols for your help. After a few other tests it was clear that the current clipping has caused the current dropping at high velocity. Using a different current source has solved this issue.