Poor Velocity Control Tracking Performance

Support
,
1

On a bench test setup with six Myxa B0Z controllers (T-Motor U8II KV 150 motors, T-Motor FA28.2x9.2 folding propellers), we observed that some motors track their setpoint poorly at high velocities.

In the test shown below, all six drives were given velocity setpoints in steps (for five seconds each 360, 350, 340, down to 310 rad/s). Some drives (Node IDs 5 and 11) manage to operate precisely at each velocity, while other drives (Node ID 3 in particular) show significant tracking errors at higher velocities.

image
image950×473 31.1 KB

  1. Is this an indication of a deeper, possibly hardware-related issue? Both the motors and ESCs have ran for a few hundred hours.
  2. If not, what would be the best approach to tackle this issue?

See this dashboard and the config.yaml (1.9 KB) for more context.

2

Today we repeated the test, but swapped motors 3 and 11. The drive with node ID 3 thus now drives the motor that was previously connected to the drive with node ID 11, and vice versa.

The problem persists, it is still drive number 3 which tracks poorly. This leads to the assumption that the issue is controller-based, not motor-based.

image
image889×432 28.7 KB

3

Hi Lasse,

Do you use shared motor model parameters (resistance etc) for all controllers or do you run motor identification on each of them individually? Did you re-run identification after swapping the motors? If yes, how do the values compare to each other?

4

Hi Pavel,

Motor identification was ran on each controller individually, and the parameters were swapped (yakut dump, load and reboot) when swapping the motors. Parameters are fairly similar for all six motors; I will upload a dump when I’m back in the lab later today.

The Telega self test runs successfully.

Lasse

5

Hi Pavel,

these are the motor identification parameters we ran the tests with:

1:
  motor.resistance: 0.05688731372356415
  motor.flux_linkage: 0.0019611255265772343
  motor.inductance_dq: [1.9264265574747697e-05, 1.9264265574747697e-05]
3:
  motor.resistance: 0.0572023019194603
  motor.flux_linkage: 0.0019517226610332727
  motor.inductance_dq: [1.9580600564950146e-05, 1.9580600564950146e-05]
5:
  motor.resistance: 0.058905016630887985
  motor.flux_linkage: 0.001976622035726905
  motor.inductance_dq: [1.890941166493576e-05, 1.890941166493576e-05]
7:
  motor.resistance: 0.0540958046913147
  motor.flux_linkage: 0.0019711616914719343
  motor.inductance_dq: [1.9116494513582438e-05, 1.9116494513582438e-05]
9:
  motor.resistance: 0.05808626115322113
  motor.flux_linkage: 0.001976014580577612
  motor.inductance_dq: [1.9026843801839277e-05, 1.9026843801839277e-05]
11:
  motor.resistance: 0.05738101154565811
  motor.flux_linkage: 0.001977154053747654
  motor.inductance_dq: [1.9137951312586665e-05, 1.9137951312586665e-05]

Yesterday my colleague ran the identification command three more times, resulting in the three parameter files attached below.

motor-params-1.yaml (945 Bytes)
motor-params-2.yaml (942 Bytes)
motor-params-3.yaml (947 Bytes)

Edit: This is the complete configuration dump of all drives: config.yaml (24.3 KB)

6

Thank you for the parameters. May I ask you to swap all three phase connections on the ESC that is showing issues (e.g., change ABC to BCA or CAB so that the direction of rotation is not altered) and repeat the test? Alternatively, change any two phases and enable vsi.swap_ab. There is a rather exotic issue that I want to rule out.