Full Members
  • Content count

  • Joined

  • Last visited

  • Days Won


electric_vehicle_lover last won the day on May 29 2016

electric_vehicle_lover had the most liked content!

Community Reputation

657 Excellent


About electric_vehicle_lover

  • Rank
    Advanced Member

Profile Information

  • Gender
  • Location

Recent Profile Visitors

1,642 profile views
  1. 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.
  2. 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:
  3. // 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??
  4. 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 :-)
  5. @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.
  6. 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
  7. 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!!
  8. 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!!
  9. @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
  10. 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!!
  11. Really nice balance example:
  12. @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!!!
  13. Hi. Can you please explain in steps what happened and what you did?? How did the board failed? were you riding the EUC??
  14. Thanks!! Simple math, just PID controller on balance controller. Uses DC motors.
  15. Didn't understand your point.