Firmware

[electric_vehicle_lover]

I configured the system clock to be 64 MHz (this is the max clock speed possible using the HSI - High Speed Internal oscillator).

The most important line:

  /*  PLL configuration: PLLCLK = HSI/2 * 16 = 64 MHz (this is the max clock speed possible using HSI) */
  RCC->CFGR |= (uint32_t)(RCC_CFGR_PLLSRC_HSI_Div2 | RCC_CFGR_PLLMULL16);

HSI is always 8 MHz. It must be divided by 2. Then the PLL can multiply to max of 16 (would need to be 18 for the max of 72 MHz that this STM32 supports).

@jayjay23 I pushed the code to github. Can you please test it?? please limit the current on your power supply to a value like 1 amp.
What can be wrong? - the signals from hall sensors can have inverted logic. The same for the signals the control the switches for the motors phases.
Also the table on get_current_sector() can have wrong sequence. On my last project I got it by experimentation by exchanging the values on the table. Good luck :-)

[jayjay23]

@electric_vehicle_lover

I tried yesterday, it compiles, but I only shortly ran it, but it does nothing, I slowly rotated the wheel (to change hall sensors), consumption was only that of the board, so I didn't had time to debug into it.

[electric_vehicle_lover]

Thanks. If there is no forces on the motor neither current comsuption, I guess the signals for the pins are not working... maybe there is missing some configuration for the pins.

We can also use the working interrupt to call comutate() and do not use the hall sensors signal. The motor should rotate.

[electric_vehicle_lover]

Anyone knows the number of poles our motors have? any guess? -- this value is important to know how many commutations we have for 1 rotation and then calc the speed. Right now, I would try to do 1/10 of rotation per second, using a fixed timer.

[jayjay23]

If we debug the hall sensor signal this should be easy to count in the code, then show the counter of one sensor and rotate the wheel exactly one rotation. The same way we could output the correct commutation table.

[electric_vehicle_lover]

4 minutes ago, jayjay23 said:

If we debug the hall sensor signal this should be easy to count in the code, then show the counter of one sensor and rotate the wheel exactly one rotation. The same way we could output the correct commutation table.

Yes, good idea.

And since you have a motor that is not assembled on the unicycle, do you think you could open it and count the coils/poles, taking also some pictures?

Here is some good information from a website of electric bicycles: https://www.electricbike.com/motor-tech-learn-the-terms-part-1/

Edited December 2, 2015 by electric_vehicle_lover

[Restless]

Nice ideas and input guys U guys rockn'it

 

I cant wait to get my ST-Link adapter ... I think i could start with reading the signals from the MPU6050.

Looks like it takes a couple days for the Boards to get to you @electric_vehicle_lover sry for that :/

[OliverH]

Yesterday I collected my JTAG adapter and the boards. Power supply will come next week. Than I need to read this thread from the start again

[jayjay23]

Opening it is not so easy though, as the ball bearing is pressed onto the axle and into the black shell:

If I counted right, there are 51 coils and 46 magnets.

Edited December 5, 2015 by jayjay23

[jayjay23]

On 12/2/2015, 9:49:16, Restless said:

I think i could start with reading the signals from the MPU6050.

What I did here already a month ago, is taking the lib from the Indian guy (which is not DMA capable) and joined it with a blog entry from a Chinese guy (don't have all the URLs right now) who gave snippets that add support for DMA to this lib. I also added a generic IMU interface that we can use to plug other IMUs behind, and added some code for the raw data conversion and the filters (kalman and complementary2) from another blog. This code is not tested but compilable and there is some very last steps missing, like passing a suitable timer tick value to the filters and adding a delay function to the initialisation routine.

If you want I can check that in but not integrate it into main, so you can have a look.

[Restless]

2 hours ago, jayjay23 said:

What I did here already a month ago, is taking the lib from the Indian guy (which is not DMA capable) and joined it with a blog entry from a Chinese guy (don't have all the URLs right now) who gave snippets that add support for DMA to this lib. I also added a generic IMU interface that we can use to plug other IMUs behind, and added some code for the raw data conversion and the filters (kalman and complementary2) from another blog. This code is not tested but compilable and there is some very last steps missing, like passing a suitable timer tick value to the filters and adding a delay function to the initialisation routine.

If you want I can check that in but not integrate it into main, so you can have a look.

That would be nice

 

Today i had some time, opened my TG-T3 and ough ...

 

Hot glue everywhere. Took me half an hour to clean it up.

 

I removed the Soldered connection wires from the Dev Boards and added Pin-Header so i could use my original plugs from the TG.

That worked out quiete well.

A side note here: The Labels on the Dev Boards are not 100% correct. It says 2x 5V for the LED Plug and the HallSensor Labels are also wrong, its starts with GND.

 

 

After i finished everything i calibrated the Board, that actually was ok.

Then i tried to fire it up in normal mode. That did not work good...

 

If i turn it on: it beeps, then the motor starts to spin. There is some fucking tourqe  and shuts down with. beep beep beep beep

If i hold it up, it spins up to max AMP from my power supply and shuts down with. beep beep beep beep

 

Any suggestions? It is not that important since it will get our firmware soon, but im curious.

[jayjay23]

    5 hours ago, Restless said:

    That would be nice

 

Just checked that in, the code is completely untested though, it just compiles, so if if anybody sees something strange it's maybe just a error to be fixed :-)

    5 hours ago, Restless said:

    There is some fucking tourqe

 

You mean it's accelerates too much? Then it's either not calibrated (uncalibrated I just had accelerations until it starts beeping, either due to max speed, or just due to max. tilt angle reached) or it's just difficult to keep the board balanced, do you have the board screwed into the wheel? If not, I had the board calibrated standing on the table and even from that position I was not able to gently accelerate, it was always too fast, so my experience with cheap boards firmware is that they have just a very very hard setup, which means they try to keep upright with every small tilt they detect, so the pedals feel hard. Those wheels if lifted off the ground are very very difficult to not accelerate to the max. A softer wheel in oposite can be lifted off the ground and keep it not rotating much, quite easy.

So maybe that's just this?

    5 hours ago, Restless said:

    The Labels on the Dev Boards are not 100% correct

 

 

You are right, I read this and thought I will ignore it straight away :-)

 

 

Btw, why is the forum logging me out all the time recently?

[electric_vehicle_lover]

@jayjay23 many thanks for the photos. I hope to use them on the documentation wiki page about the Generics :-)

I counted the same numbers as you. I don't know much more but I found a web page that seems to document some way to have slow rotation motors and I guess it our case:

http://www.avdweb.nl/solar-bike/hub-motor/permanent-magnet-dc-hub-motor-tuning.html#h11-electromagnetic-gearing

[Mystamo]

Hey All,

First post here after reading this entire 9 pager.

I've recently gotten myself one of these Chinese clone Unicycles. A week later I purchased a 30km/h motor and controller combo from FMW (Waiting for it to come)

I have a background in Mechatronics and this project interests me. Would love to help out where I can. My strength is more on the hardware side of things but I can look through some code and help debugging etc. One of the things I'm good at is reverse engineering the board. 

One question that did pop up earlier... Maybe after the software is a bit more developed we can build custom controller hardware that has components that are consistent and generic so that we can provide the source of schematics and BOM to build them without the need to deal with Chinese suppliers. Just a thought.

Anyways. My knowledge comes mostly from modding E-Bike controllers for 100amp+ 144v operation on endless-shphere. I can also help out with the major issue that still exists with the batter packs and BMS. New well ballanced Li-Po cells can be modded to charge and work much better then chinese packs that just shut off :0

Thanks for what you guys have done so much. It's great progress.

 

 

Mo

[electric_vehicle_lover]

Hi Mo.

Thank you for the interest on this project. Great to see other interested user and that also comes from electric bicycles and endless-sphere forum/community.

About help and on hardware, sources for an initial schematic of our generic EU are here: https://github.com/generic-electric-unicycle/electronics <--- done using KiCAD.

For us to advance on coding, we need to know information about the circuit that we don't know yet:

- (THE MOST IMPORTANT) circuit for current sensing: we need to know how is the signal that represents the current

- circuit for sensing battery voltage: we need to know how is the signal that represents the battery voltage

- circuit for mosfet: we need to know if the signals are inverted logic (the some for the all sensors)

 

 

[Mystamo]

Hi thanks for the response.
 

8 minutes ago, electric_vehicle_lover said:

- (THE MOST IMPORTANT) circuit for current sensing: we need to know how is the signal that represents the current

This is usually done using the main current going into the N-Channel FET 3 phase bridge. This is how it's typically done on all sensored e-bike controllers. I don't think these controllers are very different from them at all. I think they are even using the same layout and design for the push-pull FET gate drivers and FET layouts all N-FET.

Some more advanced controllers that rely on Back EMF to commutate the motor in a sensor less typology measure phase current on 2 phases and typically Kirchhoffs law is used to calculate the current from the third phase.  I don't think this is the case in these controllers.

The resistance in the shunts used to measure current is usually really low  1-4mOhm so the voltage drop which is measured as current in the circuit needs to be amplified. This is where the Op-Amp typically seen on these controllers is used for. Usually 10-20x.  Some ebikers increase the current outputs to their motor controllers by simply adding a resistor in parallel with the shunt current measurement resistor. This lowered the total resistance in the shunt and thus reduced the voltage drop measured by the op-amp and finally sent to the micro. The micro thought it was supplying less current then it actually was.

When I get home from work today I'll open up my unicycle and have a better look at the controller and probe around a bit.

 

12 minutes ago, electric_vehicle_lover said:

circuit for sensing battery voltage: we need to know how is the signal that represents the battery voltage

This circuit is very simple on ebike controllers usually attributed to R12 on those controllers. Might even be the same on these.

A voltage divider just reduces the voltage to fit the microcontrollers A2D limits. 0-3.3v on ST?  You can see the divider usually close to the power wire connectors closer to the +ve end.

15 minutes ago, electric_vehicle_lover said:

- circuit for mosfet: we need to know if the signals are inverted logic (the some for the all sensors)

The mosfets are controller by a PNP NPN push pull transistor gate driver. When driven high they drive high the gate on the FET. (Non Inverted) This holds true on ebike controllers. Let me scope a couple of pins when I open up the cycle and I'll confirm. The one thing I am sure of is that they are the same for all 3 of the drivers.

These controllers are typically run in Bi-Polar PWM running complementary outputs to the transistor gate drives. This way the motor can run in all four motor function quadrands. Forward, Forward Brake, Reverse, Reverse Brake.

 

Hope this info helps an inch. I'll report back with some more concrete data.

 

Regards,

 

Mo

 

[electric_vehicle_lover]

Please tell me your username on github so I can add you write access.

Would be great if you could write the information on the schematic and on wiki (the information here is great but will be lost over the time).

This controllers also have BEMF circuit (and hall sensors) but we don't know how that works yet. Do you have an oscilloscope?

Yes, ST is 3V3.

Maybe you can update this wiki page: https://github.com/generic-electric-unicycle/documentation/wiki/Generic_Controller

I don't know yet what means "all four motor function quadrands" nor how the brake works... I really hope to learn a lot more on this project ;-) :-)

[Mystamo]

Hey,

 

User name on git is "mystamo"

 

5 minutes ago, electric_vehicle_lover said:

This controllers also have BEMF circuit (and hall sensors) but we don't know how that works yet. Do you have an oscilloscope?

If the controller does have a BEMF circuit I doubt it's using the feedback to spin the motor. This controller certainly seems to be running in sensed configuration. This provides smooth commutation at low speeds. 

I do have a 100mhz digital scope 2ch scope. A 4 ch would be really useful :S

8 minutes ago, electric_vehicle_lover said:

Maybe you can update this wiki page: https://github.com/generic-electric-unicycle/documentation/wiki/Generic_Controller

Maybe I can help out with this.

 

 

Regards,

 

Mo

[electric_vehicle_lover]

I added you to github.

Great that you have an oscilloscope :-) -- I also have one but I do not have yet a board to explore.
I hope you can find many info using the oscilloscope.

About sensed configuration, can you please share any link with information so we can learn about it?

[Mystamo]

This link below has lots of info regarding dead time in triggering the FETS in an all N-Type 3 phase driver as well as a great explanation of the different ways to run the motor. Bipolar Uni polar, Complementary, Independent.

https://hackaday.io/project/3176-gator-quad/log/11741-pwm-control-and-dead-time-insertion

Also, this link of a ST32 operated brushless controller. This is operating the same as the ebike and unicycle controllers.

http://vedder.se/2014/01/a-custom-bldc-motor-controller/

Regards,

Mo

[Mystamo]

Attached is a Schematic of the typical e-bike controller. The power section is the exact same as the Unicycle controllers you see. You can see on the FET power section the shunt I was talking about earlier. In this schematic it is 5mohm.

 

Regards,

 

Mo

China-BLDC-motor-controller-36V-250W.pdf

[Mystamo]

Hey all, 

managed to take my controller out of my unicycle today and take some pictures. Same ST32 as others. Pretty small and light controller. 

I also took some pictures of some bare ebike controllers that I put together with my own components. Exact same gate driver setup. Even down to the component selections. 

Will probe around a bit to see what i can find. 

Regards, 

Mo

[electric_vehicle_lover]

@Mystamo I know very well the KU63 controller for electric bicycles :-) -- the history seems to repeat on this project: a cheap simple chinese controller for cheap electric bicycles. I see the controllers of our cheap chinese generic EU just like KU63 + the IMU ic. But there are BIG key differences:

• EUC have a big cool factor (unlike electric bicycles) - for instance, I can see kids adopt EUC to go to school etc but I don't see them doing with electric bicycles
• we can't program the microcontroller of KU63 because it is unknown but we can program the STM32 from generic EUC - there are a LOT of OpenSource projects using STM32 even for BLDC motor control :-)

I tried to make an OpenSource electric bicycle controller and I used KU63 for a first prototype. Later I did my circuit using kind expensive components and STM32F10x. I shared my code on github and on a message on endless-sphere forum - but I lost my wiki were I documented the project. I stopped with the project because I could not see someone build and sell the hardware in big numbers. But I think generic EUC will always be the cheaper that we can find on Ebay and such. Who knows if in future our firmware can be used by chinese manufactures and DIY users?? :-)

As for hardware, I would pay for a DIY board that have advanced features like the comercial boards already have, like higher speed, LEDs, bluetooth, etc. Would be great to upgrade our generics.

 

[electric_vehicle_lover]

I updated the wiki pages:

- main page
- the page "Generic Electric Unicycles"
- created Motor page and included the pictures and information that @jayjay23 shared.

https://github.com/generic-electric-unicycle/documentation/wiki

---

We have now 5 suggestions on the issue tracker: https://github.com/generic-electric-unicycle/firmware/issues

---

Finally I got a notification and I should get the boards tomorrow morning :-)

Edited December 8, 2015 by electric_vehicle_lover

[esaj]

23 hours ago, Mystamo said:

Attached is a Schematic of the typical e-bike controller. The power section is the exact same as the Unicycle controllers you see. You can see on the FET power section the shunt I was talking about earlier. In this schematic it is 5mohm.

Regards,

Mo

China-BLDC-motor-controller-36V-250W.pdf

Thanks for the schematic! I have a couple of (stupid) questions though, if you don't mind...

How does the high-side gate driving work, I tested the circuit in LTSpice, and got around 45V at the gate, but I'm not sure I understand how it works. Is it some kind of charge pump/voltage multiplier?

What are the 10k resistors (R29-R31) in parallel with the low-side mosfets for? My guess was something like preventing the "open" phase from floating, but could be very wrong