electric_vehicle_lover

Full Members
  • Content count

    807
  • Joined

  • Last visited

  • Days Won

    2

electric_vehicle_lover last won the day on May 29 2016

electric_vehicle_lover had the most liked content!

Community Reputation

559 Excellent

5 Followers

About electric_vehicle_lover

  • Rank
    Advanced Member

Profile Information

  • Gender
  • Location
    Portugal

Recent Profile Visitors

1,264 profile views
  1. Not just that part of the circuit... things like power supply ICs, etc. But 30B4 is a good board to hack!! very simple technology and cheap!!
  2. I also think the same as you, about MicroWorks and Gotway controllers. 30B4 measures battery voltage/board input voltage on PA4 pin for STM32F103 and that is the only voltage it is able to measure. For Vin = 60V, PA4 pin = 2.35V. PA4 pin limit voltage should be about 3.2V, so, Vin max = 81.7V. BUT, we need to account the voltage produced when regen the battery/braking - which I don't know a safe margin that should be. I don't know what the original firmwares does with PA4 voltage pin value, but for sure low voltage limit and I don't know about a possible high voltage limit (to protect the battery pack??). Also Vin voltage value may be used on FOC motor control, but as a relative value (for sensorless algorithm at least) - I hope is not a a problem. With an OpenSource firmware, we will be able to do things like change 1 resistor on the circuit so the board can measure much high values than 81.7V!!
  3. I had to buy a few units of MicroWorks 30B4 boards to play with them draw the simplified schematic: https://github.com/EGG-electric-unicycle/documentation/wiki/MicroWorks-30B4-30kmh-controller-board-with-bluetooth If now one will do that for other boards, there will be no schematic for no one :-)
  4. I mean I have 2 different projects: develop firmware for EUCs and for EBikes, each one on a specific controller. I found many EBike controllers with microcontrollers very limited, without documentation, dedicated for automobile industry - probably the developers program them in assembly. I had luck to find one cheap and that is sold by the most famous Chinese website (BMSBattery) and with an STM microcontroller with a good documentation - but maybe 100x less available documentation than the STM32F103 from MicroWorks 30B4 board.
  5. There is something with motor control... I found more people referring about the EBike controllers switching between 2 modes, at low/medium and high speed: WhatcomRider wrote:The sine-wave controller is rated at 10-20 amps and is running in sensored mode. It is able to hold a steady speed as low as 3 rpm and smoothly ramps up to no-load speed. It is interesting that there is an audible change at around 130 rpm where it seems that the commutation shifts into a different mode. I even documented this before, but from a EUC cheap board that doesn't FOC: Pictures of electrical signals Seems there are 2 different ways to control the motor - one for low speed up to medium speed and other for higher speed. The 1st way seems specific to this application were a motor may work at very low speeds and even stopped. The 2nd way seems to be the standard 6 steps trapezoidal control. 1st way, low to medium speed: yellow: phase 1, blue: hall sensor signal. 2nd way, high speed: yellow: phase 1, blue: hall sensor signal. On the 1st way, when the wheel is stopped, there is a square (duty-cycle is 50%) on all the 3 phases (the signals are in phase) and the frequency is 15.625khz. https://github.com/EGG-electric-unicycle/documentation/wiki/Controllers A bit out off topic: I decided to look again to EBike controllers and decided to look for a cheap wide available controller that I could program the firmware. Seems EBike controllers (the cheap ones that most people use) aren't doing FOC. After many searching, I found the cheap widely available from a chinese well known shop that exist since 8 or more years, that sells a recent controller that uses STM8S105C6T6 -- this microcontroller is also from ST and can be programmed with the same cheap ST LinkV2 cable that I am using with MicroWorks 30B4 board. Also for this STM8S105C6T6, there are OpenSource firmware and libs, to program on Linux <3 STM8S105C6T6 is much more limited than STM32F103 of 30B4 board: (STM8S105C6T6) 16 MHz STM8S 8-bit MCU 32 kbytes flash VERSUS (STM32F103C8T8) 72 MHz ARM 32 bits 128Kbytes flash memory!!!
  6. After he replaced the board the wheel worked fine, but he recommended never to ride in deep sand because it will overload the board. IMO, bad quality firmware that is not looking at motor current and reducing or disable it in that case.
  7. Can you please put a picture of the board? If is something like this board https://github.com/EGG-electric-unicycle/documentation/wiki/MicroWorks-30B4-30kmh-controller-board-with-bluetooth I would say it can be the mosfet driving ICs that are turning always on the mosfets and burning them.
  8. Well, balance EUC using brushless motor seems a unique application. That's why most examples we can find are different, like there is a lot for bicycles that most of don't do regen or not quick directions change like needed for EUC. EUC have specific needs. I want to have knowledge to understand the unique application of EUC.
  9. I am almost sure the issue is for now on the way I drive the motor - and I need to do it correctly, with or without rotor angle correction that is given by the FOC. I think the issue is about the number of magnets vs number of coils, that don't give a correct number of 360 degrees for each electric rotation. Here a technical review with details about a bicycle motor with the same number of magnets and coils: Hihttps://www.electricbike.com/9c/ Running with hall sensors should be no problem for all speeds, as the FOC algorithm will detect the correct angle correction value and apply it continually. I don't think sensorless algorithm is a must have to get the correct angle, as even with an incorrect angle with increase speed, given by hall sensors, the algorithm find the correct angle by looking at Id current that must be zero, other values means the angle should be corrected with proportion. And this works well with my current code.
  10. Hi @Tomek. Not at full voltage and I just found the code I thought was working correctly for motor running on both directions, is not. At low voltage from 23V up to about 30V is ok but after that, in one direction, it goes wrong :-( So now I have 2 main issues: 1. control motor code for medium/high velocity is not ready yet 2. balance controller is not working and I don't know a possible algorithm... (current motor control code is ok for testing/develop balance algorithm). The latest video have PID on balance controller... and I tested many values and with/without D term. I am not sure PID is the correct algorithm for a balance controller... I found a good discussion here: http://www.plctalk.net/qanda/showthread.php?t=103066 Now I understand why EUCs keep increasing speed at a constant error angle, to have and increasing speed and so have acceleration because Force = m*a; Force is the force to needed to push the rider to vertical. "The first thing you need to understand and account for is, even in the small signal sense, this is a non-linear system. A given set of PID tuning values will only be valid for a very small range of angles. So you either have to scale your PID output based on the angle of the bike or you will have to perform what is referred to as gain scheduling, which means to change the PID gains as the bike angle changes. Ideally I think gain scheduling may be the better plan. However, that will require you to make up a mathematical model of your system so you have something to calculate the gains from." "I agree that PD is typical in controlling such "servo" systems with much inertia. Integral action is more useful for long-term trim in process control like chemical plants. But, I doubt basic feedback control will be sufficient for your process, which is trying to make an unstable system stable via active control. You most likely will also need "anticipatory" action, termed "feed-forward" or "open-loop control". These are algebraic equations that look at disturbance variables to the system and apply control output before a set-point error is realized. If you add the proper dynamics (lead/lag), they are differential equations. Feedback control is like trying to keep a car in its lane by looking straight down at a lane line, whereas feed-forward would be looking ahead, seeing the lane curve and start turning the wheel a little early. Another example, think of Space X trying to land a tall, skinny booster on a barge in heaving seas. Feed-forward inputs might be approaching waves, tilting rate of the platform, approaching air gusts, ... Even if you have only the controlled variable as an input, there are additions to PID that act similarly. Look at Delta Computer's RMC motion controllers, which have enhanced derivative terms." For the control motor code for medium/high velocity, I am being looking and thinking about the motor poles and the magnets... I am not sure the wave should perfectly sinusoidal... I want now to look for a PC oscilloscope that permit to register like continuous 10 seconds, were I can rotate the motor by hand and see the generated BEMF voltage - should be the same I need to generate with the firmware. I am looking to OpenSource software like Sigrok and cheap PC oscilloscopes from china and that works on Linux.
  11. If you know something or found anything online about, please share with me as I need to correctly control the motors and implement on the OpenSource firmware.
  12. I wish I have that knowledge... I think no one have in our community. And I think my motor control firmware is not perfect because maybe some unusual motor characteristics are on the EUC motors. I will remove the notifications from this thread and I hope to come back later to see the motor final running :-)
  13. Maybe they can wire a motor to pull more energy and that runs at a faster speed :-)
  14. The IMU MPU6050 angle read is now fast, at every 2ms. Before it was 15.6ms!! I implemented DMA read of I2C MPU6050 and increased the I2C speed to the max of 400kHz. The balance now reacts fast, in some parts seems near the commercial EUCs but is not there yet. Video: And now a screenshot showing the value of key variables, sent by bluetooth to PC.: - angle_error: this value should be zero when the EUC is in vertical. This value is the input for the balance controller algorithm, when increases to positive values the motor should rotate in "positive" direction. The inverse for negative values of angle_error. - duty_cycle: this value is the output of the balance controller and the input to the duty_cycle motor controller. Duty cycle should be zero when the EUC is on vertical --> angle_error = 0. - motor speed: is positive and negative, for clear indication of motor rotation direction. Motor speed is measured be reading the hall sensors period signal. Balance controller algorithm should run fast and is running now at 2ms (500 times every second). The max theorical speed is 1000 times a second, imposed by the IMU MPU6050. The next screenshot shows shows at left when I moved the EUC to one side and it balances. At the middle it shows oscillation as when I move it to fast, etc, as seen on the video:
  15. I think KingSong also use some STM32 microcontroller, not sure if is the same. I want first to add features on firmware only, so anyone take advantage of it, without touching wires. I already did a mod, adding and Arduino + RGB led bar, and it is really nice :-) Firmware should be flashed over bluetooth, so users will be able to flash using Android phones, I hope to make an app for it. No touch on hardware on first phase, then more customizations can be done. My girlfriend and my son of 6 years old, both ride, you can see videos here: https://github.com/EGG-electric-unicycle/documentation/wiki