Firmware

[Tomek]

I have access to a super large 3d printer, will try to print (almost) a whole case in one piece from ABS sometime early 2016. ... but this discussion doesn't really fit here, shall we start a new thread for open source cases? I'll be more than happy to share my 3d models. I use rhino 3d for this kind of stuff, anyone else using rhino?

[electric_vehicle_lover]

@Tomek Good idea to create a separated thread.

Would be great if you want to share your sources and STL files on github - please tell me your github name so I can add you in the case you are interested.

[electric_vehicle_lover]

@Tomek I created the https://github.com/generic-electric-unicycle/hardware and added you.

[electric_vehicle_lover]

I pushed the code that runs the motor using PWM complementary unipolar mode. It seems to run the motor with the same noise, I can't say if is better or worse.
Maybe later I can try to switch to the BEMF signals after some speed like 6km/h and try see if the motor runs more smooth.
I also measured with duty_cycle = 50%, the motor runs at 13km/h.

I want also to make velocity ramp and brake/regen ramp.

[lizardmech]

Can you run the ST motor control software on the board? From what I understand they have a ready to go BLDC library and you just tell it your motor specs and it autodetects the details it can and then spits out some code ready to use.

[electric_vehicle_lover]

I am following the various documents ST and others provide for BLDC motor control. I think that such library will not work and probably damage the board because this one is very specific and I don't have the technical information (nor knowledge) to pass to such application. Also I want to learn. I must say that it is taking much more time that what I expected but at the same time I am learning a lot. Also I am not alone :-)

[robca]

Driving brushless motors efficiently is pretty hard, and different motor typologies need different signals.  I know that there are existing implementations, but none for the exact types of motors used in EUC. Methinks that it would help this project to have someone with a good multi-channel DSO capture the different signals a commercial EUC uses to drive each phase of the motors. Just looking at the signals shouldn't create any problem with the open source state (unlike copying someone else's firmware, say), and would give the team a starting point for the necessary signals (in all cases: acceleration, steady state, balancing, regen braking).

Looking at this project from the outside, if I were working on it, my main concern would be to efficiently drive the motor. Everything else is, relatively speaking, straightforward. Driving the motor with high currents without damaging anything, that's hard. Once you can duplicate the motor drive signals, future improvements are easier.

Just my 2 cents from an outside observer (really interesting project, btw)

[lizardmech]

1 hour ago, robca said:

Driving brushless motors efficiently is pretty hard, and different motor typologies need different signals.  I know that there are existing implementations, but none for the exact types of motors used in EUC. Methinks that it would help this project to have someone with a good multi-channel DSO capture the different signals a commercial EUC uses to drive each phase of the motors. Just looking at the signals shouldn't create any problem with the open source state (unlike copying someone else's firmware, say), and would give the team a starting point for the necessary signals (in all cases: acceleration, steady state, balancing, regen braking).

Looking at this project from the outside, if I were working on it, my main concern would be to efficiently drive the motor. Everything else is, relatively speaking, straightforward. Driving the motor with high currents without damaging anything, that's hard. Once you can duplicate the motor drive signals, future improvements are easier.

Just my 2 cents from an outside observer (really interesting project, btw)

There's a fully featured open source BLDC driver with detailed motor control configuration software available. The only issue is it's STM32F4 based and 2 or 3 components are limited to 60v and would need to be replaced. From what I understand you need the F4s FPU for advanced motor configuration. But I haven't been able to get any information on the balance mechanisms. Do they need to be tightly integrated with the motor control or could you just send commands to the motor driver and have a separate MCU + gyro board connected via canbus?

Separating the gyro + and balance side from the motor drive also opens up some interesting options like using TI instaspin hardware to drive motors.

[electric_vehicle_lover]

1 hour ago, robca said:

Driving brushless motors efficiently is pretty hard, and different motor typologies need different signals.  I know that there are existing implementations, but none for the exact types of motors used in EUC. Methinks that it would help this project to have someone with a good multi-channel DSO capture the different signals a commercial EUC uses to drive each phase of the motors. Just looking at the signals shouldn't create any problem with the open source state (unlike copying someone else's firmware, say), and would give the team a starting point for the necessary signals (in all cases: acceleration, steady state, balancing, regen braking).

Looking at this project from the outside, if I were working on it, my main concern would be to efficiently drive the motor. Everything else is, relatively speaking, straightforward. Driving the motor with high currents without damaging anything, that's hard. Once you can duplicate the motor drive signals, future improvements are easier.

Just my 2 cents from an outside observer (really interesting project, btw)

Thanks @robca!
Yes, I am find very difficult to "understand" the motor and be able to correctly drive it including the circuit or it will just burn.
I think I will focus more on having a robust motor code and good interface so others can program safely.
At least, right now we have pictures of the motor internals that may help to understand it: https://github.com/generic-electric-unicycle/documentation/wiki/Motor

[electric_vehicle_lover]

Found a wikipedia page about EUCs and decided to add our project to the page: https://en.wikipedia.org/wiki/Self-balancing_unicycle

[lizardmech]

1 hour ago, electric_vehicle_lover said:

Thanks @robca!
Yes, I am find very difficult to "understand" the motor and be able to correctly drive it including the circuit or it will just burn.
I think I will focus more on having a robust motor code and good interface so others can program safely.
At least, right now we have pictures of the motor internals that may help to understand it: https://github.com/generic-electric-unicycle/documentation/wiki/Motor

The problem is many of the motors are slightly different. If we had self balancing code ready we could use more powerful dev boards to analyze each model of motor and generate motor control code. Then you could possibly port the code back to the stm32F1 by hand. Depending on how complicated the motor tuning process is doing it well by hand might be near impossible. If I had to guess the manufacturers probably hook up the motors to a pc or more powerful STM dev boards, run configuration programs then flash the code onto the STM32F1 chips.

[electric_vehicle_lover]

I corrected the ADC code using DMA. Now I have a potentiometer on PS_signal pin that controls the duty-cycle of the motor. Max potentiometer is about 40% duty-cycle. Please see how the motor works on this video I recorded:

 

Here is a picture of BEMF signal at STM32 pin (yellow) and the hall sensor signal, at a low speed:

1 hour ago, lizardmech said:

The problem is many of the motors are slightly different. If we had self balancing code ready we could use more powerful dev boards to analyze each model of motor and generate motor control code. Then you could possibly port the code back to the stm32F1 by hand. Depending on how complicated the motor tuning process is doing it well by hand might be near impossible. If I had to guess the manufacturers probably hook up the motors to a pc or more powerful STM dev boards, run configuration programs then flash the code onto the STM32F1 chips.

Ok but I am not going on that direction for now.

NewFile13.bmp

[electric_vehicle_lover]

I were looking at the signals on original controller and seems that there is 2 ways to control the motor, at kind of low speed and higher speed. I put many screenshots of oscilloscope on the wiki here: https://github.com/generic-electric-unicycle/documentation/wiki/Controllers

I still can't understand how it works... the relation with the hall sensor signals. Also the 3 phases seem to have the signals in phase so I don't know how current can flow... also can't understand why 50% duty-cycle is stopped wheel and higher or lower to invert the rotation...

Please look at the information and help: https://github.com/generic-electric-unicycle/documentation/wiki/Controllers

[OliverH]

2 hours ago, electric_vehicle_lover said:

I were looking at the signals on original controller and seems that there is 2 ways to control the motor, at kind of low speed and higher speed. I put many screenshots of oscilloscope on the wiki here: https://github.com/generic-electric-unicycle/documentation/wiki/Controllers

I still can't understand how it works... the relation with the hall sensor signals. Also the 3 phases seem to have the signals in phase so I don't know how current can flow... also can't understand why 50% duty-cycle is stopped wheel and higher or lower to invert the rotation...

Please look at the information and help: https://github.com/generic-electric-unicycle/documentation/wiki/Controllers

Sensor and sensor less operation?

[electric_vehicle_lover]

I don't think so because the hall sensors are there and working from the start. And the first mode of working is for low and maybe up to medium velocity where the hall sensors and aslo BEMF circuit works.

[vezu4iy]

Motherboard does not see the Hall sensors , so it works as a punch.

[electric_vehicle_lover]

@Алексей, I think you mean the start of the motor. And I don't think that is the case because motor runs up kind of medium speed and here is an example:

On that picture, yellow is a phase and blue a hall sensor. And zooming the the phase signals, on this case 2 phases:

Yellow and blue are 2 phases. Here the motor were rotating at a medium speed and at this speed the hall sensors signals are good.

Please see more here: https://github.com/generic-electric-unicycle/documentation/wiki/Controllers

[vezu4iy]

The motor have 3 phases. You used only 2. You have to make picture of all phases and Hall sensors. 

Recently my motor to vibrate due to the problems of one of the phases. At high speed motherboard did not see the signal of one of the Hall sensors and vibrating like a hammer under his feet .

Phase  have Switching correctly.

Edited January 1, 2016 by vezu4iy

[electric_vehicle_lover]

My oscilloscope have only 2 channels and I switched to see the signals on the 3 phases and hall sensors. I will do it again as there is the possibility that I did not correctly the measures.

[vezu4iy]

Make some pictures: phases A and B, A and C, B and C, B and A. Use all combinations between phases and all Hall sensors. It used all sensors.

And check the resistance between the input phases of the Hall on the motherboard and the ground. Perhaps there is a drawdown  
Perhaps it is faulty .

[electric_vehicle_lover]

It's not faulty because I am measuring on a full working EUC. I ride the ECU after the measurements. I want to understand how the original controller generates the signals that controls this motor. 

[vezu4iy]

I see. 

The controller uses the signals from the Hall sensors for switching phases keys. You can create your own algorithm based on theory or disassemble the firmware.

[vezu4iy]

Do you have pictures of all phases of the original firmware ?

[electric_vehicle_lover]

I just have this pictures: https://github.com/generic-electric-unicycle/documentation/wiki/Controllers

[vezu4iy]

 

Connect the oscilloscope to the phase A and take pictures with Hall sensors A, B, C, repeat the phases B and C. After all the images compatible and sign every where what phase .