Jump to content
jayjay23

Firmware

Recommended Posts

:DThanks,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:P).I will try my best to translate it(it's not difficult for me).You are right,the firmware of EBike should come first.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
esaj    5,313
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 by esaj
Stupid forum mangles up the code, throwing out [i] 's...
  • Upvote 1

Share this post


Link to post
Share on other sites
esaj    5,313

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 (216) / FILTER_TIMES-2, the sum may overflow and give out wrong value...  </rant> :P

Edited by esaj
  • Upvote 3

Share this post


Link to post
Share on other sites
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.

  • Upvote 1

Share this post


Link to post
Share on other sites

@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 by electric_vehicle_lover
  • Upvote 1

Share this post


Link to post
Share on other sites
Tomek    225
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?

Share this post


Link to post
Share on other sites
lizardmech    647
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.

  • Upvote 2

Share this post


Link to post
Share on other sites

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 by electric_vehicle_lover
  • Upvote 1

Share this post


Link to post
Share on other sites
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 by electric_vehicle_lover

Share this post


Link to post
Share on other sites
lizardmech    647

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.

  • Upvote 3

Share this post


Link to post
Share on other sites
Tomek    225
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!

Share this post


Link to post
Share on other sites
lizardmech    647

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. 

Share this post


Link to post
Share on other sites

@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 by KingQueenWong
  • Upvote 2

Share this post


Link to post
Share on other sites
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!!

Share this post


Link to post
Share on other sites

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

  • Upvote 2

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

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

Create an account

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

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


×