Firmware

[lizardmech]

2 hours ago, KingQueenWong said:

I don't think you are right what so ever.You try to add a bad tag for this open project,which make others uncomfortable.I will try my best to do somthing for this project.

Look at the code it's not FOC, there's nothing taking into account motor induction and resistance variables, I'm not making this up. There's already fully functional open FOC software that can be made to run on many 32bit MCUs. Those 24v and 36v controllers can't be used to make EUCs due to hardware constraints. The current proposed development will not result in anything useful for EUCs nor will it improve access to low cost FOC motor controllers. Refusing to use existing FOC code from other open projects is irrational and counter productive. People try to point out these issues politely but there's never any response or the slightest interest in debate or letting anyone collaborate. Disagreeing about software development is not a personal attack, look at linux kernel development, it's full of arguing, if they all refused to allow different opinions so everyone could feel good there would be no linux kernel. It's impossible to have an open source project where peoples feelings dictate development rather than objective actions based on evidence and data.  

[KingQueenWong]

LSW659-94-1F

[KingQueenWong]

LSW959-94F

[Tomek]

@lizardmech I think you need to see @electric_vehicle_lover's project as nothing more than his personal hobby exploration that he's kind enough to share with everyone. I do see the point of having dirt cheap and open source ebike/EUC controllers for all kinds of quick and dirty DIY projects. And, IMO, developing a balancing algorithm is impossible without access to the hardware and iterating a lot on it, so I also get it that he doesn't contribute code (I think he hasn't managed to make the balancing code work for his hardware either...). On the other hand, if you want to be serious about making an EUC that's anywhere close to the wheels we ride today (800W+), custom hardware and well developed software is a must. That's why I really applaud your efforts. btw. do you have access to VESC6 beta? If so, how's the integration with your hardware going? Once that's available an ocean of new possibilities opens up .')

[lizardmech]

1 minute ago, Tomek said:

On the other hand, if you want to be serious about making an EUC that's anywhere close to the wheels we ride today (800W+), custom hardware and well developed software is a must. That's why I really applaud your efforts. btw. do you have access to VESC6 beta? If so, how's the integration with your hardware going? Once that's available an ocean of new possibilities opens up .')

I have the VESC 6 firmware up and running on custom hardware. Basically it's complete but I can't find anyone to program the balancing functions. I can hire freelance developers to do it, the problem is I'm unable to find any with balancing vehicle experience, by the time I buy and ship an EUC to them and pay them to study how it works the costs will be perhaps $5000 to $10,000. But I'm hesitant to to spend that much on top of the hardware costs when no one is willing to work on open EUC controller software to begin with. It makes it even more difficult because the handful of people that can code end up investing time on a project that has no coherent goals or long term plan to support EUCs, they get bored or frustrated after a couple of months then never come back to the forum. If people are going around saying not to bother with open projects and to buy proprietary hardware instead that is opposing open source solutions not promoting it.

[Tomek]

2 hours ago, lizardmech said:

I have the VESC 6 firmware up and running on custom hardware. Basically it's complete but I can't find anyone to program the balancing functions. 

wow, did you do some testing with full voltage/torque? do you consider your hw design to be final? I can make my own hw setup and I could engage some of my colleagues to help out with the balancing part of the software - I work at the industrial engineering faculty of a tech university (it's just that I'm totally short on time with much work and two babies at home)

PS. the way I'd start with it would be to keep VESC intact, and do some try-outs of the balancing PID loop on a separate arduino connected over CAN or UART, just to keep things clean.

 

Edited August 17, 2017 by Tomek

[lizardmech]

13 minutes ago, Tomek said:

wow, did you do some testing with full voltage/torque? do you consider your hw design to be final? I can make my own hw setup and I could engage some of my colleagues to help out with the balancing part of the software - I work at the industrial engineering faculty of a tech university (it's just that I'm totally short on time with much work and two babies at home)

 

Yeah I had it up and running, I found I greatly overestimated the amount of heat it produces, I was running 80A+ loads on it. I had some water jet cut copper parts for bus bars on that one but I found they were a reliability headache as they bend the PCB with heat expansion causing failures. I redid the layout to make use of thicker 3oz PCBs rather than separate busbars but I haven't had time to assemble that one yet. I also have another one built from an integrated IGBT power module, pretty much all the power components are in the one package all you need to do is add a simple 2 layers PCB with MCU and sensors, it doesn't switch as quickly as the mosfets but can handle up to 600V. I have both VESC software and Ti instaspin software up and running on my EUC motor. The VESC has many more features and can be configured over USB but it can be a little complex to add additional things as you have to deal with all the real time OS subsystems. The instaspin software is the opposite everything is minimalistic and you have to recompile firmware just to change motor variables, however once you have it running it performs well and is simple to build on.

[Tomek]

1 hour ago, lizardmech said:

Yeah I had it up and running, I found I greatly overestimated the amount of heat it produces, I was running 80A+ loads on it. I had some water jet cut copper parts for bus bars on that one but I found they were a reliability headache as they bend the PCB with heat expansion causing failures. I redid the layout to make use of thicker 3oz PCBs rather than separate busbars but I haven't had time to assemble that one yet. I also have another one built from an integrated IGBT power module, pretty much all the power components are in the one package all you need to do is add a simple 2 layers PCB with MCU and sensors, it doesn't switch as quickly as the mosfets but can handle up to 600V. I have both VESC software and Ti instaspin software up and running on my EUC motor. The VESC has many more features and can be configured over USB but it can be a little complex to add additional things as you have to deal with all the real time OS subsystems. The instaspin software is the opposite everything is minimalistic and you have to recompile firmware just to change motor variables, however once you have it running it performs well and is simple to build on.

nice. share some photos!

[lizardmech]

24 minutes ago, Tomek said:

nice. share some photos!

This is them, I changed the mosfet layout a bit on the new revision, next time I order PCBs I want to make a test version with isolated hall sensors instead of the current sensing shunts, that way it is possible to use 100V mosfets as resistive losses were not really a big issue at the currents EUC use. I should update the IGBT one as well, I quickly threw it together not expecting to use it but when I sent a sample request for the IGBT modules they accidently sent me 10 of them due to their website having a glitch so now I have $800 worth of 600v IGBT motor controller power stages I may as well use them.

[Tomek]

cool duo. can't believe that copper heatisink wasn't enough. does the IGBT version also run VESC or just instaspin?

[electric_vehicle_lover]

I got some more knowledge about driving the motors, and on EBikes, the cheaper, lighter and small motors are popular and they are geared like running at 13x faster than the direct drive motors. This faster motors have a much higher eRPM and they need faster PWM frequency -- which is not the case with the EUC motors that I know. But taking as example the MicroWorks 30km/h 500W motor, at 30km/h it is half the max eRPM (22.000 eRPM, max of eRPM for 16kHz PWM = 40.000)). Going with a bigger wheel size for speeds over 30km/h will help to avoid potential issues with faster eRPM.

Ok I think I got the eRPM of your motor: I saw value of 40 of ui16_speed_inverse and that means 40 * 64us = 2.560ms per eRPM at 36V power supply -- I guess you want run motor at 36v. The firmware will draw the "sine wave" voltage using 40 points.

My Q85 at 30V (and I think it is a 24v motor), have a 1.808ms eRPM as seen on the next picture -- so firmware will draw the "sine wave" voltage using 28 points... I think this is an issue!! (we can verify/count the 28 number of PWM pulses on the next image)

At 30V, this motor have an eRPM of 15ms!! 6x lower than my Q85 motor!! So the firmware will draw the "sine wave" voltage using 234 points VS the only 28 on my Q85.

I remember to try drive my Q85 with my MicroWorks 30B4 board (STM32F103), using FOC/sine wave/SVM and it worked well just up to medium speed and after that it was going craze!! I could see the value of position_correction_value start going backwards (crazy!!)... that firmware have the PWM running at 20MHz / 50us and with S06S it runs even lower at 16kHz / 64us... I am that afraid S06S can't run well this fast eRPM motors like Q85 and Q75, due to low PWM frequency / motor high eRPM.

---

http://kellycontroller.com/faqs.php

What's BLDC high speed model and ultra high speed model differ from standard model?
32-bit microprocessor, higher PWM frequency.
Standard model: 16.6KHz, 40,000 eRPM.
High speed model: 33KHz, 70,000 eRPM.
Ultra high speed model: 100KHz, 100,000 eRPM.
eRPM=Mechanical RPM*Pole pairs.
It does generate more heat because of higher switching frequency.

[electric_vehicle_lover]

Sharing the knowledge I developed:

So I think I was able to figure out how to do FOC on the BMSBattery S06S/Kunteng STM8 motor controllers!! Due to the hardware limitations, I think FOC is only doable with losing much resolution but that should be enough for this application. But this way there is not need to do multiplications and calc sines and cosines, just read directly phase B current to have ID and IQ currents!! I write my notes, please see here: https://opensourceebikefirmware.bitbucket.io/Various--Endless-sphere.com_forum_messages--2017.09.02_-_How_to_do_FOC_on_the_BMSBattery_S06S-Kunteng_STM8_motor_controllers.html

2017.09.02 - How to do FOC on the BMSBattery S06S/Kunteng STM8 motor controllers

On FOC hardware, typically at least 2 phase currents are measured while on the BMSBattery S06S/Kunteng STM8 motor controllers only 1 phase current is measured. Also FOC needs processing power and we see cheap hardware using like the STM32F103 32 bits that can do the math algorithm while the STM8 8 bits can't.

I think BMSBattery S06S/Kunteng STM8 motor controllers do a kind of simplification of FOC. They can do FOC with much less resolution but that may be enough for this application where the target price of this motor controllers is ultra low. Next, I describe the way I think they achieve FOC.

The following documentation considers that you are familiar with FOC documentation.

The next image shows the 3 phase currents, phased out 120º of each other. On Kunteng STM8 motor controller, only 1 phase current is measured - let's say it is phase A (green line).

Image 01

ia = green line
ib = red line
ic = dark blue line
hall sensor signal = light blue line

On FOC hardware, typically at least 2 phase currents are measured and since the sum of the 3 phase currents are zero (ia + ib + ic = 0), the third current is calculated. As we can see on the image 01, ib and ic have the same negative value while ia is positive with double amplitude, for instance: 10 + (-5) + (-5) = 0; 10 = -(-5 -5); 10 = 10.

Although on Kunteng STM8 motor controller only 1 phase current is read, the other 2 should be similar but phased out 120º of each other.

The next image shows the same current as vectors while teta is zero. Every current is placed 120º phased out of each other.

Image 2

The sum of the current values can be represented on the quadrature axis Q and Q (gray color). At the specific moment when teta is zero, ia, ib, ic D axis components results in ID component which should be the max possible value for ID amps (100%). ia, ib, ic Q axis components: ia Q is zero as ia is placed on D axis; ib Q and iC Q have the same value but opposite directions and so they cancel out -- IQ is zero amps (0%).

The next image shows the phase A current with teta 90º relative to motor rotor position - at FOC we want it to be at 90º where happens max efficiency of the motor.

Image 3

hall sensor signal = light blue line

As we can see, ID have the max value, the top of sinewave phase A current value. IQ is measured 90º compared to ID and the phase A current is 0. On FOC we want to keep/control IQ = 0 and that will mean a constant 90º of the phase current relative to motor rotor position, where happens max efficiency of the motor. ID is the value current value that we will also want to control and results of the motor torque.

The next image shows the phase A current with teta 45º relative to motor rotor position. As we can see, IQ is not zero and ID is not the max value -- motor will vibrate, make noise and asking to much current: will be very inefficient.

Image 4

The next image shows the phase A current with teta 0º relative to motor rotor position (I think motor would not even work/run on this situation). As we can see, IQ is max value and ID is zero value. With ID zero, we have zero torque meaning motor would not run, I think all the current/torque would be used to block the motor instead of making it rotating.

Image 5

Conclusion
I think we can do FOC on the BMSBattery S06S/Kunteng STM8 motor controllers by doing the following:

• please refer to image 3. On this situation, if we read phase current B on Kunteng STM8 motor controller:
◇ point B: the read value is the IQ current
◇ point A: the read value is the ID current

• to do FOC, we need:
◇ keep IQ current = 0
▪ adjust the PWM sinewave phase angle that we generate, to keep IQ at zero amps value
◇ keep ID current at the value we desire, that will result the effective motor current/torque
▪ adjust PWM duty_cycle value to keep ID at the amps value we desire

[Tomek]

http://www.vesc-project.com/

...just sayin'

[electric_vehicle_lover]

22 minutes ago, Tomek said:

http://www.vesc-project.com/

...just sayin'

Nice to see the news about VESC :-)

[Tomek]

22 hours ago, electric_vehicle_lover said:

Nice to see the news about VESC :-)

To quote Benjamin Vedder's today's post from the VESC-project forum:

   The source code for VESC Tool and the latest firmware are already available:

   https://github.com/vedderb/vesc_tool
   https://github.com/vedderb/bldc

   I'm working on a reference design based on HW6 that I will finish this week hopefully.

[electric_vehicle_lover]

FIRST TIME EVER having "FOC" (very low resolution FOC) on the dirty cheap EBike controllers with a 8 bits microcontroller STM8: https://opensourceebikefirmware.bitbucket.io/

Very low resolution FOC seems to be working with my motor (EUC2 motor, low eRPM, at power supply 45V) but I had to do the interpolation every hall sensor signal and now the motor startup ok and do ok the interpolation.

My EUC2 motor, low eRPM, at power supply 30V.
Next image: without FOC, angle keeps constant. First part, motor at max eRPM speed of +100 and using about -500mA of IQ current. Second part, also using -500mA but I was blocking a bit the motor, so it could not get the max velocity:


Now with FOC enable and and just changing the velocity/PWM duty_cycle. We can see that FOC try to keep IQ current near zero:


Now as before, but on second part I tried to bloc with my hand and we can see angle going decreasing to very low values while the IQ current then goes to near zero value (it takes sometime to go to zero value, needs a PI controller):

[lizardmech]

That's not FOC, the stator iron does not magnetize and demagnetize instantly, without knowing the motor induction values you have no way to correctly align the field. It's effectively a BLDC controller with sinusoidal commutation to make it somewhat less noisy. When used on loads it's likely to have efficiency issues, it may not stay synchronized at higher ERPM I'm not sure if it's a good idea vs conventional BLDC, I think some of the chinese brands do it because the average customer will not know they aren't proper FOC controllers.

[electric_vehicle_lover]

34 minutes ago, lizardmech said:

That's not FOC, the stator iron does not magnetize and demagnetize instantly, without knowing the motor induction values you have no way to correctly align the field. It's effectively a BLDC controller with sinusoidal commutation to make it somewhat less noisy. When used on loads it's likely to have efficiency issues, it may not stay synchronized at higher ERPM I'm not sure if it's a good idea vs conventional BLDC, I think some of the chinese brands do it because the average customer will not know they aren't proper FOC controllers.

See here that Texas Instruments employees consider FOC using hall sensors (you can find many other examples on Texas Instruments forum):

And I just found this 8 bits motor controller as low as $17!! Every online shop sells them and everyone is happy because they find their motors silent and efficient, when compared to the 6 steps old generation controllers.

[lizardmech]

Yes you can use hall sensors on FOC, a sensorless observer or a combination of both but if you don't take into account the motors inductance and resistance you cannot achieve any sort of FOC scheme. That is why they even advertise those cheap controllers as "sinewave" rather than FOC or Vector control. It's called field orientated control because the control loop is supposed to take into account the properties of the magnetic field. A BLDC controller modified to output a sinewave does not come with any of the FOC advantages aside from slightly less noise.

[lizardmech]

In that link to Ti E2E forum the Ti motor control engineers specifically say not use hall sensors alone with FOC algorithms as they lack enough resolution to do it alone. Not sure why you think that supports what you're saying.

[electric_vehicle_lover]

11 hours ago, lizardmech said:

Yes you can use hall sensors on FOC, a sensorless observer or a combination of both but if you don't take into account the motors inductance and resistance you cannot achieve any sort of FOC scheme. That is why they even advertise those cheap controllers as "sinewave" rather than FOC or Vector control. It's called field orientated control because the control loop is supposed to take into account the properties of the magnetic field. A BLDC controller modified to output a sinewave does not come with any of the FOC advantages aside from slightly less noise.

See this document from OnSemi, with the implementation of FOC with only hall sensors, with tittle "Field Oriented Control of Permanent Magnet Synchronous Motors" that uses only hall sensors.

I will keep calling FOC but explaining that is a "very low resolution FOC" in the case of this EBike controller that uses a 8 bits STM8 microcontroller running at 16MHz only!!, and only measures 1 phase current.

 

Edited September 8, 2017 by electric_vehicle_lover

[lizardmech]

That image has the hall sensors feeding angle data into the park and inverse park calculations. Unless I'm missing it somewhere I cannot find any clarke, park or inverse park transformations in the code you made for the 8 bit controllers. If there's no calculation of the magnetic fields you can't have "Field orientated control".

[electric_vehicle_lover]

3 hours ago, lizardmech said:

That image has the hall sensors feeding angle data into the park and inverse park calculations. Unless I'm missing it somewhere I cannot find any clarke, park or inverse park transformations in the code you made for the 8 bit controllers.

Yes, because would not be possible to do that calculation on this so limited microcontroller.
But I found a simplification to read ID and IQ currents, avoiding the need to have a second phase current sensor and do clark and park calculations. I documented the simplification math here:

 

3 hours ago, lizardmech said:

If there's no calculation of the magnetic fields you can't have "Field orientated control".

That is what you say but others like OnSemi and TI employees consider that is also possible not making that calculation.

Edited September 8, 2017 by electric_vehicle_lover

[lizardmech]

54 minutes ago, electric_vehicle_lover said:

That is what you say but others like OnSemi and TI employees consider that is also possible not making that calculation.

Where?

If you're talking about that microsemi FOC guide, it's for a cortex-m3 + FPGA it's using the FPGA to do the complex FOC calculations. At no point does it suggest you can delete all the FOC sections. 

Edited September 8, 2017 by lizardmech

[electric_vehicle_lover]

1 hour ago, lizardmech said:

Where?

If you're talking about that microsemi FOC guide, it's for a cortex-m3 + FPGA it's using the FPGA to do the complex FOC calculations. At no point does it suggest you can delete all the FOC sections. 

I did quote what I was talking about:

6 hours ago, lizardmech said:

If there's no calculation of the magnetic fields you can't have "Field orientated control".

And my answer was:

That is what you say but others like OnSemi and TI employees consider that is also possible not making that calculation.

Seems you are not reading before answering.