A thread for finally figuring out sensorless drive strategies

1

Sensorless seems to be generally assumed to be a cheapie approach or a crummy approach, but after my explorations it appears to have many considerable advantages. In terms of cost of course, but also energy efficiency and thus maximal power output, system reliability, and general purpose utility for a range of different motors appears to be on the table.

Fundamentally, I have found that the error introduced by the sensor and reading it is an issue, for instance. Depending on the type of sensor there is code propagation error, measurement error including from stray magnetic fields and the mounting of the sensor. You have to adapt each sensor to each motor which complicates things.

There are approaches like IPD that can work at zero RPM to sensorlessly detect rotor position. Not absolutely, but at least within one “step” i.e. for 7 pole pair motor 1/7 of a rotation. I think with careful design it might even be practical to get a decent servo motor working with a fully sensorless design…

I posted previously that I got considerably higher energy efficiency when I eliminated the sources of error in the sensor etc. We are trying to regulate the angle to the optimal but I think in a lot of cases it’s not optimal, thus efficiency suffers. With sensorless, the sensor is the motor basically so you the sources of mechanical error and stuff are much reduced.

In my case, the water resistance of the assembly matters. A sensor is susceptible to water… I can paint it with encapsulant but that’s more complications. It’s a bit silly to use a sensor on fan, it’s clearly some overkill.

It also seems to me to be one of the best ways to make things plug and play which is always nice…

It seems to be that the so called Luenberger observers are the most common and standard approach, combined with IPD or open loop for startup of the rotor. Luenenberger observers appear to be a kind of state observer

I think the future for my fan is to use a Lepton 3.0 or similar (one step beyond the current lepton 2.0, solving the noise issue and using a G431 MCU, primarily, with a few modifications to break out more pins etc so it’s general purpose and thus can be adopted more broadly by the community as a flagship board for SimpleFOC). Ideally with sensorless drive. If it’s up to me, I would probably use what I dub tuned open loop with stall detection, which is not really that good and probably useless to anyone else, but I would like to make my experiments applicable more broadly.

Anyone else interested? I think the first stage is to hunt up some good documents and learn the fundamentals.

1 Like
2

Hi,

Sensorless drive in terms of BEMF driven commutation is fairly easy to achieve. There is much interest in this, and also there is hardware available that can do it.
I think this is on the road-map, and there are even people working on integrating it into SimpleFOC for their projects I believe.

Sensorless drive in terms of more advanced strategies, like the high frequency injection and the observers you mention are quite advanced topics at the moment.
I think these are super-interesting topics, but unfortunately they are far from “simple”.
I think VESC and ST-Micro have some code for HFI, but I’m not sure whether it’s open source or not. We could take a look.

From the point of view of the library, it would be good if one could do this in a way where it is like a Sensor implementation, or as a sub-project of SimpleFOC in some way, so that the main codebase doesn’t get complicated.

In terms of the hardware, HFI and other sensorless methods will be compute intensive, some people use DSPs and FPGAs, though I think both VESC and ST-Micro run on higher end STM32 MCUs. So it won’t really lead to a cheaper system because while you might save $10 on the sensor you’ll then pay it extra for the fast MCU. But it might lead to a simpler, smaller, lighter system, or have other advantages.
In terms of hardware I think HFI gets by with a good driver stage and current sensing (inline?). Other methods might have further requirements on the hardware.

1 Like
3

What does HFI stand for?

I think that re the sensor cost, the MCU costs more yeah but I estimate the sensor is costing me like $25 bucks after you factor in the mechanical parts, waterproofing and assembly costs. You need wire, connectors, gotta solder stuff.

The g431 MCU is pretty fast yeah?

There is tons of hardware that can do BEMF in terms of watching the one unpowered phase, but IDK if it is programmable and general purpose. It has to be, because I found this hardware often does not work or do what it needs to do, in a particular context. Acceleration was too poor, they weren’t reversible, they made too much noise, and in some cases couldn’t even drive the motor at all, I don’t know why exactly.

Modularity is good for sure, yeah. A separate module that watches the electrical angle, and the current waveform, and it would require initialization parameters to tell it the inductance etc (there could be a separate module that measures those), and basically returns the rotor angle would be the bees knees.

You would have to not run it at low rpm of course, it would get confused if you did.

IPD again, separate module of course yeah for sure.

I am a little concerned when I see that the complete driver ICs that I tried were never up to snuff. This seems to indicate that even the big boys have problems getting sensorless FOC working. However to be fair they also didn’t work in other ways which I am pretty sure I could have not failed at so just be cause they failed doesn’t mean we have to.

4
5

high frequency injection

yeah, these are all disadvantages of more simple commutation methods, and conversely, advantages of FOC…

Some BEMF based ESCs only work well for certain motor types. Others need to be configured using a “ESC programmer” before they will work.

Sure, there are open source implementations, and a wide array of hardware to choose from. If you hunt around you’ll find ones based on STM32 with exposed SWD pins.

@Candas1 nice link, the book describes the theory fairly well…

6

I have hunted around, I found the wraith32, but there does not seem to be anything that rivals the concept of the Lepton 3.0 that I posted, for intstance. Lots of broken out pins, led, easy to connect to. General purpose.

I tried configuring the Blheli ESCs, both blheli_s and the regular one, and no combination of setting got them to work for my current motor. They have baked in stuff. Theoretically bl_heli_s or whatever is open source so I could recompile it and I considered doing this with the wraith32 board, but honestly it’s a bit silly. Once again, that board is nothing special. If it was extremely common or something fine. But it could disappear tomorrow. If I’m going to be getting into that stuff, I want to be using a Lepton type device. Open source all the way down, common commodity components. As previously mentioned, the b-g431b-esc1 board is theoretically open source and obtainable, but in reality sourcing it is not reliable and as you pointed out there are licensing problems and other issues.

I think I have done a pretty thorough job checking the options for hardware and software, and there is nothing proper right now in the hardware department. Everything is kind of special purpose, not very sourcable, stuff like that. The lepton 2.0 and mosquito are the closest but just need one more push.

I have not investigated using VESC yet, if it is well written it will be possible to use the source code to roll something that can be used elsewhere… and it will be apparent what technique it uses for sensorless drive. There is that other one floating around here which claims to have sensorless drive capability, I have yet to check it out. High probability it needs work though, no one person can do a thorough job for free like that.

7

the VESC is extremely hardware specific… you can likely reuse some of the code but only if you are using the exact same MCU.

1 Like
8

But it should illuminate the logic used for sensorless drive, yeah?

9

I’m having a look at the xESC, but I think it’s probably another case of another half finished project, unfortunately. It would likely not be any easier to get that working than to take this road.

10

Hi Anthony, thanks for starting this subject.
I have set myself the task of building a system to drive a BLDC motor.
I have the motor, rated at 12kW 100v, 20 pole, 0.015 Ohm/ph , 45kV. (No sensors).
I did have an ESC driving it, roughly, but that ended in smoke and flames, and rather a large bang! The cause of which I am curious about, and would rather like to avoid it happening again. But am willing to bet it was a voltage spike caused by my ESC-Motor leads too long, bundled and tied together out the way of the prop. Within a few minutes of the smoke clearing, I decided I needed to know what was originally in the blacken box, and so make one myself.
So before the smoke, I had the motor spinning, first at 24v and 800RPM, and then at 4000RPM at 100v. (No load/prop), So motor should be good.
I have driven the motor at 25v with the STM32 b-g431b-esc1. And hacked the PCB to attach it to my intended MOSFETS, Infineon NTMTSC4D3N15MC, (just one bank, as I’ll use 5 in parallel later). And both ran at 800 RPM at 25v. So working from that schematic, I have rolled my own PCB intending to use the same firmware, with some modifications. As has been pointed out elsewhere finding my way around that firmware was driving me nuts, and drove me to find other options, and so found this amazing place, simplefoc.
So that’s me and my project so far.
Now I think the STM firmware may not have been the problem, but I’m the problem.
I don’t know how to proceed.
I have started with a the STM32_open_loop_velocity_example.
BLDCMotor motor = BLDCMotor(20);
BLDCDriver6PWM driver = BLDCDriver6PWM(PA8, PC13, PA9, PA12, PA10, PB15);
Still working low voltage ~25v
And can get the motor to move at 18Rad/s, but when I try
BLDCMotor motor = BLDCMotor(20, 0.015, 45, 20E-9);
Does not move. (But sounds much nicer :slight_smile:
Whatever may be the problem there, is this the right place/way to start?
Thank you for any assistance.
Cheers. Pete L.

1 Like
11

for a 12kW motor I think you would want to be taking a different approach, that’s quite a doozy. Also the boards you mentioned are not good to 100 volts.

The general approach is to get open loop working, yes, then add on to that, though. I would caution that you seem to be potentially assuming that SimpleFOC has some kind of sensorless commutation capability. You are trying to use current limited open loop? That’s not the same as sensorless commutation, not at all.

12

Hi Pete, sounds like a cool setup! You’re going to be among the people running larger motors in our crowd, and not all the advice you find will apply to your case.

Just to understand you right, this is open loop mode? And it works when you don’t set the motor parameters, but stops working when you set them?

13

Hi Anthony and Runger, thank you both for your replies.
Yes, the motor is spec’d at 25 to 30kW peak, but I’m not relying on that, a bit too speculative for me.
My PCB is not a direct copy of the STM dev kit, but I have used the same uP and general arrangement. It’s designed to be modular, which I suspect has lead me to make longer tracks in some cases than I should have, but I can roll out a new one later on. It should be capable of 100v and 250 Amps, but heat will be the limit to the later, and I don’t expect to need that capacity to do the job.
Sensorless commutation, yes at first I did assume that, but found it to be on the road map ahead rather than behind. I have included current sensing on the PCB, so maybe when I understand more I can implement an observer, and so lead on to position sensing(?).
And to answer Runger’s questions. Yes open loop velocity mode, mostly a standard example with some acceleration and voltage ramping. And yes the only change is from passing the pole pair count, to including the R,kv,inductance. Have to say I’ve not measured the inductance, just going from the value the STM motor workbench software determined. 0.02uH.
There are many variables I have yet to investigate, but feel I’m banging away with a blunt instrument, rather than understanding what effect I should be seeking and applying the required change.
Very interesting to note that the sound the motor makes is much more mellow with the second non rotating code. Seems to indicate an applied FOC signal with less wasted energy (?).
More reading, and learning.
Thanks again for your interest.
Cheers Pete L.
(PS being in Australia, the time zone will mean a slow conversation. Sorry for that).

1 Like
14

VESC is open source, too, I bet if you look at it you can discern something slightly useful at least, easier than reinventing everything.

My tiny motor was I think 12 millihenries, not micro. So there must be something wrong with that measurement, you can get cheap inductance meters on ebay or use a frequency generator and oscilloscope ( including the test signal from an oscilloscope) to measure inductance although I was never able to get that working quite right. Theoretically the relationship between the phase of the voltage and current when a sine wave is applied should allow one to easily calculate the inductance. Remember the terminal to terminal inductance is what simpleFOC uses, however in some cases some authors use the actual phase inductance, which is half that.

15

Ah, OK will investigate inductance, I do have a LCR bridge, but was concerned about the effect of the magnetic field on the measured value. So didn’t trust the value above the STM software. IIRC the bridge measured something in the low uH range. Will test again and apply that value. And it’s nice to know about the terminal-terminal value. Where should I look for other such details? For example, should the resistance be per phase or term-term?
I think smaller motors will typically have many more turns of thin wire, so don’t expect large mH values for mine.
Any comment on adapting the simpleFOC B-G431B-ESC1 example? That is closed loop, position control. I have avoided looking into it too closely yet, as it has many things I’m unfamiliar with. Just thought the simpler the better to start with.
I have many distractions from this project at the moment, so work will be slow, but will report back as I progress.
Thanks again.
Cheers.
Pete L.

16

I have found by looking at the code that SimpleFOC uses the terminal to terminal resistance, which imo is the best way to do things.

The subject of how to proceed with getting a novel combination of hardware working comes up fairly often on this forum I have noticed, and the answer has been evolved to a reasonable degree, but I don’t think we have expressed it in a central location very well. For me, which is probably missing stuff for your situation :

Get things working at very low power and low rpm with voltage based open loop. The use of a current limited power supply is advisable. I used like 1 or 2 volts even as the driving voltage in the code.

Get your sensor reading sensibly.

Get the sensor adjusted so that it is reading accurately, and is coordinated with the electrical angle, simplefoc has calibration stuff and can measure the zero offset. This may be not needed for hall sensors, IDK.

Then try to connect things so that simplefoc loops around reading the sensor and updating the “electrical angle”, at low power.

Then there is pid tuning and a bunch of stuff I never bothered with so can’t really comment on.

Might want to get current sensing working at this stage.

-other stuff??

Then increase speed and power with no load, then add load.

It would be good to have something more detailed for the different drive strategies.

I don’t know in what way inductance is factored in right now, or resistance, I haven’t explored that, however I am under the impression it is often not used and kind of still in development? however for large motors it is more important.

IMO it is important to check operation is proceeding as expected at each stage. It’s possible to have the motor turning and apparently working but you actually are getting poor efficiency or it stops working at higher rpm and so on, if you don’t proceed carefully with eyes open. Check to make sure things are not overheating for instance. I think getting everything working only in clockwise at first is also advisable as it reduces complexity and confusion and adapting things to also work counterclockwise is relatively easy after the other details are worked out.

BTW you should be aware these b-g431b-esc1 boards are hard to solder, I was super careful and still almost ruined one like three times. I carefully tinned the pads and the wire and used small gauge wire from the picoblade kit, I think it was 28 gauge or something. Then hold them together and heat them and inspect carefully.

17

I had a few minutes to work on it. Measured term-term inductance. 34.7uH was the average of several measurements. And my LCR bridge also said 0.2 Ohms, but it’s not so good at low resistance. I have previously put 1.0Amps term-term and read 30mV, so have been using 0.015 per phase.
Changed to;
BLDCMotor(20, 0.015, 45, 34.7E-6);
And got some movement with 1.5v, about 3.7Rad/S before missed steps and cogging.
Also increased resistance incrementally up to 5.0 and got 6Rad/S, still with 1.5v
I need to have a good block of time to dig down through the code to see these units and learn more. Should get that time next week.
As for soldering, Dad taught me to solder when I was 8 years old, I’m now 67 and for the past 30 years have had a business designing and building electronics devices, hand soldering SMD components. I do have a small reflow oven but never found the need/time to get any experience with it. So yes it was not easy hacking the B-G431B-ESC, and it would be no way reliable enough to move off the test bench, but it proved useful. Gave me the (maybe flawed) confidence to buy $200 worth of Mosfets!
Thanks for your comments and assistance. Cheers. Pete L.

1 Like
18

Good to hear. I realized we kind of highjacked this thread, that was a mistake. Further posts on your project should probably get their own thread. Sounds like a cool project and chances are good there will be another thing or two!

19

I didn’t want to work on sensorless because I think there are a lot of other lowest hanging fruits but Elwin reminded me yesterday how easy it is to implement the Flux observer from the MESC firmware I shared in June. David Molony got it implemented in VESC also together with Benjamin Vedder.

All the credit goes to David Molony, it might look complicated here but
apart from the mess I made in SimpleFOC to be able to use Alpha Beta Currents and Voltages, those are the few lines that are needed for the flux observer.
It’s incredibly simple but yet effective, and it’s using only current sensing…
This is not meant for 0 or low speed, velocity open loop could be used for the start up.
This paper is not related to this implementation but explains the formula used for the flux observer.

Here I am only calculating and displaying the angle in the main loop while running in velocity open loop, I am not using the angle for the commutation or anything else:

It needs phase_resistance and phase_inductance, and the flux_linkage that is used to saturate flux_a and flux_b, I calculated it based on the KV for a hoverboard motor but I am not 100% sure about the value.
Maybe you guys want to experiment with it on b-g431b-esc1 to see if it’s worth going further.

2 Likes
20

Yeah I am game to do this at some point, probably not right now, but it plugs into the HFI thing, you would sort of need one strategy for low speed and one for higher speeds, this could work for higher speed. Do you think it might be possible to calibrate the system in some way using an angle sensor? We can measure inductance and KV cheaply using an oscope and LC meter, but the other three values I know nothing about. Perhaps we can go from things that are easy to measure and infer the things that are hard.

Another approach that could work to get a measurement, while the motor is turning, of the motor timing, is to use an optimization algorithm to adjust the voltage until the current is minimal. If the voltage is too high or too low, a motor spinning under light load will actually draw minimal current when the motor timing is the ideal 90 degrees. If the motor is slightly past, you are of course very close to stall, and the current goes up. If the timing is less than 90 then the current also increases. So there is a dip there, a minima. We could use that to calibrate the rest of the model for a particular motor, perhaps. Possibly even implement some kind of correction at higher rpm etc if needed.

I tried to use this phenomena directly with my fan but it’s too prone to stalling, at least with my crude implementation

Another issue is getting an adequately clean current signal. And filtering would mess up the calculations as it causes lag etc. so we can’t really depend on that very well probably. Any noise would probably mess it up? Some people are saying with the b-g431b-esc1 board they are seeing more noise from the measurements simpleFOC takes than with the MC workbench related tools that ST electronics provides (Although those tools in my experience rarely work and when they don’t there is no hope of getting them working)

I found with my experimeting that one of the issues with sensorless drive is this threat of stalling. If things stall the measurements quickly become a bit borked, the mathematical model isn’t usually sophisticated enough to factor in the additional complexity, or maybe it’s not even possible. HFI might be used to recover from stall. I think most sensorless drivers use a padding margin on the motor timing, i.e. they do not try to regulate it to 90 degrees, because of this issue. The extra margin helps defend against stall, but of course it reduces efficiency and maximal torque etc.