Sensor vs Sensorless pros & cons

[bikerpete]

I've read a variety of posts referring to sensorless controllers but have failed to identify any significant advantages or disadvantages other than:
Pro

• No need for sensors. Duh

Con

• Startup from stationary can be less than ideal. ie sometimes it wont, or it does but with reduced torque.

There's no such thing as a free lunch, so I figure there have to be others or no one would bother developing sensorless controllers.
Does efficiency change?
Is field weakening as effective or not? (it seems it is, but not totally sure).
Are there specific conditions other than startup that sensorless struggles with perhaps?
Are there other particular advantages?

I'm wondering if sensorless might be a good option for a trials bike?
That seems perhaps counterintuitive given a trials bike often runs at very low RPM but the thing is, even with encoder based control they still can't pickup satisfactorily from stalled. Not necessarily due to lack of torque or control from the motor, but because the rider can't deal with the shift from stalled to driving. It's way better to have a mechanical clutch to use at the transition from stationary to moving and set the motor to always idle. There's more, but that's a simple version.
Given the bike has a clutch and the motor is set to always idle, I'm trying to work out if there is any reason why (or why not) to use a sensorless controller?

I should add, I'm envisaging this on a IPM motor such as the QS165 V2.

Cheers.

 

[amberwolf]

I've read a variety of posts referring to sensorless controllers but have failed to identify any significant advantages or disadvantages other than:
Pro

• No need for sensors. Duh

Con

• Startup from stationary can be less than ideal. ie sometimes it wont, or it does but with reduced torque.

There's no such thing as a free lunch, so I figure there have to be others or no one would bother developing sensorless controllers.

Not needing sensors is a pretty big advantage, and is worth it all on it's own.

If no sensors are required, it saves complications in the motor design, build, and cabling, and in MCU software load on the controller as it doesn't have to try to read often-highly-degraded hall signals to get motor position data. (under high currents, like startup loads, the hall signals often have phase-signals imposed on them via induced currents from the phase wires running in the same cabling).

There are very few sensorless setups that can startup perfecly from a stop under load, but the ability does exist--at the least, Lebowski developed a technology to do this, though that code is not in the Lebowski brain chip code. There is a thread about it by him, though.

The cheap sensorless (or sensorless-capable "dual mode") non-FOC controllers derive sensor data by using some hardware outside the MCU to turn the BEMF from the phase wires into square waves, then knock the voltage way down to that the MCU can handle, buffer it, and send it to the MCU's hall sensor inputs. Then the MCU takes that data and compensates for the timing if needed, and uses it to control when it sends each phase current pulse the same way it does for halls, because it may literally not even know they aren't hall signals.

Better sensorless ones (FOC) derive position data from phase *current* info, but there's plenty of variations on that, and some are better than others.

Does efficiency change?
Is field weakening as effective or not? (it seems it is, but not totally sure).

It should be--that is only used at high enough RPMs that the motor cannot normally reach them without the FW, and sensors are not typically required anymore there--at least some of the FW-capable FOC controllers have modes for sensored start, sensorless run, for instance, so they wouldn't be using the sensors past startup.

Given the bike has a clutch and the motor is set to always idle, I'm trying to work out if there is any reason why (or why not) to use a sensorless controller?

I would guess there is no specific reason to use one, since the advantages of one are really that it just doesn't need sensors. If you don't have problems with the sensor data, and it's always clean signals and always present, then they can help give precise enough position data (especially if it's SIN/COS vs ABC/UVW halls, for instance).

If the data is not clean, is noisy from induced currents from the phases under load, etc., then sensorless might work better, depending on the sensorless method.

But if you are using an FOC controller on it anyway, it already has the physical ability to run sensorless (even if the UI doesn't present the option to you, and the code it runs on requires sensor data, by nature they can do so as they are measuring phase currents and already know the motor position from that; best with three current sensors, one on each phase, but some use only two successfully enough).

 

[bikerpete]

Not needing sensors is a pretty big advantage, and is worth it all on it's own.

If no sensors are required, it saves complications in the motor design, build, and cabling, and in MCU software load on the controller as it doesn't have to try to read often-highly-degraded hall signals to get motor position data. (under high currents, like startup loads, the hall signals often have phase-signals imposed on them via induced currents from the phase wires running in the same cabling).

There are very few sensorless setups that can startup perfecly from a stop under load, but the ability does exist--at the least, Lebowski developed a technology to do this, though that code is not in the Lebowski brain chip code. There is a thread about it by him, though.

The cheap sensorless (or sensorless-capable "dual mode") non-FOC controllers derive sensor data by using some hardware outside the MCU to turn the BEMF from the phase wires into square waves, then knock the voltage way down to that the MCU can handle, buffer it, and send it to the MCU's hall sensor inputs. Then the MCU takes that data and compensates for the timing if needed, and uses it to control when it sends each phase current pulse the same way it does for halls, because it may literally not even know they aren't hall signals.

Better sensorless ones (FOC) derive position data from phase *current* info, but there's plenty of variations on that, and some are better than others.


It should be--that is only used at high enough RPMs that the motor cannot normally reach them without the FW, and sensors are not typically required anymore there--at least some of the FW-capable FOC controllers have modes for sensored start, sensorless run, for instance, so they wouldn't be using the sensors past startup.





I would guess there is no specific reason to use one, since the advantages of one are really that it just doesn't need sensors. If you don't have problems with the sensor data, and it's always clean signals and always present, then they can help give precise enough position data (especially if it's SIN/COS vs ABC/UVW halls, for instance).

If the data is not clean, is noisy from induced currents from the phases under load, etc., then sensorless might work better, depending on the sensorless method.

But if you are using an FOC controller on it anyway, it already has the physical ability to run sensorless (even if the UI doesn't present the option to you, and the code it runs on requires sensor data, by nature they can do so as they are measuring phase currents and already know the motor position from that; best with three current sensors, one on each phase, but some use only two successfully enough).

Thanks so much for that very complete synopsis.
Sounds to me like running an encoder equipped motor would be gold standard.
Only compelling reason to go sensorless seems to be reducing components & potential failure points.

Of course the reality of what's available at what cost probably drives the decision more than anything most of the time.