Skip to content

Acceleration with Cruise Control enabled #4

@Trigger239

Description

@Trigger239

Hello Emanuel!

I have discovered an issue with using the input target value to temporally increase the speed when the cruise control is enabled. Steps to reproduce the issue:

  1. Set FOC control method and VLT mode
  2. Apply some input value (r_inpTgt) for the motor to spin, but not at the full speed
  3. Enable Cruise Control (b_cruiseCtrlEna = 1) with current speed used as a target speed (n_cruiseMotTgt)
  4. Increase the input target value (r_inpTgt) until the motor starts to accelerate (cruise control speed stabilization is overridden by the input target)
  5. Gradually decrease the input target

The expected behavior is that the motor should slow down to the cruise control target speed, and once this speed is reached, input target value should be ignored. Actually the speed can go below n_cruiseMotTgt. Cruise Control engages again only when the input target is set to 0 (or, maybe, some small value) by releasing the accelerator.

After analyzing the Simulink model, I think I've found the problem. The anti-windup circuit in the PI controller ( PI_clamp_fixdt ) is implemented in the wrong way. This implementation works fine when satMin and satMax have the opposite signs (satMin < 0 < satMax), and usually this condition is met, but with the Cruise Control enabled both min and max values can have the same sign.

Clamping_circuit should take into account not the sign of preSat, but the actual limit (min or max) which has been hit. The integrator should be disabled (Clamp = true) when the following condition is met:

((preIntegrator > 0) && hitMax) || ((preIntegrator < 0) && hitMin))

I don't have a Matlab/Simulink installation, so I modified the code in BLDC_controller.c manually and replaced this:

  /* Signum: '<S66>/SignDeltaU3' incorporates:
   *  Sum: '<S65>/Sum1'
   */
  if ((int16_T)tmp < 0) {
    tmp_0 = -1;
  } else {
    tmp_0 = (int16_T)((int16_T)tmp > 0);
  }

with this:

  if (rtb_UpperRelop_l) {
    tmp_0 = -1;
  } else {
    tmp_0 = rtb_LowerRelop1_l;
  }

inside PI_clamp_fixdt_l() (this function is used for FOC speed mode) and two similar PI controller functions. With this modifications the input target can be used to temporally increase the speed when the Cruise Control is enabled without any problems, and the speed never goes below n_cruiseMotTgt.

I also have a question about Cruise Control and the input target. When using torque mode, the input target is used to set Iq. But with Cruise Control enabled the input target sets the lower limit for Vq. I see a potential issue here: if some Vq value causes the motor to spin faster when the same numerical value of Iq, the speed will be instantly increased after the Cruise Control is enabled, because the input target is now considered as a voltage target, not a current target. This may be not convenient for driving. Am I missing something here?

Note: I'm using your FOC BLDC controller for my custom electric scooter based on the wheels and the main board from an hoverboard. A lot of modifications have to be done to the code from hoverboard-firmware-hack-FOC in order to integrate it with the rest of the e-scooter's system (it contains some custom boards and other non-standard stuff), so I decided to write the code from scratch. The only things I'm using from your code are the BLDC controller itself and the idea on how to use MCU's peripherals (DMA, timers, etc.) for motor control. Because of that I'm opening this issue here, not in the hoverboard-firmware-hack-FOC repository.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions