Firmware

[KingQueenWong]

Thanks,i got it.I will buy a GEN1 board which only cost $9 in China(I know the GEN1 board's weakness,but It's very very very cheap for me to buy one).I will try my best to translate it(it's not difficult for me).You are right,the firmware of EBike should come first.

[electric_vehicle_lover]

@KingQueenWong can you please answer to my question: what are the main motivations for you to work on this project and also for the EBike firmware??

[KingQueenWong]

@electric_vehicle_lover

1.Just like you,I wanna learn motor control;

2.Beause of you insist on learn and study motor control in forum,which cause me just wanna join with you,at the same time,i could contribute my effort to many open source projects;

3.Thanks to forum,everyone can share ideas and informations in here;

4.I love electronic hardware and sofware;

5.The world always keep moving whether without me or nor;

6.You are the only one that love so many China’s electronic hardware and try to develop firmware for them,i can buy this hardware in China easily,why not take part in this project?   If the hardware is difficult for me to buy,nothing i can do for it,maybe i will keep quiet.If the project is a closed source project all,maybe need a explanation to support it actively;

7.I have ever been crazy about motor control for a while before i know your project and this forum issue,it's my first time discuss so much about motor control and join the open source project. Just like many people at once smoke tobacoo, they will can't stop liking it easily.I don’t know that it is good for me.Actually,i refuse smoking.

[electric_vehicle_lover]

@KingQueenWong good to know!! however, I was expecting that one point would be about environment.

[KingQueenWong]

This board is well as Microwork 30B4.

http://www.znphc.com/b2b/index.php/store/index/index/id/248.html

Operational amplifier: LM324

60VDC-12VDC: LM5007

MCU: STM32F103C8T6

5V: 78M05

3.3V: LM1117

SHUNT: 0.007Ohm

Gyro: MPU6050

Edited June 14, 2017 by KingQueenWong

[electric_vehicle_lover]

3 minutes ago, KingQueenWong said:

This board is well as Microwork 30B4.

SHUNT: 0.007

Near but not equal. That 3 power resistors to measure phase current makes the firmware to be different...

[electric_vehicle_lover]

On 12/06/2017 at 7:38 AM, lizardmech said:

Did he write it or just get access to generic EUC firmware? Pretty useful, shows they use software kalman filter combined with a complimentary filter.

The kalman filter is used only to get the process out the angle -- not for the balance controller. And the complementary filter is commented and instead they use the kalman filter.

For balance controller seems they do PD controller, with speed and position as inputs for the controller.

Does anyone knows what type of filter is this one: uint16_t ADCDataHanle(uint8_t ucChannel), on ADC.C file?? all the ADC measured values pass on that filter before being used.

[esaj]

1 hour ago, electric_vehicle_lover said:

The kalman filter is used only to get the process out the angle -- not for the balance controller. And the complementary filter is commented and instead they use the kalman filter.

For balance controller seems they do PD controller, with speed and position as inputs for the controller.

Does anyone knows what type of filter is this one: uint16_t ADCDataHanle(uint8_t ucChannel), on ADC.C file?? all the ADC measured values pass on that filter before being used.

Some sort of oversampling/averaging? It seems it adds a new value into the usBuf on each call:

    usBuf[ucCount]=usADCDate[ucChannel];
    ucCount++;
    if(ucCount>=5) ucCount=0;                     

Then the following for-loops sort the values in order of magnitude (looks like a bubble sort?). After that, it sums up everything except the first and last value in the usBuf and divides that by the size of the buffer - 2 (times LOST_VAL does nothing there, LOST_VAL = 1), giving out the average of the summed values. The sort is there probably just to drop out largest and smallest value.

#define FILTER_TIMES  5                 //Â˲¨¸öÊý
#define LOST_VAL 1                       //¶ªÆúÖµ
/*ADÊý¾Ý´¦Àí*/

uint16_t ADCDataHanle(uint8_t ucChannel)
{
    uint8_t i, j;
    static uint8_t ucCount=0;
    static uint16_t usBuf[FILTER_TIMES];
    uint16_t usSum=0;
    uint16_t usTemp;
    usBuf[ucCount]=usADCDate[ucChannel];
    ucCount++;
    if(ucCount>=5) ucCount=0;                     
    for(i=0;i<FILTER_TIMES-1; i++)//ÅÅÐò
    {
        for(j=i+1;j<FILTER_TIMES;j++)
        {
            if(usBuf[ i ]>usBuf[j])//ÉýÐòÅÅÁÐ
            {
                usTemp=usBuf[ i ];
                usBuf[ i ]=usBuf[j];
                usBuf[j]=usTemp;
            }
        }
    }      
    usSum=0;
    for(i=LOST_VAL;i<FILTER_TIMES-LOST_VAL;i++)usSum+=usBuf[ i ];
    usTemp=usSum/(FILTER_TIMES-2*LOST_VAL);
    return usTemp;   
}

 EDIT: For some reason, the forum software doesn't like i in brackets [ i ] , apparently it's the forum markup for italics, replaced with [ i ]'s

Edited June 15, 2017 by esaj
Stupid forum mangles up the code, throwing out [i] 's...

[esaj]

In general, the above is actually pretty bad code. The if(ucCount>=5) ucCount=0; has hardcoded size for the buffer, when the buffer is actually initialized in FILTER_TIMES size. Change FILTER_TIMES to 4 or lower, and you have a buffer overflow. Change it to higher value, and it won't write all the values in the buffer (but the loops will go through them as well as the average calculation), which can affect the average. The new values are entered in succession into the buffer, but the buffer order can change on any call due to the sorting, so it may be overwriting values out-of-order in comparison to when they were written into the buffer. It seems it's meant to be called 5 (or FILTER_TIMES) times in a row with same ucChannel-value, otherwise you're mixing values from multiple channels. If that's the case, why not store the 5 values first and then calculate the average? Is it even necessary to filter out the largest and smallest value? If it is, the sorting could be done at the time when the average is needed, saving clock cycles in a time-critical software, otherwise just add a new value in successive order. Since usSum is a 16-bit unsigned int, if the usADCDate[] -values can be more than (2¹⁶) / FILTER_TIMES-2, the sum may overflow and give out wrong value...  </rant> 

Edited June 15, 2017 by esaj

[electric_vehicle_lover]

12 hours ago, esaj said:

Some sort of oversampling/averaging? It seems it adds a new value into the usBuf on each call:

Then the following for-loops sort the values in order of magnitude (looks like a bubble sort?). After that, it sums up everything except the first and last value in the usBuf and divides that by the size of the buffer - 2 (times LOST_VAL does nothing there, LOST_VAL = 1), giving out the average of the summed values. The sort is there probably just to drop out largest and smallest value.

Thanks!! Makes good sense for me.

[electric_vehicle_lover]

@KingQueenWong this firmware seems unfinished, maybe a prototype and maybe only to evaluate the PD parameters of balance controller.
- the messages printed out over UART are for debug purposes only
- there are some needed functionalities that are on the code but not used: UnderVolt_Protect(); FallCar_Protect();
- the PD parameters for balance controller are adjusted/or defined using some hardware switches/keyboard. Those parameters should be needed for correct working of EUC but are not stored anywhere - although there are STMFLASH_Write(); and STMFLASH_Read(); on the code, again they are not used. So, maybe this firmware could be used to find this PD parameters before to hardcode them on the final production firmware that may be similar to this one.

It is really great to have this firmware for EUC, it clears out a lot of questions I had :-)

Edited June 16, 2017 by electric_vehicle_lover

[lizardmech]

I finally got instaspin running on custom hardware and EUC motors. Using that balancing code it would be easy to make an instaspin based EUC. Running on a 600V IGBT module as well.

 

[Tomek]

9 hours ago, lizardmech said:

I finally got instaspin running on custom hardware and EUC motors. Using that balancing code it would be easy to make an instaspin based EUC. Running on a 600V IGBT module as well.

 

looks pretty smooth! how does instaspin compare to VESC in terms of performance?

[lizardmech]

7 hours ago, Tomek said:

looks pretty smooth! how does instaspin compare to VESC in terms of performance?

Sensorless performance seems much better than the v4 VESC but I don't have V6 firmware to compare it to yet. Instaspin is much more advanced in terms of features with over modulation, field weakening and real time calculation of motor resistance to compensate for temperature changes. For some reason instaspin motor detection hates large direct drive outrunner motors. I was only able to get it running because I got a scooter with a 2kw inrunner motor and found instaspin could easily detect that motor, I was able to find the specific value instaspin always gets wrong during detection on large outrunners and use VESC to measure it.

Instaspin is pretty barebones it only includes software to detect the motor via debug and run it either in torque mode or speed mode.Anything else must be built by the developer.

[electric_vehicle_lover]

This is about the balance control algorithm - I just saw the video where a user did fall and did answer there:

I think that balance algorithm have inputs of ECU angle and motor speed, also depends on capacity for motor acceleration/power, that depends on the hardware capacity and rider weight, etc. Balance algorithm should have quite a big math involved (at least for me ;-) ) and I am afraid this companies got the original firmware from someone that did the math for a specific EUC but this companies after started to scale the EUCs for more speed, heavier EUCs, boards placed on different position on the EUC, etc, without redoing the math and the EUC just oscillate because it gets on instable point for the control system/balance algorithm. This is why I am taking time to make the OpenSource firmware, I am learning more math to understand the control algorithm, I do not want to copy from someone else without understand same ground base!!

 

Edited June 23, 2017 by electric_vehicle_lover

[Hunka Hunka Burning Love]

Not sure if this site has been mentioned already, but this fellow was working on his own Arduino based EUC.

http://www.diyelectriccar.com/forums/showthread.php/ovaltines-segway-clone-89471.html

 

[electric_vehicle_lover]

12 minutes ago, Hunka Hunka Burning Love said:

Not sure if this site has been mentioned already, but this fellow was working on his own Arduino based EUC.

http://www.diyelectriccar.com/forums/showthread.php/ovaltines-segway-clone-89471.html

Thanks!!

Simple math, just PID controller on balance controller. Uses DC motors.

Edited June 26, 2017 by electric_vehicle_lover

[lizardmech]

I have my controller running on the VESC 6 beta firmware now. I was running 70 amps through it for about 5 minutes without any issue, it doesn't make very good contact with the heatsink a properly made one could probably handle 100 amps or more, even at 70 amps the bullet connectors were becoming a limitation though.

[Tomek]

6 hours ago, lizardmech said:

I have my controller running on the VESC 6 beta firmware now. I was running 70 amps through it for about 5 minutes without any issue, it doesn't make very good contact with the heatsink a properly made one could probably handle 100 amps or more, even at 70 amps the bullet connectors were becoming a limitation though.

awesome! what motor/voltage were you testing? share some pics/vids!

[lizardmech]

a 2kw scooter motor, it's just running on a desk at the moment. VESC 6 firmware has an option that lets you run huge currents at low RPM for testing thermal properties. 

[electric_vehicle_lover]

Really nice balance example:

 

[KingQueenWong]

@electric_vehicle_lover I am busy in the last days.I try my best to do something for this open source project.I found some codes that designed for two wheel balance cars.The good news is that it use bldc motor too.The bad news is that it annotate in Chinese.The algorithm maybe very reasonable.I think this code will take us more thinkings about balance control.

bldc.rar

Edited June 28, 2017 by KingQueenWong

[electric_vehicle_lover]

52 minutes ago, KingQueenWong said:

@electric_vehicle_lover I am busy in the last days.I try my best to do something for this open source project.I found some codes that designed for two wheel balance cars.The good news is that it use bldc motor too.The bad news is that it annotate in Chinese.The algorithm maybe very reasonable.I think this code will take us more thinkings about balance control.

bldc.rar

Variable names and functions are in EN and even some comments, but others are in CN... I think I understand most that I need.

It is not FOC, it is 6 steps but scheme that handles regen/brake. They are using Kalman filter to get the angle from the inputs of gyroscope and accelerometer. For balance controller they are using PID -- just like the other chinese firmware you shared before.

Thank you!!

[electric_vehicle_lover]

@KingQueenWong added that code on github with parallel files translated to EN by google -- it helps to understand the comments: https://github.com/EGG-electric-unicycle/bldc_chinese_firmware_2

Edited June 28, 2017 by electric_vehicle_lover

[electric_vehicle_lover]

I would like to share some knowledge about the motors and the controller firmware (found this on my EBike motor, while developing the firmware for it for the EBike motor controller):

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!!