Electric Bike motor, lights, safety features conversion kit

Get help, and assist others in with open source kits and running a business! Do not ask for legal advice or for consulting services in this forum, only general biz questions!

Moderators: adafruit_support_bill, adafruit

Forum rules
Get help, and assist others in with open source kits and running a business! Do not ask for legal advice or for consulting services in this forum, only general biz questions!
User avatar
amberwolf
 
Posts: 310
Joined: Wed Oct 08, 2008 2:42 am

Re: Electric Bike motor, lights, safety features conversion kit

Post by amberwolf »

This is sort of an update/summary of the project info so far. I'll do another of these at some later date, assuming that no one replies and/or wants to do this right now.

I would very much like to base it around the STM32 Primer, or better yet the Primer2, as it has a lot of processing power for future additions, and the STM32 MCU has a number of variations specifically intended for motor-control applications, among other things. It's pretty inexpensive for the power it has. More info on the Primer1 and 2 is here:
http://www.stm32circle.com/

There is a group of people that may also work on a version of it, but I do not know when that will be, nor how long (if ever) it will be before usable results appear. I'd like to get at least a version of this running soon to test on my newest bike creation, for long term determination of how well it does or doesn't work, and for feature refinement.

Basically this project consists of a kit of lights, sensors, controller, motor, and batteries to fit any bicycle or tricycle, upright or recumbent. Obviously for different styles of frame and whatnot, it will need some different components here and there, and thus would need multiple versions or a way to alter things for certain situations.

The motor and motor controller (and battery pack for it) do not have to come with the kit, and indeed are probably better off using one of the many "standard" motor and controller kits already out there, from the cheap to the absurdly expensive. ;-) Since there are so many variations, from friction drive to pedal-chain-insert to hub motor and so on, the overall controller will need sensors that detect the necessary signals regardless of motor type and such.

The functions of the overall controller begin with but are not limited to:
  • Turn signals (manual *and* automatic)
    Brake light (ditto)
    Automatic Ambient Light Sensor (ALS) controlled lighting
    Motor throttle control
    MEMS Tilt-angle-sense for cutoff of systems in crashes, among other things.
    LImit bike speed while under motor power for legal reasons
    Log data like a cycling computer normally does
    Be rider-configurable, when the bike is fully stopped
    Be firmware-updatable for bug fixes or customizations
    Easily undockable from bike for antitheft
    Weather-resistant
    Fully-customizable, in that any item can be enabled or disabled, and all values can be changed, as long as the bike is stopped.

Turn signals are controlled first by buttons on a handlebar grip, as normally done by a three-position switch of some type (some are slide, some are rocker). Two buttons, left and right, close enough together to be easily pushed simultaneously for "off", preferably with arrow-shaped buttons pointing left and right so that they can be distinguished by touch, but also backlit slightly for nighttime use (backlight controlled by the ALS).

When steering-angle has passed 45° and then returned to straight for a few seconds, relative to the frame of the bike, the signals will be automatically shut off, in case the rider simply forgot to do so manually. This can be accomplished via magnets and Hall sensors (or reed switches) in the steering stem, or by having two MEMS sensors, one on the steering fork or handlebars and one on the bike frame, and comparing their outputs. Having two sensors gives the ability to do other safety-related things later on, and so is the preferred method.

If steering angle exceeds 15° for more than a second, the turn signal for that direction will engage automatically, in case the rider forgot to signal but is beginning a turn or lane change, etc. Better late than never, as the blinking signal will give visibility to the change in direction possibly otherwise unnoticed by another vehicle approaching from the rear, especially at night on poorly-lit roads. The signal can be overridden after it starts by pressing both buttons, or prevented from starting by holding both buttons during the maneuver, in case there is a reason to maneuver like this with no signal.


Brake light will engage manually via the brake handles. The rider may choose to replace their existing levers with ones that have integrated NC switches in them, or install magnets on the levers and encapsulated NC reed switches on the mounting bases (because rarely are the inexpensive integrated-switch brake levers all that great a quality, and many may prefer or even require the levers they already have for one reason or another).

Brake light will also engage automatically, if the bike drops suddenly in speed, by perhaps 10% per second, possibly less. If a pedal sensor exists (for cadence monitoring, for instance) then that sensor can also be used, along with the speedometer sensor(s), to determine if the rider is intending to slow down (coasting to a stop, for instance), and engage the brake light for that instance as well (perhaps only after dropping below some critical threshold speed). Though it is always possible for a rider to manually engage the brake light without engaging the brakes, by squeezing the levers just enough to actuate the switches, it is easier and perhaps safer to have the controller do it for them during a coast-to-a-stop. If desired, the brake light can be disengaged by manually engaging and disengaging the brake light for half a second or so. If the conditions that triggered it in the first place continue after that, it will reengage just as before, after the original time delay, and can again be aborted manually. I don't really see a need for disengaging it manually, but someone else might, thus the provision.

The reason for this is that If no brake light occurs, there are instances where some motor vehicles simply do not stop, even at a traffic control like a stop sign, and can hit the bike from behind because they weren't paying close enough attention. With the brake light activation, any following vehicle will be alerted to a stop, just as if a regular motor vehicle was braking from it's road-speed to a stop (most motor vehicle drivers do not coast to a stop, but rather stop very quickly from the road's speed limit within the last score or two of feet at most, thus always engaging their brake lights, which warns vehicles behind them of the impending stop). An experienced cyclist *usually* coasts down to a stop, applying brakes only if necessary to completely stop at the end, which may not give enough warning to the vehicles behind them.

In all cases, the brake switches are routed into the OC, then the OC will output to both the brake light and to the motor controller (most of which have a dedicated brake switch input to cut motor power or even actively brake the motor when it is engaged).


Automatic Ambient Light Sensor (ALS) will change brightness levels of all lighting on the bike to keep it as visible as possible under changing lighting conditions without endangering the vision of anyone in darker lighting conditions.

Under daylight conditions, it will turn on all lighting at maximum brightness to make rull visibility possible.

Under darker, shadowy conditions (in tunnels, under trees, etc) it will turn the brightness down after a few seconds or less so that it is not wasting power where unneeded, as it is going to still be quite visible.

In full darkness, including streetlight conditions, it will turn brightness down by at least 2/3, so that the daylight-visible markers, headlight, and signals are not going to blind other vehicle drivers and riders (or pedestrians) who have dark-adapted eyes. Currently many motor vehicles have lighting that is quite sufficient to be easily daylight-visible but does not get dimmer at night, and thus is blinding to many others on the road, especially headlights, brake lights, and turn signals. Under most conditions, that kind of lighting does not seem to be necessary for safe road use, but instead actually makes it less safe, as others may miss dimmer lighting or unlit vehicles, bikes, or pedestrians (or road obstructions, potholes, debris, etc) from the eyes' reaction to the overbright lighting pointed at them.


Throttle controll of the motor should be accomplished in two ways, the first of which is most preferable for normal operation, but the second can override.

Main control would be sensing the amount of torque generated by the rider and attempt to drive the wheels such that this is reduced to a preset (by the rider) level, so the rider never has to input more than a certain amount of power to get the speed desired, and never has to deal with a throttle control manually, either. Sensing chain tension is one easy way to do this, with a spring-tensioned roller on top of the chain pivoting up as the pedals are pushed harder (not faster), and moving a magnet into proximity of a Hall effect sensor that is attached to the main throttle input of the overall controller. That is passed thru the OC to the motor controller (MC) as either raw or processed signal, depending on whether or not there is a secondary throttle and whether performance tweaks are set by the rider. A potentiometer could also be used, but is less likely to be easily made weatherproof or mechanically isolated from vibration/shock/etc. The harder the rider pedals, the more deflection of the pivot, and thus the more throttle input to the controller to provide more power to the motor. As the rider eases off the pedals, the motor gets less power, and none at all if the rider does not pedal hard enough to pass the preset level.

Secondary control would be a standard grip or thumb throttle (as the rider chooses), connected to the seondary throttle input on the OC. The OC will read that and if it exceeds the input level from the main throttle, it will send the secondary control values instead of the main ones, until the level drops below the main throttle's level.

If wheel speed exceeds 20MPH, the motor will be cut back until it is at 20MPH, or shut off if speed continues to exceed that speed. 20MPH is the limit for electric-assisted bikes in most places in the USA that have limits for them. For places that either have no limit or have a lower or higher one, this value is alterable in the configuration pages of the OC, along with many other things.

If wheel speeds are significantly different, ever, for more than a tenth of a second, the motor will be shut off until they are the same again. This is because in some conditions, like muddy roads, the motorized wheel will spin MUCH faster than the non-motorized one, and all traction for that wheel can be lost, as well as vehicle control. Sometimes the motorized wheel will not be the same as the pedal-powered wheel, depending on bike configuration. Sometimes it may be the steering wheel, and sometimes not. This is a critical safety item, as I have personally experienced a crash that would not have happened if I had such a cutoff, and I would have been able to regain control to avoid even much of a skid.


MEMS Tilt-sense will help avoid serious injuries from wheels that continue to spin even after a crash, and may also prevent certain types of crashes. If the bike tilts past 60° from upright the motor will have all power cut, and if past 80° it will actively brake the motor, if the motor and it's controller can do so (some are designed to, some not).

If it is possible to determine a good default range for this, there will also be a function that detects the tilt of the bike vs the speed it is going at and the radius of the turn it is making, and reduce or cut motor power if it is beyond the limit preset as "safe" for that combination, so that unrecoverable skids during a turn (very dangerous, especially in traffic) are less likely to occur. An audible warning to the rider should also happen once they begin to reach the preset limits, so they can reduce speed themselves first instead of having it done for them.

If the manual throttle is reduced to zero and then run back up to the desired level ("gunning" the motor) after it has been disengaged for any reason, it will restart and continue running, in case there was a very good reason for the rider to maneuver like this (unlikely, but just in case...). The same may be made possible with the pedal throttle as well, but this would not be enabled by default, as messing with the leg positions and whatnot in such a turn when already potentially about to spill and skid could easily tip the balance and cause the crash the rider was trying to avoid.


Customizing the settings can be done either via the menus in the OC, or by docking the OC to a PC via USB and uploading a configuration created in a yet-to-be-conceived GUI program that will show the rider all configurable items, and both show (with tooltips or other labelling) what exactly the setting is for, and what the default is. All settings can be saved to a file, and then uploaded wholesale into the OC. All settings in the OC can be loaded into the program, and then saved to a file, or simply edited and then reuploaded to the OC.


The lighting system should have it's own separate battery from the motor, since the motor can easily and quickly discharge smaller packs depending on the rider's use of it, but the lighting needs to keep working even if the motor does not. At least 6Ah worth of power is recommended, at 12V, to give a multi-hour runtime. Exact amount of lighting power needed depends on the actual lighting used.

LED is strongly recommended for everything including headlight, as it is less likley to be damaged by crashes or weather, and is more likely to be less power hungry than other light sources for the same illumination. It is also more directional, and there are LEDs with integrated optics allowing elliptical fields-of-view, excellent for road use as less power is wasted shining light up or down and more used for sideways scattering to make the system more visible where it needs to be, without having to custom-design lens covers for the assemblies that do this for other lighting types.

There is much more detail than this to the system, but this is the very basic parts of it. More detailed info exists in the previous posts.

User avatar
kishore.srimat
 
Posts: 1
Joined: Fri Dec 18, 2009 1:36 pm

Re: Electric Bike motor, lights, safety features conversion kit

Post by kishore.srimat »

Hi Amberwolf,

I have read your post. I have done quite a bit of work with STM32. I am trying to play little bit with motor control now a days and trying to do some kind of helicopter motor. I mean toy helicopter :)

I definitely could help you in software point of you in getting together your bike with STM32. By the way , I am working in ST,phoenix as an Engineer working on STM32.

Let me know if you need any help with motor control with any project, I would be glad to assist you and we can learn together.

Cheers
Kishore

User avatar
amberwolf
 
Posts: 310
Joined: Wed Oct 08, 2008 2:42 am

Re: Electric Bike motor, lights, safety features conversion kit

Post by amberwolf »

Thanks! I could certainly use the help, so I emailed you. :)

Locked
Forum rules
Get help, and assist others in with open source kits and running a business! Do not ask for legal advice or for consulting services in this forum, only general biz questions!

Return to “Kitbiz”