I started my ebike journey with this Novara bike, and it had the controls in the usual USA configuration - right rear, left front. I grew up with that on many bicycles before, but of course had to adapt to motorcycle setups for many years and miles with right front, left clutch, right toe rear brake. The other day when I test drove the Zero electric motorcycles I had to adapt to right front, left nothing and of course right footbrake. It felt weird for a couple of seconds and then mostly normal, with brief moments of confusion that became less and less frequent as the ride progressed.
At any rate, my ebikes are USA bike standard, right rear, left front.
I'm thinking for this AWD ebike that I will keep the right rear, left front brake setup, that's hard to change with the hydraulic front and cable rear brake. I spent quite a bit for quality on both those items. Unfortunately neither have switches, I may want to add magnetic switching to them later.
I mention this because we don't want to confuse left/right, so I will try to avoid using that terminology without clarification in this discussion.
Throttle Splitter
The most convenient physical implementation of this "throttle splitter" is to connect to both controllers via the CA connectors, and then provide a third output for the real CAv3 (using an external shunt that reads battery current before both controllers, so the total battery current):
CA connector pinout (one for each motor controller, plus one for the actual CA)
Pin 1: Red = Battery +75V
Pin 2: Black = Ground
Pin 3: Blue = Shunt Negative
Pin 4: White = Shunt Positive
Pin 5: Yellow = Motor Hall Sensor
Pin 6: Green = Throttle
That provides almost everything needed, but it doesn't provide the 5V power, which can be had from the throttle connector:
Throttle Connector (one for each controller)
Pin 1: Red = 5V
Pin 2: Black = Gnd
Pin 3: Green = Throttle
And if motor temperatures are wanted:
Thermistor (one for each motor)
Pin 1: Black = Gnd
Pin 2: Yellow = NTC
The tricky part is to keep the controllers isolated and don't connect grounds (or anything) between them in the splitter. If that happens it creates a ground loop, and it can cause very high battery current surges to try and flow through the mixer, which not only confuses the throttle inputs but could destroy the mixer and/or the controllers low level inputs. Circuitry in the mixer must be designed to keep the two controller inputs and outputs separated, and handle surges and variations in ground voltages. I know how to do that.
I don't like the normal "direct PWM" throttles on the Infineon controllers, they are okay on a very low powered ebikes but become very jerky as the power is increased. A torque throttle is better, but requires accurate motor current knowledge which is more difficult, but an excellent compromise is a power throttle. In our case we have battery voltage and current for each controller, so we can do a power throttle, or the slightly simpler battery current throttle which is almost the same and even a bit easier. So you decide what maximum battery current is for each motor at the nominal battery voltage, and that becomes 100% for that motor.
In the software we read the one main throttle and map the throttle input voltage to 0-100%, with appropriate detection for a stuck throttle.
In the software we make two control loops, one for each motor. In each loop we measure the battery current, compute the percentage for that motor based on the max for that motor, and that is the % power that motor is running at. This is compared with the power level requested by the main throttle and the difference is the error. This is used to increase or decrease the throttle output value for that motor, making a closed loop control for each motor. A pid or similar loop can be used here, or fuzzy logic.
This is somewhat simplified, but from this simple beginning we can add other features to get where we want to be. We can read some input switches or pots to select front wheel drive, rear wheel drive, or all wheel drive, combine some power level settings, and vary the proportion of power to each motor. Then these factors are used to scale the power requests to each loop.
We can detect the front is slipping if front speed is greater than the rear (once they are properly scaled as the pulse rates are different). If the front is slipping we can reduce the front power until it stops slipping. Rate of change and power can also be used to detect slippage.
Detecting a slip on the rear is a bit harder, we could do that by looking at the rate of change and the power drop, or we could decide that the rear slipping is up to the operator to take care of and not put controller software in for that. Then if the operator wants to spin the rear wheel he can.
If the control switches are mounted conveniently they could be activated while driving. But what are the circumstances where one would want to do this during an emergency? The splitter can handle the front wheel slipping better than the rider (earlier detection and quicker response). A rear wheel slip is pretty easy to handle, by reduce the throttle, and something the operator may not want automation for.
One could still have a second throttle input, and a software protocol defined for what the mixer should do if this input suddenly comes off of zero. You just have to decide how you want the mixer to respond to the additional input and put the appropriate code into the program.
I know an automotive controls engineer, I'll have to ask him how they handle these cases at some point. I know they do a lot of testing on ice and slippery surfaces to make sure they have the algorithms right, but they never let the driver decide. So they have to handle all the cases.
My primary concern is to not allow the front to spin. That is difficult to deal with and can quickly result in a loss of bicycle balance. Rear spins are much easier to compensate for and something that most riders have experience with. So to start with I'd include front wheel anti-slip code but not rear wheel anti-slip. This build doesn't have enough power to slip the rear wheel in very many circumstances. But it might be interesting to add that capability later.
