New ground-up ESC - MESC_FOC_ESC

[mxlemming]

Thank you for your assessment!

As you know, I'm using commercial China hardware, so I have to take the processor and the pinout "as is".

Some users report "misfires", audible random ticking or clicking while the motor is running.
I can't really reproduce this. So one idea is, there are sometimes problems with the order of the interrupts...

Actually I read in the halls by GPIO_EXTIx. The motor hall signal is on PA0, PA1 and PA2, so I could use Timer2 input capture channel 1,2 +3 also. I can not assess whether this makes a big difference

regards
stancecoke

I'd guessed this was the case.

If it's specific to some users, perhaps noise on the hall inputs causing commutation errors? Some motors hall sensors are much noisier than others I've found. Are they filtered? I found on my first rev PCB it wouldn't work with ST firmware because the noise from the motor coupling onto the halls was triggering the timer reset/interrupt. I'd say misfire/bangs was closer to the mark than ticking...

I dealt with this in the second version with a filter, but also, rather than using interrupt, I now sample the hall state mid pwm period where there's minimal noise, and so it seems completely immune (on either hardware) at the expense of a few clock cycles.

Of course it may be something completely different. Unfortunately I don't have one of these motors/controllers despite attempting to buy one, otherwise I'd have a fiddle with your firmware.

 

[mxlemming]

Sharing a quick MESC vid. Running 80 phase amps, 13s3p of samsung 30q cells.
https://www.youtube.com/watch?v=fQdVWIh2dzs

[youtube]fQdVWIh2dzs[/youtube]

Here's the setup.


I carried on for a bit after the end of this video, but the ride ended abruptly a few mins later when the motor overheated and the hall sensors stopped working... so the MESC shuts off automatically. I disconnected the motor, and pedalled home, thinking I'd destroyed something, but when I got back home and plugged it in again, it just worked fine. Motor was toasty. Really really toasty.

The MESC was basically cold... less than finger temperature. I need a bigger motor, and a bigger battery pack. Oh goodie, I have 20s4p of P42a arriving tomorrow! Less sure what to do about the motor. I don't really want to go hubmotor, this entire setup adds just 4kg to the bike, with most of the mass in the middle, so I can wheelie and bunnyhop like it's not even there.

Also, don't off-road on slicks. I crashed. Maybe time to get the Maxxis Minions back out...

 

[thepronghorn]

Maybe you could fit a larger pulley on there to help your motor out? Not sure whether the pulley size is limited by print bed or chain stays or something else. Perhaps move to chain if the pulley thickness is a problem? I've found chain to be not that noisy on my build.

 

[mxlemming]

Maybe you could fit a larger pulley on there to help your motor out? Not sure whether the pulley size is limited by print bed or chain stays or something else. Perhaps move to chain if the pulley thickness is a problem? I've found chain to be not that noisy on my build.

Pulley size is mainly limited by the printer bed, 250mm, but also because the bracket gets silly big. Slightly aesthic decision.

15:97 gear ratio so 6.5:1. Ideally would be about 8 i think. With a chain is this possible? I haven't seen less than 11 tooth for a chain wheel so I'd need 88 tooth... Half inch pitch so about 350mm diameter right? Just looked at your one, it looks smaller. Are you using a smaller pitch chain? Or big wheels?

Could use htd5m instead of 8m... 20 to 160 and a 254mm pulley, but the htd5m is less robust. I'll order the small pulley and try..

I'm actually thinking I might have a firmware error, it seems to have more torque/ "pickup" at high speed. Think my hall sensor PLL might be lagging, so I have to use much more throttle in the twisty wood bits and it might be getting hotter than it should.

I'm actually pretty pleased with it as is. More power is always nice, but through the woods it's fantastic. Until it overheats.

 

[Vbruun]

Dual stage reduction might be an option. Check out tom stanton om YouTube, he did it.

 

[qwerkus]

Maybe you could fit a larger pulley on there to help your motor out? Not sure whether the pulley size is limited by print bed or chain stays or something else. Perhaps move to chain if the pulley thickness is a problem? I've found chain to be not that noisy on my build.

Pulley size is mainly limited by the printer bed, 250mm, but also because the bracket gets silly big. Slightly aesthic decision.

15:97 gear ratio so 6.5:1. Ideally would be about 8 i think. With a chain is this possible? I haven't seen less than 11 tooth for a chain wheel so I'd need 88 tooth... Half inch pitch so about 350mm diameter right? Just looked at your one, it looks smaller. Are you using a smaller pitch chain? Or big wheels?

Could use htd5m instead of 8m... 20 to 160 and a 254mm pulley, but the htd5m is less robust. I'll order the small pulley and try..

I'm actually thinking I might have a firmware error, it seems to have more torque/ "pickup" at high speed. Think my hall sensor PLL might be lagging, so I have to use much more throttle in the twisty wood bits and it might be getting hotter than it should.

I'm actually pretty pleased with it as is. More power is always nice, but through the woods it's fantastic. Until it overheats.

Hello, nice to see that your bike is running. It seems you are encountering classic mid drive conversion problems: motor size and reduction. You can google around or check this forum for the various solutions. At those power levels, a bike chain is a no go, so only belts or tougher chains left. A proven solution is to use #219 go kart chain and sprockets, which can take a lot more abuse and come with a smaller pitch, that allows for smaller sprockets. You can find up to 99t aluminium sprockets for a reasonable price, and use a 11t cog which gives you a good 9:1 ratio. Beware that chain on small cogs are super loud, and tend to wear the cog very fast. Belts are cleaner, quieter and can take quite some abuse, though if you stick with htd5m you'll probably need at least 20mm wide belts. Disadvantage are high prices and the required minimal tension, which makes it difficult to design / built properly working tensioner.

My experience is that a custom mid drive can be interesting to build and to test if you have a lot of spare time; but if you need a reliable bike that just "works" every time you need it, aftermarket closed solutions like a bafang bbs and especially hub motors are just sooooo much less hassle.

 

[mxlemming]

Hello, nice to see that your bike is running. It seems you are encountering classic mid drive conversion problems: motor size and reduction. You can google around or check this forum for the various solutions. At those power levels, a bike chain is a no go, so only belts or tougher chains left. A proven solution is to use #219 go kart chain and sprockets, which can take a lot more abuse and come with a smaller pitch, that allows for smaller sprockets. You can find up to 99t aluminium sprockets for a reasonable price, and use a 11t cog which gives you a good 9:1 ratio. Beware that chain on small cogs are super loud, and tend to wear the cog very fast. Belts are cleaner, quieter and can take quite some abuse, though if you stick with htd5m you'll probably need at least 20mm wide belts. Disadvantage are high prices and the required minimal tension, which makes it difficult to design / built properly working tensioner.

My experience is that a custom mid drive can be interesting to build and to test if you have a lot of spare time; but if you need a reliable bike that just "works" every time you need it, aftermarket closed solutions like a bafang bbs and especially hub motors are just sooooo much less hassle.

I bought a hub motor. It was a lot easier. Got it running in an afternoon, and running it now on another bike. But... I'd take the other motor any time. The weight penalty of the hub is completely horrible.

I honestly haven't spent much time atall on this mid drive. I'm a mech eng full time so this kind of design is utterly trivial for me. I knocked out all the parts in a few evenings.

The controller has been 100x the work. Every time I think it's done, there's something else, in firmware. That's why you haven't got one from me yet... You will i promise

Seriously, me and a friend are zooming around together, one of us with the hub motor and one with the 80100. There's nothing in it until I do the low speed constantly on max power through the woods, and I'm pretty sure this is a code issue that would be hidden if I had an 8kg hub.

I'm going to create another thread on the whole bike builds for this, the bike is interesting, I think the power to weight is fantastic etc but this thread is meant for the controller

 

[thepronghorn]

Maybe you could fit a larger pulley on there to help your motor out? Not sure whether the pulley size is limited by print bed or chain stays or something else. Perhaps move to chain if the pulley thickness is a problem? I've found chain to be not that noisy on my build.

Pulley size is mainly limited by the printer bed, 250mm, but also because the bracket gets silly big. Slightly aesthic decision.

15:97 gear ratio so 6.5:1. Ideally would be about 8 i think. With a chain is this possible? I haven't seen less than 11 tooth for a chain wheel so I'd need 88 tooth... Half inch pitch so about 350mm diameter right? Just looked at your one, it looks smaller. Are you using a smaller pitch chain? Or big wheels?

Could use htd5m instead of 8m... 20 to 160 and a 254mm pulley, but the htd5m is less robust. I'll order the small pulley and try..

I'm actually thinking I might have a firmware error, it seems to have more torque/ "pickup" at high speed. Think my hall sensor PLL might be lagging, so I have to use much more throttle in the twisty wood bits and it might be getting hotter than it should.

I'm actually pretty pleased with it as is. More power is always nice, but through the woods it's fantastic. Until it overheats.

I'm using #25 chain with 0.25" pitch, so I can do 12:134 or 11.2:1 with a 10.7" rear sprocket. Your bigger motor probably needs #35 or #219 chain which are a little bigger at 0.375" pitch and 7.774mm=0.306" pitch respectively. 219 chain is very slightly smaller pitch than your HTD8, and it allows smaller drive sprockets than a belt can tolerate, so you could get to your desired 8:1 with 12:96 gearing.

 

[xwx]

How's the FW does it perform close to VESC specs ?

 

[mxlemming]

Motor commutation wise, efficiency is the same or better, I get better mileage with this than VESC with similar settings. Pick up is a bit slower, i have a bit of lag on the hall sensor observer at low speed, I'll fix that soon...

Has field weakening, but presently that's only switchable by uncommenting a few lines and recompiling.

Seems to have much less tendency to crash and eat it's face, but that might just be that I know it much better so know what will make it eat it's face in advance.

Only supports hall sensor mode. No sensorless yet.

Much less developed UI, the whole thing has like 20 single layer commands over uart right now. This is in progress.

If you're considering building one, at the moment I'd advise VESC, unless you want to play with firmware yourself.

 

[xwx]

It's a nice project I would like to participate but I don't have hall on my motors.
Also did you check Ottercontrol same CPU maybe there are some good ideas.

Also a question did you think making 12FET version ? and what is your source of STM32F303CB because their prise is 10$ everywhere I know they got expensive but maybe you know places )

Thanks

 

[mxlemming]

It's a nice project I would like to participate but I don't have hall on my motors.
Also did you check Ottercontrol same CPU maybe there are some good ideas.

Also a question did you think making 12FET version ? and what is your source of STM32F303CB because their prise is 10$ everywhere I know they got expensive but maybe you know places )

Thanks

Had a look at ottercontrol just now. Doesn't look like it got anywhere near completion, and the pcb design is pretty poor compared to where this is now. The code base is stmbl which is meant for servo etc... Seems no FOC yet.

Not much to learn from that I don't think! Interesting that he started in exactly the same place as I did.

I have a few f303cb in a drawer, about 3 left. Unfortunately there's a worldwide stm32 shortage started by the Gilet Jaunes and now kept going by idiots hoarding them.

I made a 12 fet version with f405 (VESC based) but that's not open source. Some other people funded it. It's pretty powerful.

 

[cheapcookie]

Hi David, cool project! Is that a custom Ebrake lever with throttle? Any chance you could show more? Perhaps you could make a thread detailing the bike build, I would love to see more detailed pictures of the rear disc assembly. I have been wanting to do the same thing on my bike for awhile

 

[mxlemming]

Hi David, cool project! Is that a custom Ebrake lever with throttle? Any chance you could show more? Perhaps you could make a thread detailing the bike build, I would love to see more detailed pictures of the rear disc assembly. I have been wanting to do the same thing on my bike for awhile

Maybe you could fit a larger pulley on there to help your motor out? Not sure whether the pulley size is limited by print bed or chain stays or something else. Perhaps move to chain if the pulley thickness is a problem? I've found chain to be not that noisy on my build.

Pulley size is mainly limited by the printer bed, 250mm, but also because the bracket gets silly big. Slightly aesthic decision.

15:97 gear ratio so 6.5:1. Ideally would be about 8 i think. With a chain is this possible? I haven't seen less than 11 tooth for a chain wheel so I'd need 88 tooth... Half inch pitch so about 350mm diameter right? Just looked at your one, it looks smaller. Are you using a smaller pitch chain? Or big wheels?

Could use htd5m instead of 8m... 20 to 160 and a 254mm pulley, but the htd5m is less robust. I'll order the small pulley and try..

I'm actually thinking I might have a firmware error, it seems to have more torque/ "pickup" at high speed. Think my hall sensor PLL might be lagging, so I have to use much more throttle in the twisty wood bits and it might be getting hotter than it should.

I'm actually pretty pleased with it as is. More power is always nice, but through the woods it's fantastic. Until it overheats.

I'm using #25 chain with 0.25" pitch, so I can do 12:134 or 11.2:1 with a 10.7" rear sprocket. Your bigger motor probably needs #35 or #219 chain which are a little bigger at 0.375" pitch and 7.774mm=0.306" pitch respectively. 219 chain is very slightly smaller pitch than your HTD8, and it allows smaller drive sprockets than a belt can tolerate, so you could get to your desired 8:1 with 12:96 gearing.

Dual stage reduction might be an option. Check out tom stanton om YouTube, he did it.

Maybe you could fit a larger pulley on there to help your motor out? Not sure whether the pulley size is limited by print bed or chain stays or something else. Perhaps move to chain if the pulley thickness is a problem? I've found chain to be not that noisy on my build.

Pulley size is mainly limited by the printer bed, 250mm, but also because the bracket gets silly big. Slightly aesthic decision.

15:97 gear ratio so 6.5:1. Ideally would be about 8 i think. With a chain is this possible? I haven't seen less than 11 tooth for a chain wheel so I'd need 88 tooth... Half inch pitch so about 350mm diameter right? Just looked at your one, it looks smaller. Are you using a smaller pitch chain? Or big wheels?

Could use htd5m instead of 8m... 20 to 160 and a 254mm pulley, but the htd5m is less robust. I'll order the small pulley and try..

I'm actually thinking I might have a firmware error, it seems to have more torque/ "pickup" at high speed. Think my hall sensor PLL might be lagging, so I have to use much more throttle in the twisty wood bits and it might be getting hotter than it should.

I'm actually pretty pleased with it as is. More power is always nice, but through the woods it's fantastic. Until it overheats.

Hello, nice to see that your bike is running. It seems you are encountering classic mid drive conversion problems: motor size and reduction. You can google around or check this forum for the various solutions. At those power levels, a bike chain is a no go, so only belts or tougher chains left. A proven solution is to use #219 go kart chain and sprockets, which can take a lot more abuse and come with a smaller pitch, that allows for smaller sprockets. You can find up to 99t aluminium sprockets for a reasonable price, and use a 11t cog which gives you a good 9:1 ratio. Beware that chain on small cogs are super loud, and tend to wear the cog very fast. Belts are cleaner, quieter and can take quite some abuse, though if you stick with htd5m you'll probably need at least 20mm wide belts. Disadvantage are high prices and the required minimal tension, which makes it difficult to design / built properly working tensioner.

My experience is that a custom mid drive can be interesting to build and to test if you have a lot of spare time; but if you need a reliable bike that just "works" every time you need it, aftermarket closed solutions like a bafang bbs and especially hub motors are just sooooo much less hassle.

Started a thread on the bike build.
https://endless-sphere.com/forums/viewtopic.php?f=6&t=112270&p=1661542#p1661542

 

[mxlemming]

MESC just went sensorless... Not a great implementation yet, but it works and spins!

I read a whole load of papers, including the ST sensorless re. Luenburg observer, the Ortega paper (as used by VESC and a few others), and completely failed to understand any of them. Masses of blah blah, masses of half explained math and undefined terms...

So I thought I'd just make up my own one from scratch. Took about 3 hours to make it do anything then about another day to stop it from losing synch... Still not quite there.

The basic principle is that I integrate in the stator reference frame and look for crossings. The key to success is to look for well conditioned crossings, where the rates of change are as different as possible, and to construct a setup where the impact of noise is minimised (hence integrator).

The integrals are done w.r.t Valpha and Vbetain the forms:

IntValpha = 0.99*(Int.Valpha+k*Valpha - Ialpha*Rphase)
and
IntVbeta = 0.99*(Int.Vbeta+k*Vbeta - Ibeta*Rphase)


where k is a factor to convert Valpha to real volts (in the code it is 0-650ish and is a modulation index not a real voltage)
0.99 is a factor that exists to pull both towards zero, to avoid offset and noise dragging one or both integrals off to infinity. With ideal ADCs and electronics, this would be 0.999999....
For now I have omitted the inductance term since all the motors on my desk have very little inductance; maximum I have is 60uH which is not hugely significant. I'll add it one day I guess.

It started as a spreadsheet, where I just wrote out 3 sin waves, clarke transformed them, then integrated them and tried taking arctans and then just generating a pulse train.


Sin and cosine curves cross at 45 and 225 degrees, integration creates a lag of 90 degrees and the BEMF is the rate of change of the mag field, so 90 degrees phase shifted again... The pulses come at 45 and 225 degrees, and you can tell which it is by just looking at the polarity of the integral.

That's it. Those pulses then get fed into the same mechanics as used for the hall sensors, which is a crude PLL (basically add a step each time, then when data received calculate an error and a new speed based on the expected rotation per step and the number of pwm cycles since the last data).

Then you get this:
[youtube]rX6IknEzREs[/youtube]

At the end it overcurrents and shuts off. Still tracking down why it occasionally does this, I think it is partly because I have set the current limit really conservatively and partly because there are conditions in which sudden changes in load allow the PLL to get itself into a runaway condition. The integrator and pulse train are rock solid though, monitoring the variables through the SEGGER show that even when it crashes out, the integrator is still spitting out regular well defined pulses and the integral levels are indicative of correctness. Not yet daring to ride with it. That would involve 100A which might be less forgiving

 

[mxlemming]

Solved the over current problem and PLL running away.

Issue was in the 0.99 I was using to pull the values towards center. This biased it towards more recent values in the integral, which could occasionally result in sudden rapid phase advance, which effectively caused massive field weakening which then caused more phase advance and... Runaway over a few electrical revolutions. Seems like 0.99 was the cliff edge. An extra 9 takes it well back from the cliff edge, but might need some thought about centering the signal in a noisey environment.

Very pleased now with how this runs, it's much smoother than the hall sensors and has shaved a few watts off the free running current. Hopefully it works when I strap this code to the bike!

I still don't really understand why it starts up fairly well. There's no startup code atall, it seems to just really on the PID loops bludgeoning the current and voltage into shape in d-q frame effectively enough, even though it has no idea what angle it's at, that it manages to pick up a signal in alpha beta frame. Normally it's enough to just give it a poke and it'll start and 50% of the time it starts spontaneously.

 

[stancecoke]

Hm, strange approach. To be honest, the various sensorless algorithms are not easy to understand, but I don't understand your's at all :wink:

regards
stancecoke

 

[mxlemming]

Hm, strange approach. To be honest, the various sensorless algorithms are not easy to understand, but I don't understand your's at all :wink:

regards
stancecoke

Yes. They are all a bit of a mind game. I've long suspected the available ones mainly just copy each other and write app notes by not quite copying each other's appnotes. They all miss the same key bits of understanding.

I'll try to break it down as simple as I can.

1) all PM motors generate a back emf. The back emf goes up with speed, but the frequency also goes up. The integral of back EMF remains constant for any given electrical angle - this is the flux linked and is dependent on the magnetic field and coil arrangement.

2) UVW and alpha beta reference frame can be considered identical. Alpha beta is just a simplification from 3 to 2 phases but all properties can be translated. A stepper motor which has 2 phases for example could be run directly from the alpha beta frame with no need for inverse Clarke or svpwm.

3) the pwm voltage must accurately follow the BEMF. The PI regulators ensure this. If they ever don't, instant over current or general unpleasant failure will occur since there's a non zero sum around the loop and large currents rapidly build up.

4) integrating the BEMF acts as a low pass filter and reduced the impact of noise while not introducing any delay (well, a known 90 degree delay which is trivially compensatable) as an averaging mechanism would.

5) considering (2) integrating Valpha and Vbeta is equivalent to integrating Vu Vv and Vw. However, there's only 2 signals to deal with and therefore 2 states/crossing points not 6. You could equally integrate Vu Vv Vw but there would be far more if elseif else blumpf, though more points might improve tracking at very high acceleration rates. The integrals are broadly sinusoidal and therefore have crossing points where the integralValpha and integralVbeta become bigger and smaller than each other. These are well defined.

6) With these crossing points detected, all that remains is:
a) to feed them into a mechanism that counts the duration (n cycles) of each Valpha>Vbeta state and sets an angle increment per pwm cycle accordingly. (180 electrical degree between each crossing, n cycles, increment 180/n degrees each pwm period)
b) introduce a term that measures the estimated angle against the angle known to be the BEMF integral crossing point and add a correction term to be applied over the next n cycles, such that with no other external change it will eliminate the error by the time the next crossing is seen.

That's it. It's all on github and my code is still a complete mess because 1) I'm not a tidy person and 2) no one is paying me for this... but it should follow fairly easily.

 

[Vbruun]

Very impressive!

I really like what this controller is starting to become!

 

[zinahe]

Hi all,

First of all thanks for the incredible work by mxlemming and everyone who contributed to this project. I'm not sure if this thread is still active but I wanted to ask a few questions:

1. The github repo consists of a number of folders (R2 Outputs, R2.1 Outputs, R2.2 Outputs V0.5 Outputs) which made it difficult to locate the latest gbr files. I also saw that there was a mention of V0.6 somewhere in the discussions. Is the repo up-to-date with the latest design and which are the files one should be using, let say to order from JLCPCB ?

2. I understand the schematics utilizes two types of MOSFETs (Q1-Q6 of CRSS037N10N and Q7-Q12 of IPT015N10N5). And unfortunately due to the semi-conductor crunch we are in at the moment, the CRSS037N10Ns are not available at the moment. I tired to search replacement and the best match I could find are these. Any suggestions ?

[Edit]
3. Now that external current sensing amplifiers are used, is there any particular peripheral requirement that ties the design to STM32F303? The firmware should be updated and the MCU pin-outs should map correctly, of-course.
[/Edit]

Cheers,

 

[mxlemming]

Hi all,

First of all thanks for the incredible work by mxlemming and everyone who contributed to this project. I'm not sure if this thread is still active but I wanted to ask a few questions:

1. The github repo consists of a number of folders (R2 Outputs, R2.1 Outputs, R2.2 Outputs V0.5 Outputs) which made it difficult to locate the latest gbr files. I also saw that there was a mention of V0.6 somewhere in the discussions. Is the repo up-to-date with the latest design and which are the files one should be using, let say to order from JLCPCB ?

2. I understand the schematics utilizes two types of MOSFETs (Q1-Q6 of CRSS037N10N and Q7-Q12 of IPT015N10N5). And unfortunately due to the semi-conductor crunch we are in at the moment, the CRSS037N10Ns are not available at the moment. I tired to search replacement and the best match I could find are these. Any suggestions ?

[Edit]
3. Now that external current sensing amplifiers are used, is there any particular peripheral requirement that ties the design to STM32F303? The firmware should be updated and the MCU pin-outs should map correctly, of-course.
[/Edit]

Cheers,

Hi Zinahe,

Nice to see the interest in this project. To your questions directly first...

1) The PCBs as ordered are on commit 96fb25afc07f31bedd5439b9273e76e75e7277ba from 16th December 2020. Since that, I made a few improvements, but there are no further GERBER files made, and I have not ordered further boards. If you are actually going to order some, I would recommend you recreate the gerbers from the project files since there are probably a lot of missing components from JLCPCB 9 months later. The current "latest greatest" is master branch at commit 0894c6b28ff915d71f7fb4fb8f169e0d44fd1a05


2) The IPT015N10 MOSFETs are massively preferred over the TO263 options if you want to push more than about 50A. The TOLL FETs are far superior in switching and current capacity. On Semi FDBL0200N100 is the optimal TOLL choice if you can get it. If you are happy with the TO263s, you might try the CR Micro CRSS028N10, which JLC currently have 900 of or HSH15810 which they have 600 of. Many FETs will work, with chinese brand ones you roll a dice to some extent, but I found the CR Micro ones seemed to work every bit as well as the Infineon and TI ones I tried. Take care that 1) Rds on is <5mohm for decent power capability (the TOLL fets are about 1.5mohm) and most importantly the ratio of Ciss to Crss is >100.

3) You need as a bare minimum, assuming you have external opamps:
3 independent ADCs, or an ADC with sufficient speed to sample 3 current channels sequentially in <about 60 clock cycles. The ADC must be triggerable by the advanced control timer, and you will have to implement your own ADC conversion functions if you swap chips.
The STM Advanced control Timer 1 (they basically all have this)
Timer with capability of PWM input for RC, and the analog throttle in also runs off that for running the slow loop interrupt at 50Hz with a 50Hx PPM in or 20Hz without.
An FPU. If you want to run FOC without an FPU, look at stancecoke's project which in many ways is more advanced than mine (integration with screens etc) though the hardware choice of that project limits how good/tight the control can ever be.
You do not need a timer for the hall sensors. Initially I intended this, but in the end found this was not helpful (in fact noise on the hall sensors makes the timer solution nearly non functional)

There are some unused peripherals e.g. USB is not implemented, and probably never will be (if I make another board I will drop an external USB-serial chip on it since the STM USB drivers are a semi proprietary crock of crap).

The F303 is optimal, one day I will get round to porting the code to F405 and L433.

The only pin for pin drop in replacement chip is the L433, which has one super fast, very well behaved ADC, and again I never got round to porting the code.

Now... Should you do this?

The power stage I believe is pretty good. It switches very cleanly and fast and is capable of quite a lump of current for its size.
The analog stage is also pretty good, with the external amps it's nice and clean, with the internal ones... it works well enough for ebike application, but you can actually hear the noise the analog sampling injects into the control loop coming backout of the motor at standstill. It's a white noise hiss, nothing serious, quieter than BLDC commutation.

The software is much less good. It runs FOC in hall sensor mode only; I made recently the sensorless branch but it is basically an academic exercise for me. The code is far from professional or enterprise, and it still has a lot of magic numbers in it that I occasionally go around sniping.

Against that, it seems pretty robust, I have done the better part of 1000km on my ebike and now the only time it ever trips is when a wire falls out or something shorts. Efficiency is decent.

I have no plan to carry this forward to some world leading ESC thing, I am currently thoroughly employed in making scientific equipment that pays far more than I can ever foresee from making ebike controllers, so this remains my toy that I use to learn electronics and embedded programming.

You are absolutely welcome to use it, bits of it, fork it, contribute code (though I won't tolerate proliferation of abstraction and 200 header file "professional developer" blumpf) build and sell them commercially... whatever, but if it breaks... you can keep both pieces. I'll gladly help out via forum posts up to a point.

Good luck whatever you do!

 

[zinahe]

Hi mxlemming,

Thank you for the detailed response. As for the MOSFETs; I'll try to pick one from your recommended list and report my findings here. Generating the Gerber files will hopefully give me a chance to brush-up my KiCAD as well. If I understand the KiCAD workflow correctly, one starts with the schematics (.sch), then the pcb lay-out (.pcb), add the BOM + placement (.csv) and finally generate the GERBER files. Correct ?

Regarding the MOSFETs, I'm not sure if I'll go with the IPT015N10 as they are kind of pricey and I expect to blow-up a few of the boards during the initial learning curve 8) As for the MCU, I have no plan whatsoever to port it to a different family TBH. I'm familiar with STM32F4 + libopencm3 + FreeRTOS. So going forward, I only wanted to get some clarification how dependent the design is on the F303.

Just to provide some context about my interest in this project, I come from a robotics + embedded systems background and lately I have witnessed a peculiar trend where many people are focusing on using FOC along with high resolution magnetic encoders. Unfortunately, almost all of the currently available open source implementations of FOC for BLDCs are somehow tightly coupled to un-obtenium ICs like DRV8203; which IMHO is not cost effective and hides a lot of details for someone (like me) who really wants to understand what the heck is going on. So I started looking for a "bare-bones" implementation that I can start playing with in my projects. I have no intention of using MESC_FOC_ESC for a commercial product; and I understand your reservation.

I'm just beginning to scratch the surface on FOC. So far my understanding is that one needs accurate measurement of individual phase currents and the precise position of the rotor; although I've seen some implementations that use a single shunt current sensor on the DC bus and workout the rest with some fancy math. I'm wondering how your implementation managed with just the hall sensors.

Thanks again,

Zinahe

 

[mxlemming]

Hi mxlemming,

Thank you for the detailed response. As for the MOSFETs; I'll try to pick one from your recommended list and report my findings here. Generating the Gerber files will hopefully give me a chance to brush-up my KiCAD as well. If I understand the KiCAD workflow correctly, one starts with the schematics (.sch), then the pcb lay-out (.pcb), add the BOM + placement (.csv) and finally generate the GERBER files. Correct ?

Regarding the MOSFETs, I'm not sure if I'll go with the IPT015N10 as they are kind of pricey and I expect to blow-up a few of the boards during the initial learning curve 8) As for the MCU, I have no plan whatsoever to port it to a different family TBH. I'm familiar with STM32F4 + libopencm3 + FreeRTOS. So going forward, I only wanted to get some clarification how dependent the design is on the F303.

Just to provide some context about my interest in this project, I come from a robotics + embedded systems background and lately I have witnessed a peculiar trend where many people are focusing on using FOC along with high resolution magnetic encoders. Unfortunately, almost all of the currently available open source implementations of FOC for BLDCs are somehow tightly coupled to un-obtenium ICs like DRV8203; which IMHO is not cost effective and hides a lot of details for someone (like me) who really wants to understand what the heck is going on. So I started looking for a "bare-bones" implementation that I can start playing with in my projects. I have no intention of using MESC_FOC_ESC for a commercial product; and I understand your reservation.

I'm just beginning to scratch the surface on FOC. So far my understanding is that one needs accurate measurement of individual phase currents and the precise position of the rotor; although I've seen some implementations that use a single shunt current sensor on the DC bus and workout the rest with some fancy math. I'm wondering how your implementation managed with just the hall sensors.

Thanks again,

Zinahe

Re.kicad, that's basically it.

I think the design would be relatively easily portable to f405 f427 f429 l433 l476 (probably others) h7xx (I've specifically checked h743) probably the f7xx series but they're defunct now h7 is around.

I haven't blown up a MOSFET since i implemented over current and over voltage protection on a cycle by cycle basis. Sadly jlc doesn't have the ipt015 any more.

Re. Hall sensors...

At low speed, it just assumes the angle is in the middle of the hall sensors position.

From about 60eHz, it watches for changes in the hall angle state and says "i know the hall state just changed so the angle at that exact moment was x degrees and the last time period between hall state changes was y pwm counts". That information is then fed into a crude PLL which increments the angle by a small amount equal to 60 degrees/number of pwm periods counted for the last hall state each pwm cycle and also adds an amount based on the observed angle error such that by the next expected hall change the error is reduced to zero.

If you wanted an encoder you'd need to wire it into inputs 1 and 2 of timer 2,3 or 4 (it already is on timer 4 for the f303 version) and set up encoder mode and a function to return the encoder angle in the fastloop instead of calling the hall observer.

Many ways to do this, this is a fairly simple but effective one.

For position control you're probably going to want an encoder.

 

[zinahe]

From about 60eHz, it watches for changes in the hall angle state and says "i know the hall state just changed so the angle at that exact moment was x degrees and the last time period between hall state changes was y pwm counts". That information is then fed into a crude PLL which increments the angle by a small amount equal to 60 degrees/number of pwm periods counted for the last hall state each pwm cycle and also adds an amount based on the observed angle error such that by the next expected hall change the error is reduced to zero.

That's pretty neat!

Well, it seems I've got my work cut out for me. Time to get my hands dirty. Would you be able to upload the latest kicad_pcb layout (v0.6) to github by any chance ?

 

[mxlemming]

Zinahe,

To the best of my knowledge, every bit of layout work and Schematic work and everything is on github already.

You'll need to find the correct branch and commit but it's all there.

Do you use some kind of git client? I use source tree. It visualises all the branches and commits much better than GitHub web.