Firmware

[zii]

Hi everyone,
Wonderful work you have done here, including the documentation. (Especially I love those great videos on control theory. Nice find.)

I am trying to run latest version of this firmware (modifiedFOC-motorMicroWorks30kmh) on a 1st generation board (I think it's 1st gen... well, it's the one with a single XL7001 12V, 5V regulator). What I want is to try and reproduce similar behaviour as the original Chinese firmware (just on a bench setup, not driving it ).
I commented out the section, which waited for some potentiometer value in the main.c and if I've understood correctly, what else I should do to get the desired behaviour:
(1) set the balance PID coefficients;
(2) set MOTOR_TYPE accordingly.

I was wondering if anybody could 
(a) say, am I missing something else that I should modify in code;
(b) tell what are PID parameters that have worked for You.

cheers,
Zigmars

[electric_vehicle_lover]

2 hours ago, zii said:

Hi everyone,
Wonderful work you have done here, including the documentation. (Especially I love those great videos on control theory. Nice find.)

Thanks for the feedback. I value a lot the documentation!!
 

2 hours ago, zii said:

I am trying to run latest version of this firmware (modifiedFOC-motorMicroWorks30kmh) on a 1st generation board (I think it's 1st gen... well, it's the one with a single XL7001 12V, 5V regulator).

You need 2nd gen boards for the latest firmware. That boards are only from MicroWorks...
Anyway, can you please share pictures of your board? where did you buy it??

If you are using the same MicroWorks 30B4 board, then your life will be easier.
Anyway, I suggest you to first connect a potentiometer and try run the motor... just after having the motor running, you can move to the balance controller...

Thanks for joining!!

[zii]

I attach a photo of my board, I got it around a year ago and I think this one is from MicroWorks.

2 hours ago, electric_vehicle_lover said:

Anyway, I suggest you to first connect a potentiometer and try run the motor... just after having the motor running, you can move to the balance controller...

I tried to do what You suggested and did manage to get motor to run with potentiometer speed control (I did have to set MOTOR_TYPE to MOTOR_TYPE_EUC1). 

To power the board I used a Lab PSU, with a 3A limit (@ 64V) and noticed that: 

1. at slow speeds there is irregular / not so smooth motion of the motor
2. in low speed region current is drawn much more aggressively than past some speed threshold, after which the current draw seems to be as good as with original Chinese firmware
3. going from low speed to higher speed, that threshold (in previous bullet) is at higher speed, than going from higher to lower (some hysteresis)
4. there is asymmetry such that in one direction the speed threshold for when rotation gets smooth is much higher than in the other

To my thinking, everything except the 4th point could be attributed to the fact that speed/position detection at low speeds isn't very good with either motor-mounted hall sensors or ACS712. What do You think, is that so?

cheers,
Zigmars

[electric_vehicle_lover]

4 hours ago, zii said:

I attach a photo of my board, I got it around a year ago and I think this one is from MicroWorks.

Do you know where did you bough it?? because MicroWorks do not have anymore an online shop and I would like to find a source with an EN shop online...

 

4 hours ago, zii said:

I tried to do what You suggested and did manage to get motor to run with potentiometer speed control (I did have to set MOTOR_TYPE to MOTOR_TYPE_EUC1). 

To power the board I used a Lab PSU, with a 3A limit (@ 64V) and noticed that: 

1. at slow speeds there is irregular / not so smooth motion of the motor
2. in low speed region current is drawn much more aggressively than past some speed threshold, after which the current draw seems to be as good as with original Chinese firmware
3. going from low speed to higher speed, that threshold (in previous bullet) is at higher speed, than going from higher to lower (some hysteresis)
4. there is asymmetry such that in one direction the speed threshold for when rotation gets smooth is much higher than in the other

To my thinking, everything except the 4th point could be attributed to the fact that speed/position detection at low speeds isn't very good with either motor-mounted hall sensors or ACS712. What do You think, is that so?

Good description. I would say the issue is with your motor phases and hall sensors correct sequence... just like I have

#define MOTOR_TYPE_EUC1             0
#define MOTOR_TYPE_EUC2             1
#define MOTOR_TYPE_MICROWORKS_500W_30KMH     2

I would say you need to find the correct angle value at motor very low speed, for each direction.

Do like this:

1. disable the FOC by commenting this line "position_correction_value = (int) correction_value;" and do "position_correction_value = 0".
2. You need to play with MOTOR_ROTOR_DELTA_PHASE_ANGLE_RIGHT value until the motor starts well and run with the lowest current value and noise possible, at low speeds -- after that speed you need to enable FOC again and you will see the difference of enabling FOC at medium and high speeds.

Then do the same for the LEFT direction, because that angle value may be different.

When you have it, maybe you can do a pull request with the changes.

I am very happy to have other developer really put the hands on the code!!!!!!! <3 <3

Edited July 6, 2017 by electric_vehicle_lover

[electric_vehicle_lover]

@zii, when you the motor running ok, I think you will want to move to the balance controller.

You know that the motor interface is set_pwm_duty_cycle(value);

The balance controller can be implemented on the function balance_controller(); as you can see the code. Right now it have as input the IMU_get_angle_error (); and as output the set_pwm_duty_cycle(value); -- I think the balance controller may need motor current speed and that is not yet implemented as should be needed but I think should be simple to do.

[electric_vehicle_lover]

12 hours ago, zii said:

I commented out the section, which waited for some potentiometer value in the main.c

Be careful!! That is needed because on development you may make a "short-circuit" on the mosfets (like some error on the PWM values) and the board will not boot and you will not be able to flash it easily again... well, maybe just keep it on BOOTLOADER mode so it will not run your bad firmware.

By the way, was simple for you to flash the first firmware? hadn't you to first put the board on bootloader mode to be able to flash the first firmware using SWD??

And the current firmware does not balance!! you will need to implement the balance controller if you want it working :-)

[zii]

@electric_vehicle_lover

OK, I got the motor running smoothly quite easily by the procedure You stated - manually calibrate MOTOR_ROTOR_DELTA_PHASE_ANGLE_RIGHT and the ...LEFT one as well. Here are the values that worked for me:
#if MOTOR_TYPE == MOTOR_TYPE_EUC1
    #define MOTOR_ROTOR_DELTA_PHASE_ANGLE_RIGHT     5
    #define MOTOR_ROTOR_DELTA_PHASE_ANGLE_LEFT    -52

About Your question regarding my purchase of the board(s)... I'll tell a little more of my backstory:
Almost a year ago I was asked if I could develop electronics and firmware for something similar to electric unicycle, so I was given few of these boards. As I, quite frankly, did not estimate correctly the time this all would take (given, I'm also studying at university, and have not previously done PMSM control), I have not finished the project to this day. 

In the year, however, I did try to port the VESC code to non-ChibiOS STM32F4 ("bare metal"), read a lot of publications/materials about FOC control, state observers, SVM, PMSM.

So, about STM32 flashing - as I remember I also wired JLink programmer to NRST pin of the MCU. So there was no problem with that back then. Now I don't need that NRST pin, as I had to fix a non-working board from multiple non-working, thus I used hot air to resolder the same MCU I used a year ago.

So now I read your code more thoroughly and most of it makes sense to me. In few places I didn't understand what was the idea of that part of the code. 

• For example, pwm_duty_cycle_controller.c:420-421 - what is the idea behind this re-calculation.
• in the PWM_PERIOD_INTERRUPT() interrupt, I tried to follow the TIM3 setup code, and it seemed to me that it was configured to fire event only a single time per upcount + downcount (so as no if(...) would be required), and I can confirm with an LED and oscilloscope, that it indeed fires only once per 50us cycle. (Actually it did fire twice if I did turn the LED off after TIM_ClearITPendingBit(TIM3, TIM_IT_Update); , but that seems understandable)
• I don't fully understand the part with #define DO_INTERPOLATION 1, which You have currently implemented in place of an observer.

To my understanding (and correct me if I'm wrong), duty_cycle (by your naming convention) sets the SVM PWM amplitude, which effectively sets the power that should go to the motor, and by turning potentiometer to some value, MCU just tries to put current 90 degrees ahead of the current motor angle, such that all the power goes into torque, so effectively, it just tries to run it as fast as the friction and electrical losses cancel the power put into it. And (disregarding two possible directions) for low potentiometer values, it will rotate slower, because the losses are lower and for higher potentiometer values it will rotate faster as the losses become higher.
(BTW, I'd call duty_cycle something like "power" / "amplitude", as the actual duty cycle of the PWM changes as per SVM).

Moreover, I tried cleaning up / refactoring some of the code for me personally to be easier to follow. I could do a pull request (like this), but I did not create a new branch... What should I do? I would appreciate some help in this, if possible.

Little bit about what I noticed in the code:
About the SVM waveform: I saw that it was not generated to cover full amplitude of 0 to 1800. Also, the 0th element of array is not 900, so at angle 0, the SVM angle is not 0. In my SVM version I corrected these things. I think that this corresponds to " -1 " you have in https://github.com/EGG-electric-unicycle/firmware-gen2_boards/blob/modifiedFOC-motorMicroWorks30kmh/motor_foc.c#L145here.

Also, there were some if-else statements, for which if and else parts did the same thing. And that same code copied 3 times with 1 parameter change (I did put it into inline function).
And then I checked, what You were printing out in every 10th FOC_slow_loop() iteration. And for me i_d, i_q values are not stable at all, which I expect to be almost constant.

Cheers,
Zigmars

Edited July 17, 2017 by zii

[electric_vehicle_lover]

2 hours ago, zii said:

So now I read your code more thoroughly and most of it makes sense to me. In few places I didn't understand what was the idea of that part of the code. 

• For example, pwm_duty_cycle_controller.c:420-421 - what is the idea behind this re-calculation.

  // apply minimum duty_cycle value
  int temp1 = 1000 - MOTOR_MIN_DUTYCYCLE;
  _duty_cycle = MOTOR_MIN_DUTYCYCLE + (((_duty_cycle * temp1) + MOTOR_MIN_DUTYCYCLE) / 1000);

I found that there are a minimum duty_cycle value after the motor start to move, like if there is a gap with low values. This code is to remove that gap and I expect it to improve the quick motor direction change rotation that I think is important for the balance of EUC.

2 hours ago, zii said:

• in the PWM_PERIOD_INTERRUPT() interrupt, I tried to follow the TIM3 setup code, and it seemed to me that it was configured to fire event only a single time per upcount + downcount (so as no if(...) would be required), and I can confirm with an LED and oscilloscope, that it indeed fires only once per 50us cycle. (Actually it did fire twice if I did turn the LED off after TIM_ClearITPendingBit(TIM3, TIM_IT_Update); , but that seems understandable)

Maybe later I will need to revise that code. I am not working on this project currently but on the EBike firmware that uses STM8 and that have a PWM module that is equal. The STM8 is much more limited and I am learning more and more, the code for motor control is the same and later I will be back to this project and apply any improvements. I did there this code and what I know now:

TIM_TimeBaseStructure.TIM_RepetitionCounter = 1; // will fire the TIMx_UP_IRQHandler at every PWM period (64us)

If RepetitionCounter == 0, will fire every upcount + downcount, so, 2 times every PWM cycle. With RepetitionCounter == 1, just like current code is, just fires in one direction (I don't know which one) and so 1 times every PWM cycle and that this if:

  if (!TIM_DirMode(TIM3))

can be avoided.

2 hours ago, zii said:

• I don't fully understand the part with #define DO_INTERPOLATION 1, which You have currently implemented in place of an observer.

You can read more after "Initial Motivation: Can the Synchronous Current Regulator be modified to work with
Hall effect sensor inputs, with interpolation?" from Shane Colton documentation: https://eggelectricunicycle.bitbucket.io/EmbeddedFiles/19-SCquals.pdf

I just commit some comments to code to clarify this.

 

2 hours ago, zii said:

Moreover, I tried cleaning up / refactoring some of the code for me personally to be easier to follow. I could do a pull request (like this), but I did not create a new branch... What should I do? I would appreciate some help in this, if possible.

I am not expert on git and I think this would be the first pull request on this project. I think you can do anyway a branch in your repo and do the pull request of that branch.

2 hours ago, zii said:

Little bit about what I noticed in the code:
About the SVM waveform: I saw that it was not generated to cover full amplitude of 0 to 1800. Also, the 0th element of array is not 900, so at angle 0, the SVM angle is not 0. In my SVM version I corrected these things. I think that this corresponds to " -1 " you have in https://github.com/EGG-electric-unicycle/firmware-gen2_boards/blob/modifiedFOC-motorMicroWorks30kmh/motor_foc.c#L145here.

Good!! Waiting for your pull request ;-)

 

2 hours ago, zii said:

Also, there were some if-else statements, for which if and else parts did the same thing. And that same code copied 3 times with 1 parameter change (I did put it into inline function).
And then I checked, what You were printing out in every 10th FOC_slow_loop() iteration.

Printing every 10th FOC_slow_loop() iteration, if I remember, to not print to much fast because maybe it would negatively affect the FOC_slow_loop controller of the motor. I think this code works ok for a prototype and is ok to develop the balance controller, after that I would revise and improve the code were possible.

 

2 hours ago, zii said:

And for me i_d, i_q values are not stable at all, which I expect to be almost constant.

Please compare with my results:

Also see this message, was the last one were I improved the motor control:

Also see this message, may apply to your motor??

 

Edited July 17, 2017 by electric_vehicle_lover

[zii]

@electric_vehicle_lover
Ok, so firstly, I have pushed my adjusted code onto this new branch on my fork of Your code. I named one of the commits such to indicate that it was the one used to get the following plots from SerialPlot. (BTW, as I am using OS X, I had to compile SerialPlot myself, which took me almost a day to find all the problems with libraries, cmake & code).

As I said previously I did rename a few things the "my way"; also the tabs that I use for whitespace somewhat makes it now a bit harder to follow actual diff's not just whitespace changes. 

So... I did try to do similar tests to what You had done and plot motor_rotor_position, interpolation_angle, interpolation_sum and interpolation_angle_step. In the following plot You can see values from when I (with pot) decelerate motor until it goes into reverse direction and keep it there (with practically slowest speed that the motor still rotates). And then in the motor_rotor_position part of the plot You can see how interpolation manages to start and track angle only after single electrical cycle.

In the next one I tried to torture the interpolation part with rapid pot turning at slow speeds.


So after that I also did test similar to Your other plot with id, iq, correction_value, motor_speed and duty_cycle (overlayed & multiplot respectively); as I use power supply with current limit set to 850 mA there are times where You can see that it has kicked in:

 

Thus far it doesn't seem far from what You got. But now I checked what happens with id, iq values at slow speeds and this is what i got (which I did not expect):

The slower the motor rotates, the greater the amplitude for id, iq oscillation. I did not expect it to be so bad.

In this last plot at the middle time of the time axis the motor has stalled.

I remember testing original firmware long ago, and seeing that it manages very smoothly and continuously to slow down wheel with great torque to zero speed (I was applying force with hand). I also remember that it seemed to me that the controller had some minimum speed, below which it would NOT actively regulate (speed would slowly only go down), but it still managed to do the continuous slow-down.

Is it correct to say, that currently set_pwm_duty_cycle(target) is basically a constant torque controller, not a constant speed controller, thus low values of torque (or duty_cycle or potentiometer value) obviously translate to the fact that I can easily hold it and it won't be able to "escape" my hand's hold?

What does everyone else think about this FOC slow speed behaviour?

P.S. I will now try to do some more tests of my own...

 

Edited July 21, 2017 by zii

[electric_vehicle_lover]

44 minutes ago, zii said:

@electric_vehicle_lover
Ok, so firstly, I have pushed my adjusted code onto this new branch on my fork of Your code. I named one of the commits such to indicate that it was the one used to get the following plots from SerialPlot. (BTW, as I am using OS X, I had to compile SerialPlot myself, which took me almost a day to find all the problems with libraries, cmake & code).

I will be away on holidays on next days, I will see your branch after.

Yeah, but I didn't found better solution than SerialPlot and it is really important that tool, as we can see by your usage.

 

44 minutes ago, zii said:

Thus far it doesn't seem far from what You got. But now I checked what happens with id, iq values at slow speeds and this is what i got (which I did not expect):

The slower the motor rotates, the greater the amplitude for id, iq oscillation. I did not expect it to be so bad.

 

Is it correct to say, that currently set_pwm_duty_cycle(target) is basically a constant torque controller, not a constant speed controller, thus low values of torque (or duty_cycle or potentiometer value) obviously translate to the fact that I can easily hold it and it won't be able to "escape" my hand's hold?

About the oscillations you refer, didn't had time to see in detail your graphs (will do it later) but I guess you are doing your tests with motor with no load. If so, remember that current is very low and should have high noise... IMO hardware have low resolution for current readings and that seem to not be a problem as in real life motor will have a big load/currents. As we can see, with that hardware the motor still runs good, IMO.
But I think you did even more tests that I did by myself and all that you share have great value!!

set_pwm_duty_cycle(target); is not a constant torque controller. To have a torque controller, motor current need to be controlled with feedback, using PID controller. For a speed controller, the same but having speed as input to the PID controller. set_pwm_duty_cycle(target); takes that output on torque controller, when we developed one but I think we will not need a torque controller...

You didn't refer the max current controller on the firmware... please see it and define different values an then try block the motor and see the max current controller working.
But yes, without the max current controller disable, low PWM means low energy on the motor and you should be able to block it.

 

[lizardmech]

On 7/17/2017 at 8:39 PM, zii said:

In the year, however, I did try to port the VESC code to non-ChibiOS STM32F4 ("bare metal"), read a lot of publications/materials about FOC control, state observers, SVM, PMSM.

Have you looked at any of the texas instruments MCUs? I found a really good open source FOC for their delfino MCUs. It's set up for a large industrial servo all it really lacks is things like motor detection and hall sensor support. It already has a sliding observer for sensorless FOC but the VESC one may be more advanced. It wouldn't be hard to take some vesc code and turn it into a decent controller for vehicles.

[electric_vehicle_lover]

@zii, I am lazy to merge your branch but I added you as a member on the https://github.com/EGG-electric-unicycle/

Please go ahead and make the changes you think will improve the firmware. Anyway, I am not working on the firmware on this phase but I will keep looking at this forum message and the git commits. I may be back in 2 or 3 months. Thank you.

[zii]

 

On 7/22/2017 at 9:59 PM, lizardmech said:

Have you looked at any of the texas instruments MCUs? I found a really good open source FOC for their delfino MCUs. It's set up for a large industrial servo all it really lacks is things like motor detection and hall sensor support. It already has a sliding observer for sensorless FOC but the VESC one may be more advanced. It wouldn't be hard to take some vesc code and turn it into a decent controller for vehicles.

I have not looked at those, but I am somewhat scared of the low level configuration that would be needed by other microcontrollers (non-STM32), which I would have no experience.
But I would love to read the code, if it is easily available... I see You have posted about this also on endless-sphere.com . @lizardmech, have You extracted / published the code that comes with that MCU.

On 7/25/2017 at 11:40 AM, electric_vehicle_lover said:

@zii, I am lazy to merge your branch but I added you as a member on the https://github.com/EGG-electric-unicycle/

Please go ahead and make the changes you think will improve the firmware. Anyway, I am not working on the firmware on this phase but I will keep looking at this forum message and the git commits. I may be back in 2 or 3 months. Thank you.

OK, Thank You for adding me. Though, I do not currently see any need to specifically change things in your branches - as I have pushed my changes to my fork (also merged your added comments) & it is available there if anybody wants. 

I did record in arrays 1000 samples of motor_rotor_position, id, iq, hall_position (respectively in plot) and then transmitted them to computer via bluetooth. Half of the screen is with lower rotational speed, the other - with higher.
id and iq appear to be quite "noisy". 

As I did value-saving in fast loop ( @ 20 kHz ), I interpret those peaks as the id, iq value before being averaged by EMA filter. 

You can see that the maximums and minimums for that periodic waveform of iq (disregarding non-filtered values of iq), correlates to the hall sensor position waveform. I think that this oscillation of iq value should be eliminated before continuing to balance controller. So I think it would be worth for be to do what @electric_vehicle_lover suggested:

On 7/1/2017 at 4:28 AM, electric_vehicle_lover said:

My Cute 85/Q85 motor hall sensors signals aren't exactly at 60º each change!! The time between each pulse have some relevant difference and I was considering on the firmware that the time was always equal --> 60º... so after I found this issue, I decided to depend only of one pulse that happens at every 360º, and works well!! The motor is quitter, I think more than the original firmware and the power supply voltage don't change/rise like what happens with the original firmware!!! I bet original firmware is doing as I was, considering every pulse of 60º while they aren't. I am really happy that I found and understood this issue, was very strange before, even with original firmware, to have the motor rotating and see the power supply voltage increase with the increased motor speed!!

So I have a question - for what exactly do you depend only for that "once per 360º" value?
I might try to automate all the "motor rotor correction angle" calculations, and then the hall sensors could be calibrated individually much easily.
 

[electric_vehicle_lover]

1 hour ago, zii said:

You can see that the maximums and minimums for that periodic waveform of iq (disregarding non-filtered values of iq), correlates to the hall sensor position waveform. I think that this oscillation of iq value should be eliminated before continuing to balance controller. So I think it would be worth for be to do what @electric_vehicle_lover suggested:

So I have a question - for what exactly do you depend only for that "once per 360º" value?
I might try to automate all the "motor rotor correction angle" calculations, and then the hall sensors could be calibrated individually much easily.

Please see here the code, on hall_sensors_read_and_action (void) and motor_fast_loop (void) , https://github.com/OpenSource-EBike-firmware/BMSBattery_S_controllers_firmware/blob/SVM/main.c
The interpolation now restarts every 360º and not every 60º!!

I also thought that could be needed to calibrate individually the timings of each hall sensors but in the end, at least in my motor and for my tests, is not needed and the result seems good -- but on a firmware that does not do FOC and a motor that seems to rotate relatively fast. One thing I am pretty sure, the original firmware of this Kunteng KT motor controller for EBikes, considers every 60º and the result is worst.

Looking forward to your results :-)

[lizardmech]

2 hours ago, zii said:

I have not looked at those, but I am somewhat scared of the low level configuration that would be needed by other microcontrollers (non-STM32), which I would have no experience.
But I would love to read the code, if it is easily available... I see You have posted about this also on endless-sphere.com . @lizardmech, have You extracted / published the code that comes with that MCU.

I uploaded them here, there's a bunch of drivers and non motor control stuff I left out. The motor control code is modular and segmented into various functions the main c file mostly includes MCU specific code and points to the macros then runs a control loop, there's a bit of junk in it because it's for a dev kit with 2 different encoder types and 3 different current sense options. Motor control algorithms are in /include/motorcontrol sliding observer is named smopos.h. IDDK_PM_Servo_F2837x-Settings.h holds the configuration settings.

The main thing I like about it is the motorcontrol sections are abstracted from MCU specific code.

https://github.com/lizardmech/ti_delfino

[electric_vehicle_lover]

Found an EBike controller that uses the STM32F103 and that does FOC. The company seems popular and have also controllers for scooters that can handle up to 500A.

----

https://opensourceebikefirmware.bitbucket.io/Controllers--Lishui_motor_controllers.html

Lishui motor controllers

Nanjing Lishui Electronics Research Institute Co., Ltd.
http://www.lsdzs.com

I got many information about this controller on some message forums like this.
• this controller can be bought from BMSBattery
• has a LCD connector that uses UART TX and RX pins for sending/receiving data
• there is a bluetooth module and app
• this controller does FOC and uses STM32F103C6T8 with 128kbytes flash memory
• Lishui provides an application to update the firmware seems an encrypted firmware file, possible for the proprietary Lishui bootloader
◇ Documentation: Linked file: User's_Manual.pdf
◇ Software: Linked file: 568d276e0188c.rar

Lishui provides an application to configure the firmware options:
◇
◇

[electric_vehicle_lover]

Another inspiration: a guy worked to discover how the hoverboard main board that control the 2 motors: http://drewspewsmuse.blogspot.pt/2016/06/how-i-hacked-self-balancing-scooter.html

Seems there is a main boar to control the motors and secondary boards to read tilt angle and send that value to main board. I want to do something alike: (Arduino Blue Pill (STM32F103) + MPU650 small board) ---> balance algorithm that input and outputs data over UART to the brushless motor controller (ultra cheap chinese EBike motor controller that does FOC).

 

Edited August 7, 2017 by electric_vehicle_lover

[electric_vehicle_lover]

I will make a talk with title "Develop embedded soft/firmware for chinese motor controllers" in PixelsCamp, Lisbon, on 30 September.

PixelsCamp is the most yearly relevant event, in Portugal, for the software, firmware and hardware developers -- 3 days of non-stop tech, talks, workshops and a 48 hour programming competition: https://pixels.camp/



The description of my talk - original link: https://github.com/PixelsCamp/talks/pull/161

Develop embedded soft/firmware for chinese motor controllers

Description

Since some years, I am being developing OpenSource firmware for the chinese electric motor controllers that are used on small electric vehicules: hoverboards, skates, unicycles and bicycles.

This chinese controllers are dirty cheap, capable and with ok quality. Since they optimize their products for price, they have very limited resources - developing firmware for their controllers means learning how to make "the thing" in a unique and creative ways, optimizing all the processing power and memory used.

Why I decided strategically to develop firmware for the cheap chinese controllers? Because the market is flooded with them: they work well and are easy to get. This OpenSource firmware is the first in the world and I hope it will be used by many users as possible, shapping the future like Arduino did.

I would like to present my experience, from developing the firmware and up to try gather a community and contact with people all over the world (using a lot Google translator for german, chinese, etc).

[Rehab1]

16 minutes ago, electric_vehicle_lover said:

I will make a talk with title "Develop embedded soft/firmware for chinese motor controllers" in PixelsCamp, Lisbon, on 30 September.

 

16 minutes ago, electric_vehicle_lover said:

The description of my talk - original link: https://github.com/PixelsCamp/talks/pull/161

Congratulations on the acceptance of your talk! I read the synopsis. Strong stuff!   Please keep us updated!

[lizardmech]

41 minutes ago, electric_vehicle_lover said:

Since some years, I am being developing OpenSource firmware for the chinese electric motor controllers that are used on small electric vehicules: hoverboards, skates, unicycles and bicycles.

This chinese controllers are dirty cheap, capable and with ok quality. Since they optimize their products for price, they have very limited resources - developing firmware for their controllers means learning how to make "the thing" in a unique and creative ways, optimizing all the processing power and memory used.

Why I decided strategically to develop firmware for the cheap chinese controllers? Because the market is flooded with them: they work well and are easy to get. This OpenSource firmware is the first in the world and I hope it will be used by many users as possible, shapping the future like Arduino did.

I would like to present my experience, from developing the firmware and up to try gather a community and contact with people all over the world (using a lot Google translator for german, chinese, etc).

Honestly I don't really understand what you want, you say you want to collaborate with people but I don't think you have been willing to help out with a single line of code with anyone trying to make open controllers. Trying to build firmware for microworks controllers was worth a try but there was little progress and now due to it being proprietary hardware supply was cut off and the project died. We have multiple hardware and software options ready to use but haven't been finished due to being unable to find an embedded programmer to help out with the final few features, now you're giving speeches about open source EUC firmware that you didn't make yet? It's probably like a week or two of part time work for someone with experience in embedded programming but you haven't been willing to help over the span of almost 2 years?

[electric_vehicle_lover]

33 minutes ago, lizardmech said:

Honestly I don't really understand what you want, you say you want to collaborate with people but I don't think you have been willing to help out with a single line of code with anyone trying to make open controllers.

I just cooperate in what I believe that will have adoption. I simple don't believe in the adoption of your hardware when we already have on the market, cheap EBike controllers using similar hardware as MicroWorks boards -- boards capable of doing FOC and using STM32F103 (and yes, my main focus now are not EUCs but EBike controllers - that will also work for the EUC application as motor controllers):

 

33 minutes ago, lizardmech said:

now you're giving speeches about open source EUC firmware that you didn't make yet?

Sure I did for MicroWorks 30B4, see Zii message: http://forum.electricunicycle.org/topic/1109-firmware/?do=findComment&comment=105903
Current firmware works for my 2 different EUC motors + Zii motor, doing simplified FOC and max current and over current protection.
If you read the synopsis of my talk, you will see that I will talk about the firmware of motor controllers.

Edited August 16, 2017 by electric_vehicle_lover

[lizardmech]

2 hours ago, electric_vehicle_lover said:

I just cooperate in what I believe that will have adoption. I simple don't believe in the adoption of your hardware when we already have on the market, cheap EBike controllers using similar hardware as MicroWorks boards -- boards capable of doing FOC and using STM32F103 (and yes, my main focus now are not EUCs but EBike controllers - that will also work for the EUC application as motor controllers):

A discontinued EUC controller and an ebike controller that doesn't support the voltages and current levels found in EUC will have wider spread adoption than making open hardware anyone can build? Really makes you think.

 

2 hours ago, electric_vehicle_lover said:

Sure I did for MicroWorks 30B4, see Zii message: http://forum.electricunicycle.org/topic/1109-firmware/?do=findComment&comment=105903
Current firmware works for my 2 different EUC motors + Zii motor, doing simplified FOC and max current and over current protection.
If you read the synopsis of my talk, you will see that I will talk about the firmware of motor controllers.

Porting Shane Coltons code was a decent effort but it didn't even replicate the basic functionality found on the FOC boards that have the twin allegro current sense. People tried to explain on endless sphere the code you have is not FOC, it's just an open loop speed controller that uses the hall sensor for electrical angle and outputs sinewave rather than 6 step bldc commutation. You can't have field orientated control if you aren't calculating the magnetic flux of the magnetic field to begin with. Seems kinda disingenuous to give people a lecture about making open source FOC controllers when you're hostile to open source hardware, ported the primary motor code from another project and the controller doesn't actually offer FOC motor control.

[electric_vehicle_lover]

32 minutes ago, lizardmech said:

 Seems kinda disingenuous to give people a lecture about making open source FOC controllers when you're hostile to open source hardware, ported the primary motor code from another project and the controller doesn't actually offer FOC motor control.

You are assuming wrong things about my talk.

I am not hostile to open source hardware, nor even to your project - I am mostly ignoring your project for the reasons I already told

I feel the need to start ignoring your messages because you are being unfriendly - as this is from long time ago.

[lizardmech]

3 minutes ago, electric_vehicle_lover said:

I am not hostile to open source hardware, nor even to your project - I am mostly ignoring your project for the reasons I already told

That's not true though multiple people have suggest many different hardware options ranging from existing low cost open hardware to designing new hardware. At every opportunity you have refused to work with anyone using opensource hardware instead telling people to buy microworks products. Then when the microworks board option fell through your first reaction is to change to even worse proprietary hardware from china with next to no documentation? You have no way to know if they make hardware revisions that break open firmware or even decide to discontinue the model without warning. What happens if people bought those microworks controllers based on that hackaday article that implied there was open source firmware? Very bad for opensource development in general. 

[KingQueenWong]

10 hours ago, lizardmech said:

That's not true though multiple people have suggest many different hardware options ranging from existing low cost open hardware to designing new hardware. At every opportunity you have refused to work with anyone using opensource hardware instead telling people to buy microworks products. Then when the microworks board option fell through your first reaction is to change to even worse proprietary hardware from china with next to no documentation? You have no way to know if they make hardware revisions that break open firmware or even decide to discontinue the model without warning. What happens if people bought those microworks controllers based on that hackaday article that implied there was open source firmware? Very bad for opensource development in general. 

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.