#$%@$#@ <--- (insert favorite swearword here), IT WORKS !!!!

parabellum said:
Lebowski, how is your throttle working in given case? Changing multiplication factor to BEMF and then chip modifies PWM accordingly?

That is what I use currently, though the multiplication factor is fixed and I use my lab supply.
I want to go to (motor phase) current control though as close control / monitoring of the currents will prevent
the killing of FET's and will make the system more user friendly (torgue is proportional to current).

I've seen Luke's videos :mrgreen:
 
As long as you have a really elegant way to control phase current during fault conditions then some sort of recovery is fine. It would really suck to have a front wheel mounted hub motor lock up hard at full speed!!! Maybe even a fallback to sensorless trapezoidal control if lock is lost?
 
Alan, I don't see how you can build a sensorless control loop to track a constantly rising phase without at least a 2nd order loop ?

CNC: this is why I put the 'lost lock' detector in, I configured it such that it turns all the FETs off when this happens. I don't like
flying over the handlebars either :? the cool thing would be to recover lock again in a sensorless way and preferably so fast
the user doesn't even notice. I could use the halls (there for startup from standstill anyway) but that feels like cheating
 
if the FET's are off it would be possible measure the BEMF and then activate the sensorless algorithm again after rotor position is known. Since the BEMF waveform is already stored, it shouldn't take but a few samples of the BEMF to find rotor position. I imagine the only time this would need to happen is under some sort of rather abnormal occurance such as a loose phase wire or some other problem. Having a super fancy motor drive isn't much good if it's continuously faulting out, just ask luke :twisted:
 
I would use two loops and combine the outputs, or one loop with logic to combine the inputs. Maybe a little fuzzy logic. I haven't looked closely enough to have a detailed suggestion. Take a step back and look at all the available information. The goal is to determine the commutation points reliably and accurately using all available information in an integrated fashion.

Cutting out when accelerating to get out of the way of an oncoming <whatever> is just not an option. Control Systems need to do the best they can even if it means less optimal.

We found when making controls at a few nanometers level that some cleverness beyond control theory is required.

Great progress by the way.
 
The control loop at the moment is a bang-bang loop. It's second order with a bandwidth of around 100 Hz and a sample
rate of 4 kHz (which will be increased to 50 to 100 kHz later, the slow 4 kHz gives me the possibility to output a 16 bit measurement
value over 115 kbaud RS232). The algorithm gets positioning information every clock cycle (so 50000 to 100000 times a second)
but has to take into account the slow motor parameters (to explain the relatively low 100Hz bandwidth). (The 'delay' of a motor
is L/R, I don't know these values so took a conservative long delay value)
Anyway, to loose lock you would need to slow down the motor to half its speed in a few 0.001 of a second. Based on the
typical inertia of a fast-spinning motor, this is just not going to happen. Because of the 50 to 100 kHz clock rate the algorithm
is going to know something is up long before it actually happens :D . The setup has actually never lost lock during
normal running, only when I did stupid stuff like accidentally shorting a PWM output signal when I tried to measure it
with my scope. This was quite a violent event but not the fault of the loop.
 
Lebo here are some motor constants if you are wondering where they might be. The motor indicated as Axial is a floor scrubber motor from Mars Electric now Motenergy.

 
The controller is progressing nicely :D I only need to add a throttle and some calibration
menu's and it's ready for a powertest on the bike.

The way I got it setup now, the algorithm is clocked at 40 kHz but about double this speed
is possible though doesn't make sense (as my output stage only runs good up to 20 kHz, after
that the drivers cannot handle the large output transistors anymore.... killed off a whole
regiment of 33N10's this weekend due to slow turn on/off gate signals :oops: ). While the motor
is running you can send a 1-character command (over RS232) to the PIC which will then respond
by sending an internal variable back at a rate of 5000 samples per second so you can real-time
monitor things like e-phase, output voltage amplitude, motor current, the signal used to determine
the motor phase (during sensorless) etc etc.

The thing is very cool now, during fast acceleration of the motor, instead of a cogging type
noise (which you get with a simple china controller) it makes a very soft turbine / jet engine
type noise :mrgreen: like a plane spinning up. Once on speed you just hear the bearings and
air 'whoosing'.
 
Lebo,
whoosing is what you do the night after a piss up. A jet goes "whooooosH!
I will be very happy if I can get my 3KW scoot to go whoosing or whoshing instead of cogging. :lol: :mrgreen:
 
Am thinking about the throttle interface now... I know just connecting an analog throttle is quite
easy but this is also very limiting. Therefore I'm thinking about adding a small 8 pins PIC (with internal ADC)
to connect the throttle to. This smal PIC will then transmit the digital value over SPI to the main
motor controller PIC.

There's 3 reasons for this. One is that I'm planning to run 2 motor controllers on my bike as my
motor is actually 2 motors in parallel on the same axle. Kind of similar to running
2 hubmotors, then you also need 2 controllers. Having the throttle as a digital signal enables easy
transmission (via optocouplers) to the 2 motor controllers. These can then be totally isolated from
each other and even run on seperate battery packs. Second reason is that, here in Switzerland an
e-bike with throttle is legally not allowed. A digital throttle allows me to run an extra 24F type PIC
which measures road speed, maybe inclination, pedalling force etc to build a proper fully automatic
pedelec. The 24F then transmits the motor-torgue requirement to the 30F motorcontrollers.
The 3rd reason is that receiving SPI is a hardware function of the 30F, it actually doesn't cost
any 'time' to the algorithm. Reconfiguring the ADC's to read the throttle channel plus the ADC conversion
time, you're easely looking at more than 1 usec, this seems like a big waste when the main
motor algorithm takes 10 to 12 usec...

The SPI bus is a very simple 2-wire approach, one wire clock second wire data. There's no speed
dictated in the protocol so you can transmit at a very low data rate (for good noise immunity). Maybe
I'll implement a 3-to-2 error correction algorithm as the ADC's in the 8 pins devices are 10 bit...

what do you guys think ?
 
Alan B said:
Seems reasonable.

Might want to have a failsafe timing out the throttle input. Out of control motor controllers are not fun.

Is a throttle illegal, or is there just a requirement to be pedaling?

Out of control motor controllers, that would be, eh, interesing :oops: especially when
you need to explain this to the police :D

AFAIK throttle is illegal and you must be pedaling for the motor to work. The motor is not
allowed to power the bike on it's own though the law is being changed now to allow
this upto 5 kmh (so you can walk next to the bike up a steep hill without having to
push it). So maybe then throttle is allowed upto 5kmh, but at the moment no.
 
This is a short clip to demonstrate the sound of a trapezoidal exitation.
Before I press the button the motor controllers output is full sinewave to
maximum possible amplitude.
Pressing the button doubles the amplitude and introduces clipping. The sound of
the motor changes dramatically when this happens.
The laptop screen is showing the real-time phase of the motor. you can see it
starts out as a staircase of 6 discrete values, the motor is running on the halls.
After a few seconds it 'morphs' into a sawtooth form, the motor is now running sensorless
and the phase value is no longer bound to 6 discrete values.

The motor is run upto 1000 rpm, not bad for a bicycle axle :D

[youtube]NagzM58h2rE[/youtube]
 
Lebowski said:
dual core :mrgreen:

press a button and the corresponding light goes on: test of CAN bus communication :shock:



You are an amazing inspiration Lebowski!! Keep up the awesome work!
 
Lebowski said:
The thing is very cool now, during fast acceleration of the motor, instead of a cogging type
noise (which you get with a simple china controller) it makes a very soft turbine / jet engine
type noise :mrgreen: like a plane spinning up. Once on speed you just hear the bearings and
air 'whoosing'.
Though I can only follow the general concepts of what you're doing, this is very exciting nonetheless... 8)

I have a geared MAC hub motor & some Hyperion RC motors. Do you need some sample motors to test your controller design on? :idea:

Just wondering what you want to do for the next test phase :?: Are you intending to offer this as a kit or product or for ES members :?: :mrgreen:

Wishing you great success with this project... 8)
 
Accountant is also offering to send you xie chang board to implement your chip inside ... Small help from Croatia.... with greetings from Tesla :)
If thats possible, you have the market for buying your chip ...
 
Lebo, I hope that you can test your new algorithm controller under load soon. I have seen "many" things change in back emf and emi/rfi when under load. It would be good to have this test to know the algorithm and filters can still pick out what it needs to when there are kiloAmps being slung around.

Perhaps you have already done this test however.
 
Great work! Certainly the next level compared to the typical chinese controller. It seems possible in theory to make a really significant improvement over the norm by using more sophisticated software. I think the hardware cost won't be increased too much, so has the potential of being "affordable", unlike many of the high end controllers with these features.
 
deVries said:
I have a geared MAC hub motor & some Hyperion RC motors. Do you need some sample motors to test your controller design on? :idea:

Just wondering what you want to do for the next test phase :?: Are you intending to offer this as a kit or product or for ES members :?: :mrgreen:

Well, it would be very nice indeed to try the system out on all kinds of motors. I imagine
that if you're handy with the soldering iron I can send you a schematic and a programmed IC.
It's not an expensive system and it would be possible to take a typical Xie Controller and
do a conversion. I once saw a schematic of a EB206 (?), if they're all build like this then
a conversion should be no problem.

What I have consists of a 30F4011 MCU/DSP. The input signals it needs are the 3 hall sensors (for sensored
start-up) and 2 current sensors to measure the motors phase currents (it is meant for the Allegro current
sensors). The outputs are 6 PWM signals which switch the high/low side FET transistors.

To come back to the EB206 schematic I saw, this is setup in a similar way (3 hall sensors to
a u-controller which then supplies signals to the 6 FET drivers). All it would need is a check to
make sure the 5V supply can deliver the 200 mA the 30F needs and then you just take out the
Infineon chip and substite wire in the 30F. Add 2 current sensors and that's it. For a throttle
anything that gives out 0 to 5 V can be used. The hardware side of my controller is nothing special.

The cost should not be high. A 30F4011 cost around $5 to $10 here in Switzerland, a current
sensor costs $2 to $20 dependent on how crazy large you want the current to be.

There will be some pins on the 30F that can bring the chip in certain modes. It has a ascii (RS232)
menu driven system for what I call 'calibration'. During calibration it will ask you a few times to
spin the motor, the 30F will then learn the relationship between all the hall signals and the motor
phases. This takes away all the guessing of which hall/phase combinations to use, the 30F will
'learn' this during calibration. Hall and motor phase signals can be outputted in table format for
copy-paste in a spreadsheet program, in this way you can look at the signals. It has a menu for chosing
the PWM frequency and dead-time to be flexible enough to use a low-cost output stage (EB206) or a
faster more advanced optical output stage (as I use). The parameters of the sensorless and throttle
(current) control loop can be chosen, as well as how fast the control loop executes (upto
around 80 kHz, so 80000 measurements and phase/amplitude updates a second). The motors resistance
and inductance do not need to be known. After you've gone through the setup everthing can
be saved to the 30F 's internal EEPROM . Calibration is a one-time deal, except of course for when you want
to play around and try all kinds of stuff. The RS232 interface can be used during motor operation to
real-time observe internal variables like motor current, e-phase etc etc (like in the video I posted earlier).

Throttle wise, I will put in a calibration for this, it will ask you to close and fully open the throttle
and measure the associated voltages. Still thinking about putting in a choise between linear/logarithmic
throttle curves. Or you can use the CAN bus for this, good for connecting multiple motor controllers
in parallel for when you have a motor in each wheel or a double stator motor. It's a current based throttle,
this means that you control the torque the motor delivers (much like with a petrol engine).

Basically I have everything except for the throttle interface (working on this now) and I still need to
add some 'fluff', some more menus for the calibration phase and things like this.

I've only tried it with my motor so it would be fun to try on others :D I hope that during the upcoming
Christmas week I'll get the throttle done so I can start with some tests under load. 'Under load' is relative by
the way, I only have a 150 Watt power supply so I cannot try it out with dozens of amps. But everything is
relative, I mean, the algorithm doesn't care whether you have a 10 Amp or 200 Amp current sensor installed
or whether you use 6 or 30 FETs, or if your battery is 36 or 150 Volt. The 30F is sitting nicely in it's 5V world, so...

If you want to try it out, PM me :D
 
markobetti said:
Accountant is also offering to send you xie chang board to implement your chip inside ... Small help from Croatia.... with greetings from Tesla :)
If thats possible, you have the market for buying your chip ...

Is there a member named 'Accountant' or is the accountant of your company ? Tesla ?
 
Back
Top