Electric Bike motor, lights, safety features conversion kit

[Amberwolf]

Ladyada suggested I post this request for an engineering/programming partner here on the forums:

For nearly a year, I have been improving an idea for an electric bicycle conversion kit (or building into the bike's design and original construction, which would be easier and probably give more consistent results, but less practical from a small business standpoint) based around the safety of the rider and the efficient use of the small amount of power that can be carried on a lightweight HPV, and ease of use of the entire system.

There are a considerable number of integrated ideas in this system, so I won't go into that much detail here, but would rather like to communicate directly via email with anyone interested in doing this. Before emailing, however, I would like to see responses here regarding interest in helping implement the project.

The only practical way to create it is via microcontroller(s), which I have very little experience with (the last one I used was the 6802 microprocessor, programmed directly in hex or compiled from assembly language input, when I was in DeVry over 20 years ago). My programming skills were poor then, and essentially non-existent now. Thus, I have yet to do more than think about the things that must be implemented, and prioritization of subsystems, user-interfaces, physical construction and design, etc.


Would anyone here be interested in helping me develop this as a viable system? I suspect that if we decided to, we could even get a patent for it as a system, if you are interested in such things. I dont' know how to go about that, either, but it doesn't really matter. I mostly want to make this system for my own HPV's, but quite simply am not going to have the skills needed to do it well enough to be reliable, not by myself.

Some things, like hardware of motor control output stages, I can simply over-engineer and not have to worry about them blowing up, but using finesse instead would be better and cheaper, component wise (as an example, currently the rebuilt controller I'm using on my Electricle™ project bike has 100A/100V MOSFETs in it, because the smaller more reasonable ones kept blowing up due to various electrical issues I'd run into, probably induced voltage spikes from the motors, but I have no o-scope yet to troubleshoot that type of problem). I'd also much rather use a microcontroller to do the actual motor controlling simply because it's a lot easier to change parameters in software (as a user/rider) than it is to change out hardware components, adust values, etc. Also it's easier to make a controller that can handle a number of different ways a motor might be used on an HPV, whether direct drive (hub motor), gear-driven, belt-driven (with expected slippage if revved up too fast), chain-driven, etc.

Once I find someone or a team of people that are interested in this project and seem capable of completing it based on existing current and past projects that examples can be provided of, I can send out the multipage general specifications for the idea, to see if it's still interesting and something you'd want to tackle.

I don't mind it ending up as open-source, and in fact it's probably better if it does so, but I do want to ensure that all of the things I need this to do will be part of at least one version of the project, even if other versions are simplified or added to, because I *really* want to be able to use this as envisioned on my own HPVs (both the regular bikes I already have, and the less standard ones I'm in the process of designing and building).

[koolkat]

So you want to build something like a motorcycle ...except on a bike...and electric?

I can help...I have nothing else to do in my free time...

[Amberwolf]

Mmm, not really like a motorcycle, no.

The motorcycle doesn't integrate human power and electric assistance, which is all this does, motor-wise. In fact (though I don't think I put this in the first post), with this system, unless one were to defeat the code for it, it will only allow the motor to work while you are pedalling, because it's throttle control is how hard you are pedalling. Or rather, a threshold above which the motor runs, and the harder you pedal the faster it runs, so that it attempts to keep you from having to pedal harder than the user-configurable amount of force. That's partly so that if a rider (like me) has bad knees or whatnot, it can be set to help keep pedaling force below the point of pain or injury, while still allowing higher gears for faster speeds.

Without the simple motor assist I have now, I'd maybe be able to go 7 or 8MPH, at most, and would have to get off and walk in a headwind. With the assist, I can easily maintain 15-20MPH and actually get where I'm going before the day is over. Unfortunately, what I have now is not very efficient, for a lot of reasons, and the batteries are also old and heavy (SLA), and are nearing the point where they will have to be replaced with *something*, pretty soon. See this post for some of the info and pics of the system I am using now:
http://electricle.blogspot.com/2008/07/ ... creen.html
http://electricle.blogspot.com/2008/06/ ... drive.html

Except for the integration of all the systems together, and the safety features it would have available as a result of the integration making monitoring of many things and feedback to each of them from other systems possible, this is pretty much like any other electric-assist kit for bikes that already exists (there are at least dozens, if not hundreds, of different types).

Most of them are cheap, and their prices reflect that. Some are pretty good, or even very good, and are generally significantly more expensive. This one would be in the upper end of the price range for kits; my guess is that it would cost (depending on battery type chosen to power it) upwards of $1500. Much less if only using SLA batteries to power it, but then it would weigh a LOT and have little range.

Now, many of the other kits out there are capable of just driving the whole bike without any pedalling, and depending on the motor used with this kit, that's possible with it, too, power-wise. But I don't want to have a separate throttle on this one, simply because, well, I don't want to. There are actually more reasons for that, but the biggest ones boil down to that. I don't want one more thing to put on the handlebars. One more thing to distract from riding or have to do with my hands. One more thing to break in a crash or if the bike falls over on it's side and the bars hit the wall or the ground (common occurence when I'm at a store, because people mess with stuff and/or they aren't careful when locking up or removing their own bikes from the common rack). WIthout the separate throttle, one must at least pedal minimally, even though the force can be set really low on the config page.

One catch: I don't know what kind of sensor would be best to use for this. It can't be a simple magnetic or optical sensor, because those will only detect speed, and that's irrelevant. Pedalling *faster* doesn't make the unit iincrease motor speed, it only pedalling *harder*. Strain gauges of various types are probably necessary, but all the ones I have seen are going to require placement on the pedals themselves (so they detect the pressure of the foot on them) or on the cranks (so they detect torque forces at work across the length or width of the crank), and both of those are moving all the time in relation to the bike, and thus must have a sensor unit that contains it's own power source, as well as a way to transmit the information to the rest of the bike.

Electrical contacts such as rings with tabs or fingers rubbing on them to maintain connection are not going to work in the very dirty environment of a typical bottom bracket. There also is little space there on most bikes, so finding a place to put the contactor rings and fingers is a little difficult.

For the recycled-parts recumbent I'm building that will have a similar (but analog-based) throttle system, the communication will be done with an IRLED from each pedal unit, inside the Bottom Bracket housing, actually mounted on the crankshaft between the bearing rings. The wire will be run from a box on the back of each pedal that will contain the batteries and electronics for the sensors, via a groove in the shaft under the threaded rings and bearing cups, etc, to the center of the shaft. An IR receiver and preamp inside the BB will pick up the signal (which is being reflected around the inside of the BB housing, meaning the signal gets stronger and weaker during rotation but never interrupted), and amplify it and pass it along as a throttle voltage to the analog-based motor controller I've already got.

The actual sensor to translate the pedalling force into voltage to transmit to the IRLEDs hasn't been decided yet, since I don't yet know enough about the different types. It has to be something that either is already weatherproof or will still work fine once it is encased in weatherproofing.

Piezo elements might work, since they generate a voltage when distorted, and that distortion can be forced to happen depending on how they're mounted on the pedals and/or cranks.

Resistive strain gauges might work on the cranks, detecting the flex of the cranks. Since every kind of them (and there are a LOT) is different, and would flex differently, there must also be a calibration routine on the controller that the rider can run while stationary to configure the min and max flex levels detected. The same is probably true of any sensor used for the throttle.

Again, I really don't know how to do this part yet, just have a number of possible ideas for it.

This is going to be the very first hurdle to overcome, of many.

I expect the programming will be fairly easy for anyone that knows how to do it, but will almost certainly be pretty large. FWIW, I was originally going to just use the STM32Circle device for the actual bike computer, before I gave up on learning to program in C (I really really just can't remember enough of it as I go along to get anywhere). I don't recall the exact MCU that's in it, but the MEMS 3-axis accelerometer in it is really what got my attention, because it can be used as a mouse pointer to move the cursor around it's screen (it comes with PacMan and Breakout clones on it, to showcase that ability). Naturally, it can also simply be used to detect bike tilt, acceleration, deceleration, etc, to monitor each of these and engage safety and other features based on those factors. It also has it's own realtime OS on it, which is a big factor in making me want to use it, since it makes a lot of things easier to do. The color LCD screen was also a feature I could see a lot of use for, primarily as speedometer and battery condition display.

The bike computer itself I would like to have be removable, with a USB port to hook to the computer to power it and charge it's backup batteries (it would be powered by the main bike batteries normally), and to both reprogram the computer with firmware updates and to do the configuration on the PC (Windows or Mac or Linux system, if possible). Using the MEMS sensor, on-the-road config is also possible, though much more tedious, by taking it off the bike and entering config mode, then using the tilt to move the cursor around, etc.

The reason for that design was that the STM32Circle only has one button, and the MEMS sensor, for input. If the bike computer box is designed from scratch rather than using the STM32Circle, a separate cursor pad can be created and used. That would add to the complexity both of building it and of weatherproofing it, but would certainly make it easier for the rider to do on-bike setup.

I'm not set on using any specific MCU, so whatever you (or others) have experience with that can do the jobs needed here is fine. I don't know exactly how many of which kinds of I/O it's going to need, but I have a feeling it will need to be a fast one with a lot of program EEPROM and user-flash available. Since I already have an STM32Circle (and another USB-based STM 8-bit MCU) development unit, I could at least test things on my end if that's used--otherwise it could be a while before I could afford whatever dev kit or stuff is needed to do this with a different MCU (I got the STM stuff free at a distributor seminar).

Enough for now, before I bore you.

[koolkat]

Ok...I think I'm starting to get it...(after trying to read the entire post )

You want a bike that you can pedal minimally and go faster with use of an electric motor?

Also, and you please explain the features that you want the bike to have (in a list please )

Thanks

[macegr]

To sense applied force, use a spring-loaded idler on the bike chain, pivoting a potentiometer.

[Amberwolf]

Sorry for the really late reply, been kinda busy and trying to work on that list before replying, then realized just now how long it's been since you posted!

Ok...I think I'm starting to get it...(after trying to read the entire post )

You want a bike that you can pedal minimally and go faster with use of an electric motor?

Well, not exactly go faster, just go easier. You might mean the same thing, but it doesn't sound quite the same, and the difference is important in this case. Once I post the list it should make more sense.

Also, and you please explain the features that you want the bike to have (in a list please )

I'm still working on this, as when I re-read my list, it was written so much for myself that I needed to rewrite it so others could understand what I actually wanted from it.

Keep in mind this list is going to be a pretty long read, because I can't just list the feature, I have to describe what it must do. It's probable that I will have to re-explain some features, especially if you are not familiar with bicycles (riding one may not count, depending on how much you know about the mechanics of them, and the differences between kinds of bikes and some bike parts). I may use some butchered terminology, too, so ask if you don't know exactly what some term means.

[Amberwolf]

To sense applied force, use a spring-loaded idler on the bike chain, pivoting a potentiometer.

That's...too simple! I never thought of that. I'll have to see about working out a simple version of this that I can test on the bike I have now, and see if it works well enough mechanically and actually does what I need it to.

Hmm...I assume that it's meant to rotate the pot on the pivot axis for the idler's bracket mounting, pivoting further the faster the chain is pulled across the idler, tautening the chain more against the spring. This may not really do what I need, though. It seems that it would not actually be sensing force but rather speed of pedalling, which isn't the same, especially with a range of speed always existing between different chainring sets of the bike, before shifting from one to the next is necessary to reduce the required force on the pedals. Also, something that is sensing chain tension is going to get spikes and dips in it's readout as the chain shifts between chainrings, potentially causing unpredictable motor output changes.

At least, this is the image I get of what will happen.

I guess I'll have to try building it and see.

[macegr]

My visualization was a rather strong spring loaded idler that would be positioned on the top side of the chain loop and attempt to push down. The more pressure is applied to the pedals, the more tension is exerted on the top of the chain loop. Tension will want to make the top of the loop straight, increasingly moving the spring idler up as tension rises.

If you power the wheels independently of the chain, this will work. A rider steps on the pedals and starts to accelerate. The motor always tries to reduce the idler tension to zero. It speeds up the bike as long as the rider can maintain tension on the chain. If there is no tension in the chain, then the rider is either stopped, coasting, or pedaling the same speed as the bike and the motor should stop. If there is tension in the chain, the rider is starting the bike, or trying to accelerate, and the motor should add some power to the wheels.

You would need a one-way bearing for the motor, because the motor will stop when no power to the wheels is needed; such as when the rider is coasting to a stop. This kind of setup would not be useful for a regenerative braking system unless you added an electronic clutch to the motor.

It may also be necessary to encode wheel speed and do some math while starting up the motor, so you don't no-load inside the one-way bearing and then suddenly engage.

If you want the rider to select a speed and let the motor run continuously, you should go back to a throttle approach instead of pedal sensors. If the rider stops pedaling, there is no easy way to tell if the rider wants to cruise at speed with motor active, or coast to a stop. I assume the whole intent of the project is to help riders start from a stop in busy traffic and ascend steep hills, which my method described above will do.

[Amberwolf]

My visualization was a rather strong spring loaded idler that would be positioned on the top side of the chain loop and attempt to push down. The more pressure is applied to the pedals, the more tension is exerted on the top of the chain loop. Tension will want to make the top of the loop straight, increasingly moving the spring idler up as tension rises.

That's pretty much what I am imagining, and what I've sketched up to try once I get a chance.

If you power the wheels independently of the chain, this will work. A rider steps on the pedals and starts to accelerate. The motor always tries to reduce the idler tension to zero. It speeds up the bike as long as the rider can maintain tension on the chain. If there is no tension in the chain, then the rider is either stopped, coasting, or pedaling the same speed as the bike and the motor should stop. If there is tension in the chain, the rider is starting the bike, or trying to accelerate, and the motor should add some power to the wheels.

This will work for the kit I want to make for potential sale, but it will only work for the recumbent I'm building right now if I put the idler onto one of the front two chains, before the wheel's drivetrain chain at the rear, because the motor shares the entire rear primary drivetrain with the pedals, so that the shifting and sprocket system can be used to make the motor run as efficiently as possible (keep it at it's optimum speed whereever possible, just like it's designed to do for the human pedalling). The motor itself will already be reduced via it's own sprockets or gears down to 80-100RPM average speed at the input to that drivetrain, just like my average pedalling speed would be.

You would need a one-way bearing for the motor, because the motor will stop when no power to the wheels is needed; such as when the rider is coasting to a stop. This kind of setup would not be useful for a regenerative braking system unless you added an electronic clutch to the motor.

For my current recumbent project, I'm not planning on regen braking, as I have freewheels in the system to keep me from having to pedal against the unpowered motor's resistance if I were to run out of power or have a system failure, etc. For the kit, that will partly depend on whether the end-user uses their own motor system already on the bike (or from somewhere else), or uses one provided with the kit (if it is decided to include one at all).

It may also be necessary to encode wheel speed and do some math while starting up the motor, so you don't no-load inside the one-way bearing and then suddenly engage.

I would probably always do some ramping up to speed, so there is no sudden jerk to the rider or high-power-spike thru the controller electronics, aside from mechanical considerations. Wheel speed will be detected and considered anyway, for a separate reason (ensuring the motor will not engage when over 20MPH, as that's illegal in at least some places, and undetermined in others).

If you want the rider to select a speed and let the motor run continuously, you should go back to a throttle approach instead of pedal sensors. If the rider stops pedaling, there is no easy way to tell if the rider wants to cruise at speed with motor active, or coast to a stop. I assume the whole intent of the project is to help riders start from a stop in busy traffic and ascend steep hills, which my method described above will do.

Your assumption is correct, and an additional purpose is also to reduce the need for riders to ever pedal really hard if they either don't want to or can't (like me, because of my knees). The actual tension point at which the motor would begin to operate and the curve upon which it acts would be adjustable by the user with the configuration page of the controller, along with most other things. That way they can set it for a certain amount of force to be required before the motor engages, to fit their riding style or physical requirements. The range of adjustment would be limited only by the mechanics of the sensor system itself, and I don't really know how to calcuate that out, but I'll figure something out there.

I wish there was a way to just slap a strain gauge on the cranks to figure this out, without having to have some wireless method of getting the data from it to the controller, along with all the encoding and power issues that involves. But realistically, there's no cheap and easy way to do that, especially in a way that would "just work" on practically any standard bike, installable by a typical bike rider.

The system will have the *option* for a standard throttle instead of the tension-controller, but that's not part of the way the idea is supposed to work--just a way to get more people to buy one than would otherwise (because some people won't want to pedal at all, and just want to have a motor-driven cycle, instead of motor-assist, which is fine, but not the original intent of this system).

[Amberwolf]

Ok, well, here is a list of some of the things. I'm still trying to type this up in a "spec like" format, along with other things it has to do.



The system's motor control would need to ensure the motor does not overheat, draw too much current, and that it is running at the optimal speed for the desired HPV speed. Some conversions will be running thru the HPV's drivetrain, and some thru a computer-controlled drivetrain (or gearbox), so direct measurements of the motor's speed are not necessarily directly relevant, but rather comparing motor power usage with vehicle speed, and shifting the drivetrain ratios to keep the lowest power usage while ensuring speed does not change.

Speed control itself is not done by a throttle, but rather by sensing the force applied to the pedals by the rider, so that that force is always the same (user-adjustable). Thus, the motor assists the rider as needed to maintain the level of effort that rider feels best with. There is thus also no separate control to have to deal with during riding, and no worries about a throttle (thumb, griptwist, etc) breaking during a crash when the handlebars impact something. It also ensures that a rider does not wear out the batteries too quickly, as they are always providing some of the energy.

Helps with forcing some exercise, as well, since a number of those I've seen on ebikes and many I've read posts from in various places simply use the motor and don't pedal at all. Nothing wrong with that, I guess, but for me it's a lot more fun to ride when my whole body is involved in the riding, and I'm not just steering some self-powered vehicle.

The system has turn signals, brake lights, and marker lights, as well as headlights, all of which are light-sensitive so that as ambient light is brighter, it *increases* the lighting to compensate and maintain visibility, thus it can be used in daylight as well as nighttime. At night, it would be dimmer so it does not blind other riders, pedestrians, or other vehicular traffic. The ambient light sensors must thus be set up so that light from only one direction (such as vehicle headlights) will not increase the brightness significantly, but rather only when there is a lot of light coming from around the HPV, for instance when entering a shopping area or other well-lit area vs a poorly-lit residential area. The headlight can be set to not be affected by the ALS.The ALS system also controls the brightness of all of the displays for the rider.
The ALS can be defeated inthe configuration page for each system individually if desired. If it is defeated, a manual brightness control is enabled in the configuration page, and all the lights will be set to that brightness level, when they are turned on.
All marker and signal lights are *always* on, and they have higher priority for power consumption than the motor. If there is not enough power to run all systems, the lights will be the last system to be deprived of power, as that is the most important system to the safety of the rider.

Accelerometers are used to detect tilt of the bike, partly to know when to turn off the motor(s) in the event of an impending crash. If it goes past the point where a rider could recover (say, 60 degrees), the motor is shut off, and if the wheels are determined to be spinning free the wheel is braked on HPVs equipped with any brakes (or hub motors capable of braking, rather than freewheeling) that are computer-controlled. The motor is also turned off when the speed reaches 20.1MPH for more than 5 seconds, because it is in many (most? all?) places illegal to ride a motor-assisted bicycle faster than 20MPH while the motor itself is engaged. The reason for the delay is that there ARE situations in which it would be far better to break the law than die because you couldn't go fast enough to get out of the way of something. That delay is reset to zero as soon as the motor is shut off, so that if you HAVE to, you can immediately retrigger the motor to engage by stopping pedalling, then pedalling harder than the threshold to turn it on, and keep pedalling, so it will again give you 5 seconds of boost before shutting off, again leaving you to pedal unassisted. That process could be repeated indefinitely to defeat the feature, but it could result in a ticket. There will be a beeping or tone (or perhaps even a voice warning, if memory is available for a sampled voice) to indicate the set limit is being exceeded, and that the motor will shut off.
There is an option in the configuration page to turn off each of the automatic shutoffs individually, including a defeat for the 20MPH limit, and a spinner to change that to any number (since some places may have slower speed limits than that, though I don't know of any higher).

Accelerometers also detect the direction the bike is going, comparing it to where it had been going the few seconds prior. This is used for turn signals, both to automatically flash them on when a more-than-gradual turn is being made and to turn them off after you have completed any turn.

The automatic signals would exist because sometimes one needs to maneuver suddenly around debris, potholes, cats running off the sidewalk, etc. Usually that means dodging left into the lanes cars are likely already in. If they're already in a position to hit you, it's too late anyway, and you should know better than to go there no matter what (the spill taken from the debris is probably going to be less damaging than getting hit by the car, depending on your relative speeds). But if they're far enough back that they could have a chance to brake, it's definitely better to give them the signal of a left turn/lane change as a flashing warning that you're about to move, since otherwise they are less likely to notice you are making a leftward maneuver. You might not actually have to move into the lane, but if you do, it's nice to have the signal going without you having to think about it and manually turn it on, all the while also trying to avoid the sudden obstacle, try to see if a vehicle *is* to your left or rearward, *and* perhaps deal with the throttle controls/shifters/etc. to change your speed up or down as you feel necessary.

Manual signals would be a momentary contact switch for each direction, pretty much just like the ones typically used on motorcycles, scooters, and the few bikes that have them today. It could be a rocker switch, or it could be something more advanced (which I would rather see, myself, and have some ideas to be worked out more fully). They will be automatically turned off after riding in a straight line for more than 500 feet (as I don't see any situation I've ever been in that I had to signal that long to be able to move over a lane), or if the direction of travel changes more than 45(?) degrees and then straightens out for a couple of seconds or more. The buttons themselves light up blinking dimly (to keep from blinding the rider) to indicate the signal is still on, so the rider can remember to manually turn them off (by repressing the same button) or turn them back on if they've switched off when the rider needs them still on.
There is an option in the configuration page to turn off each of the automatic shutoffs individually.

Computer-controlled braking could be done (in theory) using muscle-wire, since despite the massive amounts of current used by that stuff, they would not be needed that often or for very long. Unfortunately it's very impractical to use this wire for shifters, as they'd need to be held at a specific tension all the time they're in a specific gear, using that much power the entire time.

IF there is CCBraking available, then accelerometers can also be used to detect too fast a stop for the safety of the bike, where the rear wheel is lifting off the ground, and begin pumping the brakes instead of locking them up. I honestly have no idea if this would work or not or if it is safe, but having seen riders go over the bars because they misapplied their brakes and get seriously injured because of it, I'd like to give the inexperienced rider a way out of such a potential disaster.
For experienced riders there is an option in the configuration page to turn off this feature, as they would be far better at controlling the brakes for a given situation than a computer could ever be.

[koolkat]

I read half of it so far(I was supposed to be doing my homework...)

You wrote that "the ALS can be defeated in the configuration page..."

So do you want the bike to have a screen that you can change settings with?

Thanks

[Amberwolf]

So do you want the bike to have a screen that you can change settings with?

Yep. Two ways to do it.

First is the easiest: if a rider has a PC, they just hook it up with USB and use the PC-based software screen to change all the settings to their preferred defaults. Then when they hit Save it will save them to the controller, and to a local text file so that if they lose the settings somehow in the controller (or the controller is damaged, lost, or stolen and must be replaced), they can easily reset it to their preferred defaults. Probably this will only be used the first time they set it up, for most people that even wish to change anything.

That configuration software will also have some other functions, not all of which I've defined as specs yet.

Then there is a built-in configuration on the device, available only when the bike is stopped, which will display on the same LCD screen that the regular dashboard display would normally be on. Probably it would be scrolled thru using the turn signal controls, as those buttons would already be there and not in use during configuration. There's another button needed for on-the-fly toggling between dashboard screens or other stuff that can be used as a select button during configuration.

All settings that are configurable but have legal or safety implications will require confirmation of changing the setting once selected, but the other settings won't need something like that.

Some settings will need to take effect during configuration so they can be seen how they're affecting it, such as:

--the autobrightness controls
--screen contrast
--tilt-angle-motor-disable (which would provide a sound at the angle the motor would be shut off at while in config page) and could be set two ways. One is by using the cursor buttons to up/down the angle number; the other is to actually tilt the bike to where you want it to shut off, and the MEMS sensor will be read and the value set when the select button is pushed.
--auto turn signal engage, where it will turn on the signals as you turn the handlebars past a certain angle, so you can see how far that is.

There are probably others I can't remember right now, and haven't typed up.

Part of what makes this system different is it's customizability to the user. If I thought it would fit into the typical microcontroller, and had any idea how to do it, I'd really like to have it learn the rider's actual riding style and adapt to it (especially for things like signalling and other safety items, so it could do it automatically when they forget but didn't ever bother to change the settings to let it do so).

Keep in mind that the whole idea of this system is safety for the rider, and whenever that comes in conflict with the riders wishes, the *defaults* for the system err on the safety side, but can be defeated or changed by the rider as much as they wish, and set as the new defaults. So, if they have a motor system capable of doing it, the system will *let* them change it to run the bike without pedalling at 90MPH, but the default in the program will always start out limited to 20MPH because that's the legal limit in most places that have one.


Speaking of motors, the system will allow either brushed DC (simple single-phase PWM) control, or brushless DC (three-phase PWM) motors to be used, by using the appropriate power control module board/box with it and selecting the appropriate motor type in the config page. This complicates the programming, but both types are very common in hub motors already on bikes, and it's always possible someone might have the one kind now, then go for the other later for whatever reason. I myself currently only have brushed DC type motors but am very slowly working on a conversion of a cieling fan motor body into a BLDC type motor, and would end up using this controller system on both types, depending on which bike I was going to use for a while.


The basic construction of the whole thing would be modular, but preferably most would be within a single handle-bar-mounted casing, which would include the front lighting and signalling system. The computer itself would be removable so it could be plugged into a PC or serviced, or used on a second bike equipped with everything except the computer itself.

One specific goal is to have just the one thing on the handlebars, because right now it's difficult or impossible to get a single unit that will provide cycling info, control the motor/etc, provide safety lighting, and so on. That means bolting a bunch of different things to your bars, which makes it harder to flip the bike over for road repairs in many cases, without then readjusting it all afterwards. At worst, with this, a user would undo the clamps holding the system in place and hang it loose while they fixed the flat or whatever, then bolt it back on. At best, assuming it mounts fully below their bar tops, all they need do is flip the bike over and do the repair without worry about this gear. Also could be made much easier for the user to unbolt the whole thing, disconnect the cable(s) and take it in with them in high-accessory-theft areas, which are all too common.

The rear lighting bar would have to be physically separate, if for no other reason than mounting it on different bike types would require it--some have baskets or other cargo pods/racks that prevent using it directly on the seatpost, others only have the seatpost as a mounting point, and still others have brackets as part of the seat itself to use.

The motor controller would be best placed as near the actual motor as possible, but it will depend on the user and the bike design how it is actually mounted, especially since many bikes use front hub motors, and probably wouldn't want the actual controller up on the fork as it could too easily be destroyed in a slide or crash. If it is possible, I'd rather have it as part of the handlebar module, with the heatsink underneath the whole thing. Probably not practical simply because of lead lengths to the motor, and the resistance and inductance that adds to the control system, with concomitant power wastage.

Other modules might include something based on the SpokePOV idea, controlled by the main computer rather than keeping the images in local memory, so that the user could store and select from many different and much larger animations. The only practical way to change them on the road becomes RF transmission, so that's an advanced option to be designed later.

The wheel speed sensor(s) and the pedal-force sensor would have to be physically separate as well. The optional throttle would probably be best as separate, by simply providing a plug for either hall-type or resistive-type, and letting the user buy their own throttle (as there are many kinds, from cheap to expensive, from thumb to grip). The brake lever sensors would be separate but like the wheel speed sensor(s) are very simple, just magnets and hall sensors, and simply need to plug into the computer unit.

[Amberwolf]

Originally I wanted to use the STM32Circle as the main computer unit, as it's cheap (about $30) and already has a 128x128 color screen, MEMS 3-axis accelerometer, and two USB ports, plus the STM32's baseline MCU in it, and a realtime OS with libraries made for a number of purposes, and is pretty fast and with a fair amount of memory, both flash and user RAM. It's also designed to be carried around on a lanyard (which it comes with), and would be perfect for removing from the bike to program or read on the PC.

But I suspect that it will be easier to start the design from scratch, not using any of that, and just design a whole board that has all the main stuff on it, with a removable memory card containing data, programs, and preferences, so the user can take just THAT in and stick it in the PC's card reader for resetting prefs, downloading data from the ride logs, and updating the system's firmware. This way a GPS logging system would even be possible, as opposed to the accelerometer and wheel speed logging that is the only route logging possible with the STM32Circle (without adding external function modules to it via USB).

[koolkat]

Oh Boy...i've been so busy these past few weeks im forgeting to read these forums...but I still think the next couple weeks are just going to be the same
so sorry if im not responding to posts...

[Amberwolf]

I haven't really gotten any further with the controller part of this project, but I am working on a new motorization/drivetrain scheme, on a crazy semi-recumbent made by fastening two different bike frames together.

I have some video of a motor test for those interested:
http://electricle.blogspot.com/2009/01/ ... e-v20.html
Actually three videos, some pics, and a wall of text, but the last is pretty normal for me.

The posts prior to that describe and have pics to show a couple of variations on the frame itself, as well as some details of the mechanics of part of the drivetrain.

I tell ya, this is WAY more fun than fishing my trailer out of the canal.


I'm not sure yet if I'll just use my existing motor controller (rebuilt from scrap and some new MOSFETs) or if I'll build a new one from scratch. Either way, I may well integrate the chain-tension throttle idea Macegr suggested, on the first chain in the pedal part of the system--all the chains past that point include motor drive, so they can't be used for it.