Jittery zero speed startup of BLDC using DRV8301-69m-KIT

there are several threads on this topic on the forum you can search through.
you have two separate challenges:
1. start-up of sensorless control under load, and what is acceptable/unacceptable in relation to jitter/smoothness
2. complete speed synchronization of two wheels


starting with #1

you can certainly improve your performance, but you will always have some limitations/trade-offs with the existing solution.
- you need to insure your control system can produce enough torque for the load. If you are using a speed controller I am very doubtful that this is set high enough for this motor USER_MOTOR_MAX_CURRENT (5.85). This sets the maximum output of the speed controller, which is the input to the Iq_Ref_A, which is the instantaneous peak current. But this is not the total current or the bus current, so even if 10A peak is requested that doesn't mean you will see 10A through the Vbus. Testing at higher speeds with a rated load can help you insure this value is set high enough. If you are just using torque mode (like proj_lab04 or 05a) then disregard as this variable will have no effect. You are setting your Iq_Ref_A directly.

- in user.h you want to pay attention to the following variables
#define USER_ZEROSPEEDLIMIT (1.0 / USER_IQ_FULL_SCALE_FREQ_Hz) // 0.002 pu, 1-5 Hz typical; Hz = USER_ZEROSPEEDLIMIT * USER_IQ_FULL_SCALE_FREQ_Hz


#define USER_FORCE_ANGLE_FREQ_Hz (2.0 * USER_ZEROSPEEDLIMIT * USER_IQ_FULL_SCALE_FREQ_Hz)


In the first, the "1.0" sets the frequency (+/-) where - if the flag is enabled - the angle being used for FOC will transition from the angle generated by ForceAngle to the one produced by FAST. It is important to do some testing to see where FAST is giving good enough feedback for your motor. It may be 1 Hz, it may be higher. Your FLUX value is relatively high so somewhere in the 1 to 4 Hz should work.

In the second, make sure you update to exactly as I have. This will guarantee that the frequency of rotation being used is always twice the transition frequency. This helps with repeatability and stability of start-up transition.

The next thing that really helps start-up is to avoid step inputs in the initial torque command. So if using a speed controller you would set a slower acceleration and make sure the speed controller isn't overly aggressive and saturating the output. If you are just using a torque controller you need to put a ramp/trajectory input into your software control. So instead of taking a torque/throttle request and just setting say 5A, the Iq_Ref_A input ramps from 0 to 5A at a given slope.

With these techniques most people have been able to generate consistent start-up under load.

However, because the initial rotor angle is unknown there will still be some initial rotation backwards sometimes. You can't eliminate this without doing something more. In some cases simply doing an RsRecal (with a large enough RES_EST_CURRENT) will initially force the rotor to move into alignment before you start-up. With high pole count motors this can be very effective as the mechanical rotation will be quite small. However, your motor has only 1 pole pair so this will be quite noticeable and challenging IMO.

There are techniques that can sometimes be used to find the initial rotor angle (IPD_HFI example in proj_lab21) but they only work really well with rotors that have been specially designed with high saliency. And even then, as the currents are increased to generate the torque the saliency/inductance difference reduces and it is still quite challenging to track the angle under very large load starts.

Regarding #2, I'm afraid this is an extremely challenging system requirement ESPECIALLY for sensorless. When two wheels need to provide 100% repeatable synchronized trajectories and speed it will be quite challenging without the use of sensors.


In the case of your project I would strongly recommend looking at using some type of sensors to improve your start-up and synchronization.

Thanks for the suggestions! I will test these modifications as soon as possible.

I am currently running the code under a slightly modified version of proj_lab04 (mapping throttle to Iq_ref_A). I was wondering if I can modify the code so the Iq_ref_A input ramps up at a slope as you said. Is this something built into the motorware or something I need to code myself?

The motor that I am using now has three hall sensors. As far as I know the DRV8301-69m-kit only supports quadrature encoders. Are there any ways to make hall sensors work with the evaluation board? Thank you!

Zihe Huang said:

I was wondering if I can modify the code so the Iq_ref_A input ramps up at a slope as you said. Is this something built into the motorware or something I need to code myself?

an example is not provided, but you can use a TRAJ_ module from MotorWare to accomplish this.

Zihe Huang said:

As far as I know the DRV8301-69m-kit only supports quadrature encoders. Are there any ways to make hall sensors work with the evaluation board

The EVM HW supports hall inputs. There is not a HALL example in MotorWare. We have it on our to-do list to add an example which uses HALL to start the motor then transition to FAST.

There is a full HALL 6-step example for controlSUITE projects ( DRV8301-HC-C2-KIT) that I have posted on the Motor Drivers forum before.