electric_vehicle_lover

Full Members
  • Content count

    931
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by electric_vehicle_lover

  1. @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.
  2. 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. 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.
  3. Love that idea, I would love to have one as I like a lot to pedal!! And yes, as someone already told, Justin did that. Justin talks about their proprietary motor controller and Cycle Analyst -- since it is their own technology, they can do that new devices. We don't have such technology and so we can do that. This is where OpenSource plays a crucial role, we can join the community efforts and develop our own technology and then everyone will be able to build new different devices and in the end, accelerate the adoption of electric vehicles that are really important to protect the environment!! (just like Tesla mission). For the firmware and controller board, we still don't have an OpenSource solution for EUC. But I am being developing (with a help of other members) OpenSource firmware for EUC and it is not far to have a working prototype... see here:
  4. // 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. 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. 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. 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. Good!! Waiting for your pull request ;-) 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. 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??
  5. 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 :-)
  6. @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.
  7. 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... 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
  8. Thanks for the feedback. I value a lot the documentation!! 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!!
  9. 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!!
  10. @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
  11. 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!!
  12. Really nice balance example:
  13. @Rehab1 GREAT!!! that is very important for users, kind of DIY, be able to do their test systems... I will need something alike when testing my DIY EUC with the OpenSource firmware!!!
  14. Hi. Can you please explain in steps what happened and what you did?? How did the board failed? were you riding the EUC??
  15. Thanks!! Simple math, just PID controller on balance controller. Uses DC motors.
  16. Didn't understand your point.
  17. I bet not. Can you guys please provide me the files they sent so I can look them and find it is proprietary?? Maybe I will be able to make a backup so later if something goes wrong we have a backup of such firmware...
  18. 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!!
  19. I can't read everything that everyone already wrote but seeing the video and the explanations of the author, I would say the problem can be the balance algorithm that fails on that situation... 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!! I think EUC is dangerous, at least the potential problems of falling at high speed are really scary!! That's why I am being looking more at 2 wheels... to travel at low speed to minimize the risk, looks like a toy for me as I am interested on commuting. I stopped using hoverboard after 5 days because I understand was not safe to ride at more than 10km/h. Now the EUC, I would say 15km/h is a safe velocity but very slow compared to the 25km/h of an EBike or other 2 wheel devices.
  20. Thanks for sharing all this great information!!!! About the issue, I had the same when developing my OpenSource firmware, that the motor would run faster to one side and with a bit less noise... and that happen when I were using no FOC control, where the FOC angle wasn't adjust automatically and was hardcoded -- and depends only on the hall sensors signals timmings. And this makes sense in my experience, if that angle is not "like at the middle", the motor will run with different speeds on each side. I would say the hall sensor you used for some reason outputs his signal with different timing. I would try to change all the 3 for the same hall sensor reference.
  21. Changed my opinion about that, please read here:
  22. Maybe find the pin that does calibration on older board and try the same on the new one? I mean the pin of the STM32F103
  23. @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 :-)
  24. Thanks!! Makes good sense for me.