Jump to content
Tribes

Sensorless BLDC motor control

Recommended Posts

I have been super busy the last couple of weeks, so I didn't really get to do much.

So far I have completly soldered one board and wrote a simple program to test the MOSFETs and drivers.

And they work! Flashing the MCU as well! :smile:

But I suspect the bootstrap capacitors may be to small, but we'll see, and changing them is not that difficult.

 

Tomorrow I can hopefully test the comparator stuff and then start some real development.

 

And some pictures:

post-9129-0-88414100-1381337907_thumb.jpg

post-9129-0-17963800-1381337949_thumb.jpg

post-9129-0-02893400-1381337990_thumb.jpg

Share this post


Link to post
Share on other sites

Cool project, I did something very similar as well!

 

https://github.com/lgbeno/BLDC-Booster

 

There is software on there too that you are free to reference. It works with some exceptions. The method that I used for commutation is bemf integration similar to the ti instaspin approach. The issues that I had was that for very fast motors(>500Kv), I wasn't sampling the ADC fast enough to get the commutation timing right but for slow motors, it works great.

 

A few words of wisdom since I worked on this project for quite some time. I would recommend using the 28pin Tssop or qfn32 versions of g2553. Reason being is that it has 3 pins attached to ta1.1 which you can use for the high side pwm signals and 3 pins attached to ta1.2 to be used for low side pwm signals. This does 3 things, frees up timer 0 for something else, allows you to do dead time insertion (if your gate drivers don't already) and just makes your code easier too!

 

The other thing is that you will see your pwm super imposed on your bemf which will likely cause false trips of the comparator. To solve this, there's a low pass filter but that also introduces a dc offset that throws off your zero cross point.

 

Long story short, I came up with a different network that filters and then ac couples the bemf to the comparator. I was seeing pretty good results with that approach. Then I had to return my borrowed scope and have not been able to work on it. Good news is I'm getting a brand new Rigol DS2072 for keeps on Thursday.

 

Anyway I guess that is my project life story, hope it helps. Tomorrow ill try to dig up schematics with those improvements (not in github yet).

 

Btw the schematics are very inspired by the microkoptor.de schematics, mine are as well... I wonder how they got away with the pwm glitches in their software. Obviously theirs works quite well.

Lgbeno, how'd your project go? Do you by chance have video of it ...ect? I'm thinking of doing my own brushless motor 430 controller. However, what you mentioned in that last sentence scares me. I've had issues with PWM glitches in the MSP430 in the past. This makes me scared of the MSP430 PWM Timer pins in a critical application...have any ideas? Did you ever figure out a glitch less method of controlling them? 

Share this post


Link to post
Share on other sites
 

 

Cool project, I did something very similar as well!

https://github.com/lgbeno/BLDC-Booster
 

Are the booster boards still available for purchase? I have an MSP430 launchpad, and I've been thinking to get a openbldc board or a ti drv8301 pack but would much prefer to use an open source board!

Looking at the github files for the BLDC-Booster

Share this post


Link to post
Share on other sites

MSP430s have glitchey PWM operation. I wouldn't recommend them for this application. A large dev effort would be to get ideal operation out of the PWM pins which ideally shouldn't be your focus. Feel free to chime in someone if i'm mistaken.

Share this post


Link to post
Share on other sites

MSP430s have glitchey PWM operation. I wouldn't recommend them for this application. A large dev effort would be to get ideal operation out of the PWM pins which ideally shouldn't be your focus. Feel free to chime in someone if i'm mistaken.

Is this "glitchiness" something you've observed with CCS (non-Energia) work? I know a good reason why PWM is glitchy in Energia, which is why I ask...

 

Sent from my Galaxy Note II with Tapatalk 4

Share this post


Link to post
Share on other sites

Is this "glitchiness" something you've observed with CCS (non-Energia) work? I know a good reason why PWM is glitchy in Energia, which is why I ask...

 

Sent from my Galaxy Note II with Tapatalk 4

It could be me failing at driver writing but I do all my drivers from the ground up in CCS(starting usally with the TI example code). Never touched energia.

I've heard of work arounds to get glitchless opperation of TI MSP430 PWM pins but most of them involve waiting. With a BLDC sensorless algorithm, there is no time to wait and all PWM generation must be %100 consistant to reduce jitter.

Share this post


Link to post
Share on other sites

It could be me failing at driver writing but I do all my drivers from the ground up in CCS(starting usally with the TI example code). Never touched energia.

I've heard of work arounds to get glitchless opperation of TI MSP430 PWM pins but most of them involve waiting. With a BLDC sensorless algorithm, there is no time to wait and all PWM generation must be %100 consistant to reduce jitter.

Yes, agreed, as Timer_A does not have double-buffered CCR updates.  You either have to roll an ISR (and hope the ISR entry isn't too long to catch a potential miss on the update) or wait.

 

Timer_B and Timer_D (F51xx series only, basically another evolution on top of Timer_B ) have double-buffered CCR updates though, thankfully.  It's an option (CLLD_*) that lives in the upper 8 bits of the TBxCCTLx register (which typically only have 8 relevant bits on Timer_A).  The F5529 LaunchPad has that, as does the FR5969 LaunchPad.  Beyond that none of the value line launchpad chips do, except their SMD-only successors (e.g. G2744 and G2955) do have a Timer_B0.

Share this post


Link to post
Share on other sites

It could be me failing at driver writing but I do all my drivers from the ground up in CCS(starting usally with the TI example code). Never touched energia.

I've heard of work arounds to get glitchless opperation of TI MSP430 PWM pins but most of them involve waiting. With a BLDC sensorless algorithm, there is no time to wait and all PWM generation must be %100 consistant to reduce jitter.

As a side note, I really wish they'd skipped Timer_A for the new MSP432 and just used Timer_B.  Even the AVR has double-buffered CCR updates!

Share this post


Link to post
Share on other sites

 

 

 

Are the booster boards still available for purchase? I have an MSP430 launchpad, and I've been thinking to get a openbldc board or a ti drv8301 pack but would much prefer to use an open source board!

Looking at the github files for the BLDC-Booster

Share this post


Link to post
Share on other sites

Hey Blipton,

 

I still have plenty of BLDC boosters, both bare PCBs and assembled.  I would be happy to sell them but its been so long, I don't know if I can really support them any more.  I know for certain that my test rig has been disassembled.  Maybe $3 per assembled board plus $3 to ship them?  Hopefully you are in the US?  Not a big deal if not.  They are sold as is but I can visually inspect before shipping.

 

To answer your questions:

1) At one point in time I was looking to port the algorithm to digital logic so this is where the PWM vhdl comes from.  I was doing a Mixed signal test bench in Mentor System Vision

2) Yes you are correct.  BEMF integration is sensorless however I found it very useful to have hall effects as training wheels to test my algoritim.  Basically on a scope I check my decision to commutate vs the "ideal" of the hall effect sensor.

3) Yes this is exactly what this is used for, it is a Python GUI that sends some control parameters and then the MSP430 sends back it's ADC readings.

 

Regarding PWM "glitches", yes they can exist with Timer_A like @@spirilis is saying because shadow registers are not used.  This can fairly easily be fixed in software by writing a ISR that loads in new duty register settings when the timer over flows.  This is exactly what shadow registers and CCRs do but it requires CPU intervention.  Regardless of the approach, the same limit is true that a duty cycle can only be updated once per cycle, its like a loop bandwidth limitation.  The only way to fix that is to increase the frequency.

 

Very cool that you were able to implement a stable workaround. I can't remember, did you by chance get your sensorless algorithm working? Do you have a video by chance? XD . When I did mine I used Arm core to have a bit more beef & filter options. This was a dev board I made for it, not meant to be tiny. I'll post a video hopefully in a couple days on it but i'd be awesome to see your implementation working as well.

esc.png

Share this post


Link to post
Share on other sites

Hey Blipton,

 

I still have plenty of BLDC boosters, both bare PCBs and assembled.  I would be happy to sell them but its been so long, I don't know if I can really support them any more.  I know for certain that my test rig has been disassembled.  Maybe $3 per assembled board plus $3 to ship them?  Hopefully you are in the US?  Not a big deal if not.  They are sold as is but I can visually inspect before shipping.

 

To answer your questions:

1) At one point in time I was looking to port the algorithm to digital logic so this is where the PWM vhdl comes from.  I was doing a Mixed signal test bench in Mentor System Vision

2) Yes you are correct.  BEMF integration is sensorless however I found it very useful to have hall effects as training wheels to test my algoritim.  Basically on a scope I check my decision to commutate vs the "ideal" of the hall effect sensor.

3) Yes this is exactly what this is used for, it is a Python GUI that sends some control parameters and then the MSP430 sends back it's ADC readings.

 

Regarding PWM "glitches", yes they can exist with Timer_A like @@spirilis is saying because shadow registers are not used.  This can fairly easily be fixed in software by writing a ISR that loads in new duty register settings when the timer over flows.  This is exactly what shadow registers and CCRs do but it requires CPU intervention.  Regardless of the approach, the same limit is true that a duty cycle can only be updated once per cycle, its like a loop bandwidth limitation.  The only way to fix that is to increase the frequency.

 

Sorry for the late reply, I thought I would get notification of any new comments in my email   :(    

 

Yes, if you still have a few assembled boards, just PM me (or email blipton at lycos) with the total to shipping to California.  

 

Thanks!  

BTW, what motor did you use for testing? 

Share this post


Link to post
Share on other sites

Hey Lgbeno!

 

I watch over you ESC..looks very nice but i don't know any software programing so i don't know how to spin the motor with your ESC. I gues you are using some serial comands??thx!

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×