OK did the filing unemployment insurance thing for the former tenant thing and did the falling asleep on the couch right after at about 1430 thing. Got to bed about 1500 and was out almost immediately because the sleepytime cocktail hit almost immediately. I’m not sure when I woke up because it was dark outside and I normally judge time by seeing how the shadows fall on the fence around the north side neighbor’s yard. Mrs. the Poet got off the couch and in the bed at about 0230 so I got out of bed at 0245.
While I was drifting back and forth between awake and asleep but lucid dreaming, I contemplated an AWD Electric T-Bucket. The motor I mentioned for the electric A-Mod racer a few posts back is actually intended for a street vehicle and has PTO from either end, partially for ease of installation and partially to allow running as a “stack” of motors, or as I like saying “some from column A…”. Well I was thinking that if I could take power off either end why not both ends? Run the motor on the centerline and power the front wheels of the front output shaft of the motor and the rear wheels off the rear output shaft, and use some kind of decoupler to unhook the front wheels when the front axle is trying to run at a higher speed than the rear axle because of the geometry of the drive system.
Sidebar, this is a thing caused by steering the front wheels on a two axle system and had nothing to do with which end is driven. The front wheels run slightly further than the rears because of geometry, and the wheel on the outside of a turn takes a longer path than the inside wheel, and if no allowance is made for this either the tires wear out faster or more energy is consumed, and usually both at the same time. The usual allowance is to have one end or the other free-wheeling which is the natural occurrence when only one axle gets drive, and a differential on the driven axle for the inside-outside speed difference. Where it gets tricky is when both axles are driven with a solid connection between the two. Most of the time a solid connection is good, ensuring all the power gets to the road that the road surface can hold even if there is slippage at one corner. This even applies when turning, which is why welded rear differentials work most of the time except in low power and high traction situations. Ironically there is much more stress on the welds from just gentle driving on pavement than there is racing on the same surface. Back to the e-Bucket.
As I was saying, why not pull power from both ends of the motor and powering both axles, and use something to unhook the front axle when going around turns on high traction surfaces? Something like the mechanism from a locking differential? Well a big part of how that works is the different loads between the axles and we don’t have that here, we have power coming in on one side and going out the other. There is also lockers that use electric or pneumatic driven clutches to unlock one side or the other on demand that might work, since we have lots of electricity to run the electric kind. The trick would be sensing when the front is driving the system instead of being driven. The locking and unlocking is existing technology and so is torque sensing on a rotating shaft, so the trick then becomes integrating the two and running the unlock and relock fast enough to appear seamless. And some kind of logic that can tell when the front wheels are no longer trying to turn faster than the front and can be solidly connected to the output shaft again. So, the system will require torque and speed sensing from both sides of the locker, torque sensing to unlock and speed sensing to relock. Or, and this just came to mind as I was getting ready to put this to bed and do something else, adjust the logic to use the direction of torque from the sensor on the axle side of the locker to tell when the front wheels are driving the motor instead of vice-versa and only have one torque sensor in the system to reduce costs.
Second sidebar, on RC cars this is done with a one way sprag that only transmits power, well one way. While this is great for model cars that can be picked up and moved from a situation requiring travel in the opposite direction, it’s obviously no good for a real car that has to be driven in reverse. But it does provide a working mechanical solution to the problem.
The fun part comes from trying to do this on a “disposable income from SS” budget, we are literally talking years of saving just to buy the torque sensors at Ali Baba prices, forget retail in the US prices. The speed sensors are literally just a few bucks because there are like 2 of them in every LS engine sold and as many as 8 in the more exotic engine designs that have 4 cams and independently change their timing as well as have sensors watching the input and output speed of the transmission to track the health of the friction materials. I’m talking less than $100 for all the speed sensors for the system. But the torque sensors that will not twist in two under the shock loads start at a kilobuck and go up from there, and this system requires a minimum of two and a high probability of 3 total for best system performance. The controller is the easy part, an Arduino has way more processing power than this requires. It could balance your checkbook between system inputs and outputs, and still not miss anything. If anything it’s too fast and powerful, the conditions we need to track change over a few hundredths of a second, and the Arduino works at several million ops per second, literally more than a million times faster than needed or to quote the Wiki: “the ATmega microcontroller can execute up to 16 million instructions per second,” and we need to run a few hundred times a second to not get ahead of the physical system. This is why we can get good control over a mechanical system with a cheap electronic system. The old Moore’s Law “processing power per $ doubles every “x” years” (before inflation) from the mid XX century has brought us to the point that it is cheaper to use a computer than it is to depend on mechanical controls. The cost limit is now the physics of the sensors and other things needed to connect the processor to the real world.
Now the fun part of this is putting extra weight on the passenger side to balance the weight of the driver and not having it just be ballast. That can be done with a driver-weight battery pack on the passenger side of the vehicle, either an add-on, or just having that much weight naturally on the passenger side when all the bits and pieces are put in place. My preference is to have the weight balance out when all the bits are where they are supposed to be rather than adding another battery pack to go racing. Actually my preferred option is to remove a driver weight of battery from the driver’s side of the car, and call it an extended range pack to go racing, and use the BMS to pull power from the cells that were taken out to race when driving back from the race. The idea is usually to remove weight before racing, not add except to meet minimum weight rules. Since F=M*A for a given F you need to reduce M to increase A, increasing M just doesn’t make sense. The other fun part is you can make the pack low in the car to get the CG low without making the Polar Moment high, and you can build the pack around objects so they can mount as low as possible. And when objects are already as low as possible, if they don’t need to have cooling airflow it’s also sometimes possible to mount the battery underneath some things to further lower CG height. Anywho, this is what can happen when you change from an IC engine and support systems to electric power.
Witch on a Bicycle 