bobc wrote:Good idea Jeremy, I'll do a little exploration (so far as I can without killing it). I would (however) have thought it's easy & cheap enough to get a shunt on the DC- connection - the peak I there would be = phase current (a brushless drive is open circuit on one phase) so I kinda assumed they would use that for current control ('cos it's what I'd do...). I'm going to get me an ATmega BLDC control demo board & learn the job properly :^)
I know if you read up on brushless drive control they always go on about closing the speed loop (with a PID) - for our purposes we don't want to close the speed loop, we want direct control of the torque (& therefore the current). Such a control scheme would work fine for props as well, (though you might want to compensate for the speed squared non-linearity) - you'd end up with a drive that looked after itself and was nearly universally applicable (& my bargain bucket ESC actually gave a damn good impression of it!). I can't believe i've just been outrageously lucky - that doesn't happen to me......
The ebike controllers all, without exception, measure supply current and use that to limit phase current, usually using some sort of algorithm that estimates the motor LR time constant and uses that to predict phase current from average supply current plus rpm plus throttle demand. Most uControllers that are used in off-the-shelf BLDC controllers don't have fast enough A/D converters to measure the phase current peaks on the supply side shunt, so they use a combination of averaging supply current to control phase current (as mentioned above, taking account of pulse width and likely motor LR) plus, in the case of the XieChang controllers a simple peak detector that detects fast spikes of current and interrupts the controller to shut it down.
There are a few threads here that are worth a read. First off, here's a thread that describes the way we collectively discovered the secondary peak current shut-down function on the XieChang: viewtopic.php?f=2&t=16910&p=247194&hilit=solved#p247194
that gives an insight into the way that the Chinese designers coped with the phase current limiting problem for a low LR motor.
Next, Ricky has been putting together a very slick controller that does have fast enough A/D converters to measure and control phase current directly: viewtopic.php?f=2&t=23205
and his thread is very well worth a read for an insight into high-end controller design.
Finally, I've had a go and built a simple controller that controls phase current spikes with pulse-by-pulse current limiting, using an off-the-shelf BLDC controller chip: viewtopic.php?f=2&t=23350
and one or two others are taking this design and looking at replacing the hardware control chip I'm using with a uController, like this one: viewtopic.php?f=2&t=24519
There are a few other threads around where there's been a lot of theorising about ideal controllers and ways of adding additional features, but I'm not sure that any real-world controllers have yet emerged from these debates yet.
There are also several discussions here on throttle control algorithms, plus a couple of attempts to implement power control. All the ebike and RC controllers that I know of use open-loop speed control, with the throttle directly controlling the PWM duty cycle, with some intervention from the current limit circuit when required. Torque control is challenging, because it demands motor phase current measurement. Ricky can do it with his slick controller, but those of us using supply current monitoring will have to make do with power, rather than torque, control. This still requires a PID loop, as the process is to use the measured supply current and use it as a feedback signal to a loop driven by a power demand signal from the throttle. The loop output would directly control PWM duty cycle to get the motor to deliver the demanded power. I'm working on adding it to my controller, as I'm convinced that a power, rather than speed, throttle will feel more natural. Getting a fast enough PID loop in a uController is non-trivial though, as I've already discovered. It needs a fairly fast uController, running some efficient code, to get the response down to the few tens of mS needed for good throttle feel.
Please ask questions on the forum, rather than by PM, as it helps others and you'll get a better range of answers.