Compact Field Oriented Controller, ASI + Grin, limited run
- Thread starter justin_le
- Start date
Alan B
100 GW
Very nice!
speedmd
10 MW
WOW. Love the through axle hub. Possibility to run a crankset through the center of something like this with the right bore- bearing interfaces and could make a stellar mid drive motor in a custom frame build. Love the controller updates and the "lego" style battery building block setup. Great work.
mrbill
10 kW
justin_le said:Well it's not always an obvious call if you want [plug braking] or not. Regen is a no brainer, put energy into your battery pack and save wearing your mechanical brakes? Hell yeah. But when it comes to consuming battery energy in order to stop, versus just switching over to mechanical brakes at that point, then it's not so clear cut. Great if you want uniform and maximum stopping power via regen, less great if you are trying to maximize your range and wh/km.
Anyways had a rare break of nice weather today so I decided to do a little run on a flat straight stretch of road near here, cruising up to 40kph (where my kinetic energy 1/2m*v^2 = ~1.8 Wh) and then coming to a stop under purely regenerative brake control. I had my Phaserunner controller set to ~40A of max regen phase current, and then used the CA3's ebrake output setting to adjust this value in 8 different levels (0.7V, 0.6V 0.5V etc. to 0.0V) using the analog regen throttle mapping.
Here's the trip analysis view with all the intermediary data removed:
http://www.ebikes.ca/tools/trip-analyzer.html?trip=Jcjcxv
View attachment 2
Unfortunately we don't show enough digits of precision to use this tool for comparison of individual stops, so I used excel to do the comparison analysis and got this:
It's interesting to see how over such a wide range of regen intensity levels, the total amount of watt-hours returned to the battery remains roughly constant at ~0.8 Wh. But at the highest intensity braking, we then consume 0.129 Wh during the plug braking portion towards the end of the stop (starting at about 12 kph), so the net wh back into the pack is reduced by some 17%. Here's the same data shown graphically
This is all very interesting. I've been trying to tune out the plug braking behavior of my BAC2000 (used with a Nine Continents M3006RC DD hub motor) while at the same time obtaining maximum regen current at higher speed. I have good friction brakes, and I see no reason to consume precious battery energy under conditions that the controller is unable to return energy to the battery. Greater commanded engine braking or slower vehicle speed or both appear to give increased likelihood of drawing current from the battery to achieve braking effect.
Is there a BACDoor setting that turns off plug braking, that tells the controller to reduce braking effect as needed so that current is never positive when braking?
I've tried setting "Engine braking torque" to 0% (while leaving "Maximum braking torque" at 100%) (Peripheral Configuration --> Brakes), but that appears to have no effect on engine braking behavior. In fact, I'm not quite sure what the effect of "Engine braking torque" is, as I get the same behavior whether it is set to 100% or 0%. I've also tried setting a minimum braking speed, and that only handles the case well for one throttle setting during engine braking.
A simple checkbox in BACDoor that instructs the controller to disable plug braking or set engine braking to "regen braking only" would help.
markz
100 TW
Very interesting stuff Grin is doing, looking forward to the batteries and that motor looks cool too, the FOC is also cool.
Alan B
100 GW
Engine braking is normally a light regen level when the throttle is released, simulating engine compression. Also called slip regen. Works nicely on the Sabvoton.
The amount of power consumed by powered braking is very low, much less than the energy recovered during the regen phase of the stop. The value of eliminating it is thus very small. In my case it is on a separate control so I have the option of releasing it and using the front friction brakes. The powered braking only occurs at the very low speed portion of a stop. There is often a setting that adjusts the speed at which ebraking drops out, so by raising this setting you could avoid the power usage as well.
The amount of power consumed by powered braking is very low, much less than the energy recovered during the regen phase of the stop. The value of eliminating it is thus very small. In my case it is on a separate control so I have the option of releasing it and using the front friction brakes. The powered braking only occurs at the very low speed portion of a stop. There is often a setting that adjusts the speed at which ebraking drops out, so by raising this setting you could avoid the power usage as well.
mrbill
10 kW
Alan B said:
Hi Alan:
If that is so on the ASI controller, I can't tell. With "Engine braking torque" set to 100%, I see no reverse current at any speed below max RPM after releasing the throttle.
According to Justin's data, regenerated energy is reduced as much as 17% when maximum motor braking is commanded and applied down to 0 km/hr. Since I started using the ASI controller on my faired bike my observed regen Ah has doubled (when using a minimum motor braking speed of 10 km/hr).
For a while I had set "Regen brake speed" (minimum speed for regen brake) to 10 km/hr, and that prevented powered braking when I had commanded maximum motor braking (given my other settings at that time, e.g. motor power rating at 48 volts of 1200 watts, max phase current of 74 Amps). But, I discovered that at sub-maximal motor braking I could go slower and still get some regen braking. So, I have for now set the minimum speed to 0 km/hr and in the absence of controller support for this functionality am managing this myself as best I can until I can settle on what speed limit works best, if any.
Setting a lower speed limit is an imprecise way to achieve motor braking with negative battery current (regen braking) when one can vary the motor braking intensity through, for example, the proportional regen support offered with a CA3. One needs a specific setting on the controller that can dynamically enforce a negative battery current constraint in two dimensions: motor speed and user-commanded motor braking intensity.
Alan B
100 GW
Hi Bill,
The amount of energy you are seeking (regen energy from say 5kph to 0kph) is a tiny percentage of an already small percentage. 10 kph may be too high but zero is definitely too low. A median value will come very close to ideal. I suspect the way the FOC controllers do regen the ebraking comes for free and they don't really see it as a separate process, not like the trapezoidal controllers control regen. At some point the voltage upconverted from the motor isn't enough to reach the requested braking current, and the current flow direction changes. In the interest of safety it is probably better to cease braking at a fixed low speed than when the current reverses.
If you want every nuance of the controller to match your ideal you need a more programmable controller (such as a Sevcon), or to build one from modules or components. Today's programmable controllers and modules make that very possible. I have a TI kit here that would allow you to do that, send me a PM if you are interested. They have software library packages to do all the FOC complexity so you just add your own algorithms wrapped around theirs.
Did you solve the problem with high current flow into the batteries during regen braking? Part of the requirement for good regen energy capture in a vehicle is having a battery pack that can take high charge currents and efficiently capture them in increased charge state. Many ebike packs and BMS's are not designed to do this.
The amount of energy you are seeking (regen energy from say 5kph to 0kph) is a tiny percentage of an already small percentage. 10 kph may be too high but zero is definitely too low. A median value will come very close to ideal. I suspect the way the FOC controllers do regen the ebraking comes for free and they don't really see it as a separate process, not like the trapezoidal controllers control regen. At some point the voltage upconverted from the motor isn't enough to reach the requested braking current, and the current flow direction changes. In the interest of safety it is probably better to cease braking at a fixed low speed than when the current reverses.
If you want every nuance of the controller to match your ideal you need a more programmable controller (such as a Sevcon), or to build one from modules or components. Today's programmable controllers and modules make that very possible. I have a TI kit here that would allow you to do that, send me a PM if you are interested. They have software library packages to do all the FOC complexity so you just add your own algorithms wrapped around theirs.
Did you solve the problem with high current flow into the batteries during regen braking? Part of the requirement for good regen energy capture in a vehicle is having a battery pack that can take high charge currents and efficiently capture them in increased charge state. Many ebike packs and BMS's are not designed to do this.
mrbill
10 kW
Alan B said:
Hi Alan:
What is the safety issue connected with the intensity of the motor brake being limited by the controller sensing positive current flow? I'm doing this manually already, but I'd like to have this process automated so I can concentrate on riding the bike.
Well, that is probably true. I'd probably look for something like the Sevcon or a turn-key solution that offers a wide array of programmable features. My eyes are happier these days reading and writing code on a screen than soldering tiny circuits. But, thanks for the offer. Right now I'm enjoying the learning process to understand the features and limits of the ASI controller. My next project may be a bigger hub motor that would be happier on the steeper hills we have here in the (San Francisco) Bay Area. And, I do hope ASI offer a voltage throttle option so that I can use their controller on my mid-drive. But, if the improvements I've suggested are not forthcoming I may become interested in other solutions.
Yes.
My batteries are 14s12p Samsung INR18650-29E cells with a rated maximum charge current of 2.75A/cell. That's 33A for the battery, or about 1450-1950 watts, depending on battery voltage at the time. I have set a "motor nameplate rating" of 1500 watts so that 33A are only seen when the battery is nearly depleted. That peak current might typically be seen for a few seconds or at most a few minutes on a particularly long and steep downhill. My batteries also use a 40A "2-wire" BMS, where both charge and discharge go through the same circuit with the same 40A limit.
Alan B
100 GW
Hi Bill,
I agree that controls should not get in the way of riding the bike. Simple and predictable is best, any surprises can lead to confusion and result in an accident.
My experience so far is with the Sabvoton which is very similar, and I would not want the ebraking cutting out at varying speeds depending on the gradient, loading, etc as it would if it switched off when regen ended (and which could lead to a safety issue). For my CroBorg this is a real brake, not a regen feature. It completely replaces the rear braking system, which there is not room for on a Cromotor in a 135mm frame. It does so in a superior fashion, returning some energy to the battery, having some antiskid properties, and avoiding wearing out pads. I gladly pay the tiny energy penalty for not having to overheat the discs on big descents (which was part of my daily commute) and never have to change pads on the Borg. It is so effective that the front brakes are used just for the last tiny bit of stopping thus they are always ready for an emergency and the pads stay pretty much new. I do have to use them for a harder stop from time to time to keep the braking surfaces prepared for use, but at this rate they will last a very long time.
With all the specific features and controls you are looking for, you definitely would benefit from and enjoy something that is more fully programmable rather than just parameterized.
I agree that controls should not get in the way of riding the bike. Simple and predictable is best, any surprises can lead to confusion and result in an accident.
My experience so far is with the Sabvoton which is very similar, and I would not want the ebraking cutting out at varying speeds depending on the gradient, loading, etc as it would if it switched off when regen ended (and which could lead to a safety issue). For my CroBorg this is a real brake, not a regen feature. It completely replaces the rear braking system, which there is not room for on a Cromotor in a 135mm frame. It does so in a superior fashion, returning some energy to the battery, having some antiskid properties, and avoiding wearing out pads. I gladly pay the tiny energy penalty for not having to overheat the discs on big descents (which was part of my daily commute) and never have to change pads on the Borg. It is so effective that the front brakes are used just for the last tiny bit of stopping thus they are always ready for an emergency and the pads stay pretty much new. I do have to use them for a harder stop from time to time to keep the braking surfaces prepared for use, but at this rate they will last a very long time.
With all the specific features and controls you are looking for, you definitely would benefit from and enjoy something that is more fully programmable rather than just parameterized.
macribs
10 MW
- Joined
- Jul 22, 2014
- Messages
- 3,702
tightbox said:
Cool stuff. Very excited to see how the new controller and software are working. When it is all dialed in I think it will be a good choice for many builders.
The hubmotor with thru axle is cool for people looking to make awd or just fancy a fwd bike. Slap motor on, wire up and go riding.
those batteries are those Lipo batteries or 18650 li ion? I tried to reply that scene where justin introduces them but I can not for the life of me hear what he says. And watching the video on my cell I can not read the text on those lego batteries. Any more info on those batteries?
This thread is growing so large it is a pain to find what I was looking for. Info on the ASI BAC Cadmium 2000. Has people successfully run that controller with hi powered DD hubs? Seems it should top out at 15kw peak. How is it compared to say similar power & priced sabvaton?
Alan B
100 GW
The battery sticks are 10x 18650
FluxZoom
100 W
justin_le said:
There are plenty of controllers out there that do sinusoidal commutation without field oriented control (FOC). Any chance you might or have done a similar comparison with this non-FOC type of controller to trapezoidal and FOC? I would assume that the non-FOC type would be the least efficient, but I've wondered more than once by how much. I think this sort of idea might help others see a tangible distinction between these types of ideas.
Alan B
100 GW
FluxZoom said:
FOC is just one way to determine the rotor position. Other sinusoidal controllers must measure/estimate rotor position in some way. The accuracy of this estimate will determine how well (and how efficiently) they work.
toolbag
10 mW
- Joined
- Jun 19, 2015
- Messages
- 30
Alan B said:
FOC is not a method of rotor angle estimation; it is a method of directly controlling the magnetic field in the stator (which is proportional to the current), thus the term "Field Oriented Control". This is achieved by measuring the phase current and modulating the duty cycle of the switches to achieve the ideal current waveform (typically sinusoidal) using a PID controller or similar.
The frequency of the current waveform (proportional to motor RPM) is informed by something in the system. Often it is using an encoder, hall sensors, or a sensorless method (like a Sliding Mode Observer or by watching the BEMF).
I'm not sure what non-FOC 'sinusoidal' controllers are doing.
Alan B
100 GW
toolbag said:
You are correct, I was lumping two things together in a non precise way.
Field Oriented Control can be taken either as a general term or as a specific term for one particular methodology of doing the computations and feedback loops for motor control. Hence the confusion.
Here's one paper that differentiates Field Oriented Control (FOC) from Sinusoidal Commutation:
http://www.copleycontrols.com/Motion/pdf/Field-Oriented-Control.pdf
Non FOC controllers can use sinusoidal commutation. This is a different technique from FOC, it uses sine waves for each of the three coils, based on the estimated rotor position from an encoder. The mathematics of the control algorithms are much simpler. They use a sinusoidal commutation calculation (which can be largely a lookup table) and two feedback loops to drive the three PWM signals to control the currents in the three coils. This is very simple. I suspect this is what "Sine Wave Controllers" are doing. Anyone doing FOC is probably going to claim it, though there could be patent/licensing reasons that they avoid particular terminology.
FOC controllers do their calculations in a vector based rotating frame of reference (rotor) and use transformations (Clark and Park) to translate to the nonrotating physical frame of reference to control the coils. They do a lot of real-time math.
Sinusoidal Commutation is simpler and cheaper from a computational standpoint, but it doesn't work as well at high speeds as FOC. FOC requires significantly more computational overhead. Both systems require knowledge of the rotor position. Estimators for rotor position are not discussed in the above paper, they used an encoder in both cases.
There are many schemes for estimating rotor position. While perhaps not strictly part of FOC, they are often associated with it, and use the information that FOC has in its calculations. The sensorless algorithms I've seen generally are not applicable to Sinusoidal Commutation. There may be some however.
So the Sinusoidal Commutation based controllers for ebikes may have only the hall sensors to provide rotor position. They could time interpolate between the pulses and get fairly good rotor position estimates except when acceleration is changing the position between pulses, but even this could be estimated. So perhaps that's what they are doing.
But manufacturers don't always use the terminology precisely (just as we don't). So it is hard to know exactly what they mean. But there are more sinusoidal techniques than just FOC.
Alan B
100 GW
madin88 said:
That is pretty darn accurate!
cavallo pazzo
100 mW
With last software allowing variable regen and "good" tuning on Phaserunner, decelarating is nice and smooth. Total regen didn't really changed, as I more often use mild current and vary on a wide range from 0.4 V to 0.0 V (at 20 A max) instead of having 7-8 A all the time. Sometimes too strong, sometimes too weak and I had to anticipate to make good use of regen.
I really feel high current regen as an alternative to classical "heat" brakes, for everything but emergencies. Now I can slow down in a 10 % downslope, that's impressive !
Only drawback ?
Everybody wants one, and I struggle to explain I'm THE lucky guy using it so far.
I'll be more than happy when production will raise to semi industrial volumes to allow some units to arrive here.
Really nice controller, thanks.
I really feel high current regen as an alternative to classical "heat" brakes, for everything but emergencies. Now I can slow down in a 10 % downslope, that's impressive !
Only drawback ?
Everybody wants one, and I struggle to explain I'm THE lucky guy using it so far.
I'll be more than happy when production will raise to semi industrial volumes to allow some units to arrive here.
Really nice controller, thanks.
MrDude_1
100 kW
So did anyone ever figure out how big of a heatsink a phaserunner needs to maintain its peak continuous output?
I am going to move my phase runner over from my scooter (where it had a large heatsink) over to my new ebike project, and I want to maintain about 3.5 to 4kw of power like the scooter... but I dont want to make the heatsink any larger than needed.
I am going to move my phase runner over from my scooter (where it had a large heatsink) over to my new ebike project, and I want to maintain about 3.5 to 4kw of power like the scooter... but I dont want to make the heatsink any larger than needed.
MrDude_1
100 kW
maybe I missed it, but is there a "default" xml file I can load through bacdoor to reset it to "as shipped"??
I am swapping from a 80-100 to a new hub motor, and want to try the new grin software... but first I have alot of tweaks, and I want to get back to "stock" and start over.
I am swapping from a 80-100 to a new hub motor, and want to try the new grin software... but first I have alot of tweaks, and I want to get back to "stock" and start over.
Hi,
I am trying to set up my BAC2000. I have read through the 30 pages of information.
Mr. Bill's information has been a big help especially pointing out the incorrect wiring diagram.
I am using Bacdoor 1.5.0.0.
I am comfortable that my wiring is correct. The program connects with the control and reads voltage, temperature, etc.
I am having problems getting auto tune to happen. I press the pole button in the display only box on the Basic Motor (sensored) page. I enter 1 in the Write(Temp) for motor discover mode (1 for automotor parameter discover, 2 for auto Hall discover, 4 does not seem to be anything) and press enter or write. Nothing seems to happen (no high frequesncy buzzing as others have described) either way and autotune Rs and autotune Ls stays at 0. When I try entering 2, I do not see anything happen and no numbers change but when I hand spin the motor, the motor RPM and motor speed show the motor spinning.
Despite selecting 'save to flash', if I switch off the motor and switch it back on, it will not show any rpm when I hand spin it, until I do the auto Hall discover again.
Sensorless (with Halls unplugged) also gives me rpm when hand spun but no auto tune.
The motor is an un-badged mid drive with 12 pole pairs. I have throttle and regen controls going to pins 6 and 7. They read correctly 0-5 volts and seem to be set right.
Any suggestions?
Thanks
Cliff
I am trying to set up my BAC2000. I have read through the 30 pages of information.
Mr. Bill's information has been a big help especially pointing out the incorrect wiring diagram.
I am using Bacdoor 1.5.0.0.
I am comfortable that my wiring is correct. The program connects with the control and reads voltage, temperature, etc.
I am having problems getting auto tune to happen. I press the pole button in the display only box on the Basic Motor (sensored) page. I enter 1 in the Write(Temp) for motor discover mode (1 for automotor parameter discover, 2 for auto Hall discover, 4 does not seem to be anything) and press enter or write. Nothing seems to happen (no high frequesncy buzzing as others have described) either way and autotune Rs and autotune Ls stays at 0. When I try entering 2, I do not see anything happen and no numbers change but when I hand spin the motor, the motor RPM and motor speed show the motor spinning.
Despite selecting 'save to flash', if I switch off the motor and switch it back on, it will not show any rpm when I hand spin it, until I do the auto Hall discover again.
Sensorless (with Halls unplugged) also gives me rpm when hand spun but no auto tune.
The motor is an un-badged mid drive with 12 pole pairs. I have throttle and regen controls going to pins 6 and 7. They read correctly 0-5 volts and seem to be set right.
Any suggestions?
Thanks
Cliff
mrbill
10 kW
Hi Cliff:
Check that the "Read" and/or "Poll" buttons are pressed (highlighted blue, I think) when you enter a 1 or 2 in "Motor discover mode" box. You may need to try all four combinations--I can't remember the working combination. Unfortunately, I can't quickly check unless I'm connected to a controller--a quirk of the software-- and I don't really want to reprogram mine at this time.
Also, check that the Status button is clear (not red), and if it is red, then click the Reset button.
The latest version of BacDoor that I have been using is 1.5.4.0. There may be a later version.
BacDoor is a bit clunky, but once you learn its quirks, it's not too hard to use.
Check that the "Read" and/or "Poll" buttons are pressed (highlighted blue, I think) when you enter a 1 or 2 in "Motor discover mode" box. You may need to try all four combinations--I can't remember the working combination. Unfortunately, I can't quickly check unless I'm connected to a controller--a quirk of the software-- and I don't really want to reprogram mine at this time.
Also, check that the Status button is clear (not red), and if it is red, then click the Reset button.
The latest version of BacDoor that I have been using is 1.5.4.0. There may be a later version.
BacDoor is a bit clunky, but once you learn its quirks, it's not too hard to use.
Similar threads
