(Well, the system is base on the moving auxiliary of the one servo for contact the motor with wheel. The system is opposed to accidental contact (iregular field) with the wheel motor and the servo motor movement limited and only turns the wheel to 20%. Once, touched the motor is caught by friction and the servo moves freely.The shock absorber applies to avoid breaking the servo.)

Interesting mechanism. I like how you just use the existing throttle signal to move the servo. But it looks like the servo will reduce the force it is holding the motor into the tire as it reaches 100%. I assume you are just relying on the motor/tire friction to keep them together. This might not be good at low speed, high load situations. As you want as much drive engagement with the tire as possible to transfer the high torque.

Thanks for posting.

To be honest I have never had an issue with the motor tire engagement on my drives (unless they are not installed correctly), but I use a button throttle interface that accurately controls the motor acceleration for the user, which in turn controls the way it lifts the motor and engages the tire. Maybe for a system with an analog twist type throttle, your concept could be useful for people that only slowly apply the throttle at start-up. But if it only engages at a certain percentage throttle then you may already have a mismatch in speed between motor and tire just prior to engagement, which is not good once they come in contact. But I my system is has no real control over the speed mismatch either... Hmmmmm. Interesting.

After a lot of testing, refinement, building, testing, refining, building, etc. I am now happy with my new throttle interface/ebike computer/datalogger/brain box.

I have settled on a schematic, nailed down one hardware varient, and finally crammed all the features I want into the firmware. I'll post up pictures in the coming week, and contacting the list of people that have put them names on the waiting list, and put up a thread in the for sale section. But here is a quick heads up.

Commuter Booster- Only minor changes have been made to the mechanical drive unit, based on alpha test units- specifically the main pivot shaft will now be a press fit into the swing arm

Pics and videos to come. Still awaiting the final parts for manufacture but have 95% of them, and design is now finally finalised. Woo hoo.

I am really excited about this, because it makes my drive a much more refined and complete package. I will likely offer fully assembled kits with ESC and motor if people are interested. Just leaving you to supply and plug in your own battery. Doesn't get much easier than that.

Scope creep got to me a bit. If I had not implement all the data logging stuff, this would have been so much quicker. And I suspect most people won't use the feature, except the ebike stats nerds. But since a normal microSD card will be big enough to capture 1sec data for thousands of rides, it could just be a nice black box for life analysis of bikes. Developing it all myself also allowed me to quickly iterate features, debug, etc. But now it is time for everyone else to join the fun and see what features/tweaks/changes others would like.

How's yours going? I noticed you are going with the CA-LRC on your beautiful new commuter, rather than your throttle interface. I expected to see it available by now.

I am getting a few through now but every time I get one or two, I end up selling them as part of a drive package so they are gone before i get to use one. Problem is that they are all hand made at the moment and we are still adding features so we don't want to tie our selves down to a run just yet. Also funds are a little tight to do a manufacturing run at the moment. The version we are working on at the moment has wheel speed and motor speed sensing so we can accurately match engagement and keep slip down to an absolute minimum. In other words the dreaded "design creap" is kick our butts again. Hopefully this will be the last major addition for a while however Bluetooth comms is also on the development list so who knows.

The CA is a great pre packaged solution for us though and really suits installations where a traditional throttle is the preferred method of speed control. Also its such a neat professional package. Packaging the interface into a good quality water resistant box is still one of our biggest issues. I dare say you would be in same boat on this front.

Kepler wrote:In other words the dreaded "design creap" is kick our butts again. Hopefully this will be the last major addition for a while however Bluetooth comms is also on the development list so who knows.

Totally agree on the CA, and it looks like the new version Justin has in the works is going to narrow the margin between his and mine in terms of feature set. But for a button throttle mine will most definitely win out. I even prefer it for flat bar bikes.

Yep water resistance packaging has been fun. Hence the 10+ physical variants I have built. All identical schematic, but just trying out moving components around, different enclosures, different mounting points, etc etc. Finally happy with my solution now, adaptable in mount options, suit front or back wheel sensor, easy to remove battery, or stealth builds. Ended up using off-the-shelf enclosures with some minor modes. They won't take a high pressure hose (neither does a CA), but will be fine in rain. So it all looks pretty, and protects things, while still giving relative easy access to microSD, USB, or for adding sensors etc.

Mine is still hand built for all the termination and enclosure modes, but uses others mirocontroller/SD/sensor boards. I won't try and roll my own unless I get volumes to justify a custom board. So I won't be making any money back to on these, as they take a bit of time to make still.

Adriam, the servo don´t reduce the force it is holding the motor into the tire as it reaches 100%. I shall think use for road bad or for mountabikes (pothole), because in my case it exist contact the motor with tire on surfice irregurar

I needed to look at ermoustruo's drawings a few times to work out how it operated. Basically the servo will help engagement with a small amount of throttle applied. From there on the motor can climb tire and the servo position wont have any effect on how the swing arm moves.

I experimented with a similar strategy but used programming logic to jog the servo. It worked but I came to the realization that the extra complication just wasn't necessary. Smart design by ermoustruo though.

Okay spent a chunk of today getting a few videos together to help those not familiar with the Commuter Booster.

They run through from building a battery, assembling the Commuter Booster, all the various parts of a system, installation, tuning, the new Brain Box ebike computer/throttle interface/datalogger, and a general walk around.

Here you go. I'll put these in a new 4 sale thread soon. I promise.

- Adrian

P.S. Apologies for the quality, these were just "first take" videos using my phone.

Thanks for the kind words Matt. I appreciate it, I have always been a huge fan of the quality and performance of your creations. They are truely an inspiration.

Yeah. The friction drives are definitely not for everyone. But I am still amazed at the performance you can get out of such a small package, while still keeping your bike a bike. They are a totally different beast to a typical hub motor bike. My big old full suspension hub motor bikes is starting to feel pretty neglected.

Now that the development side of the Commuter Booster has settled down to a point that I am happy with the mechanical and electronics sides, I am starting to think what my dual suspension bike would be like with a big outrunner, and a chain/belt reduction..... Shaving some weight off my 30kg beast, getting a performance hit, and being able to pedal without feeling like I am on a beach would be awesome. But I think this one will just be a one off for me. It takes way too much time to make something suit a bigger audience.

To be honest I have not spent a lot of time tuning it for 200w, and from initial testing I was not happy with how it performed.

The Long Answer:The problem was that at this low a power level when the rider pedals, they are providing a similar amount of power as the motor. So the control loop needs to react quickly as the RC ESCs are actually more speed controllers, rather than power controllers, as they just set the PWM of the phase current.I may need to change the way the PID loops works to make it to my satisfaction. I have all the code implemented to be able to adjust PID parameters on the fly if necessary, the loop is evaluate in the 20-30ms range, but I just haven't got around to tuning it yet. This may take the form of on set of PID parameters during initial engagement, then switching to a different set.

One last things against the modest power limits with this drive, is that at low power levels the drive is more likely to disengage from the tire when you hit bumps on the road. I have never really noticed this in the past as I was typically riding at 500-1000w, and had a no load speed well above my cruising speeds. But today I went for a long test ride with a new motor that is a lower speed and smaller diameter than I have used in the past. At the end of the ride with battery voltage lower, then no load speed was now closer to my cruising speeds on the flat. Meaning that the motors BEMF was reducing the power to a level that was not keeping the drive engaged. Hence my concern.

This taught me that motor selection needs to be based on ensuring that the motors no load speed at the pack minimum voltage needs to be greater than the maximum assist speed for the bike. The simple solution for me was to just use a 6s pack for this motor, rather than the 5s pack.

The Short Answer:So, will it work with 200w? Yes. Is it optimsied for this yet? No. Am I very interested in optimising it for 200w? Yes.Will I updated the brainbox to suit 200w limits in the future? Yes.Would I appreciate some help in optimising it? Sure.Do you need to raise the minimum speed? No.

The BrainBox measures the battery current & voltage. Calculates the power, then uses this in a PID loop to set the throttle signal to the ESC.The enforced power limits are way lower than what the motors are able to deliver unrestricted.

As for an engage switch. If I had to go to that level of complexity, I think this whole drive is a failure. It would definitely work, but the beauty of the system is how easily it is to engage.disengage and still ahve th bike feel like a normal bike. It only is worthwhile if it is simple and just works. Not if it turns into some complex system. Then you would just be better off going and buying a hub motor for your bike, and putting up with the weight and efficiency hit.

It will take a bit of time to get it working for low power, I just haven't got around to it yet. As I wanted to get the BrainBox hardware & first release of the software out for those interested in a higher power system.

Good news. I just came back form a few test rides with the Commuter Booster on low power setting, and it all worked perfectly.

After posting my previous response above about how I wasn't happy with how the drive worked at low power settings, I realised I have change a lot since I did those tests. So I thought I should give it a go. Mainly I have tweaked the PID loops a lot. So it adaptively modifies the PID parameters to suit the power limit you set. This was initially done to give similar engagement for higher power settings, but also has improved things for low power setups too. I think last time I tested it I actually set 200w battery side, and had my PID control too slow to respond. With the new PID settings, and a more realistic battery side power limit set, it all seems good.

I set the lower power limit @ 300w. Remember this is the battery side power, not the output power.The no load power for the motor depends on which motor you have. I was using the orange Turnigy 6374-200kv, which cold uses ~60w at full throttle, no load. Add another ~10w to keep the wheel spinning @ 50kph, then there are some additional losses when the drive is under load due to the rolling resistance of motor&tire contact, at low power levels this maybe around ~30w. (this really depends on a lot of things so can vary a lot)

Anyway @300w battery side, we should be seeing between ~250w on the road.

Now obviously this is not as exciting to ride compared to 500 or 1000w, but did give a gentle assist helping me maintain a good cruising speed, and make the hills feel a little flatter.

Frankly I was quite surprised. I am sure we test it more we will find some more quirks, that may require tweaking things a bit, but it looks quite promising. Thankfully.

First of all I want to congratulate on the idea and turning it into an actual product

I am really looking forward to buying it but before that I want to dissolve some uncertainities:1. Will I work properly with ZIPPY Flightmax 8000mAh 6S1P 30C ( http://www.hobbyking.com/hobbyking/store/__16228__ZIPPY_Flightmax_8000mAh_6S1P_30C_.html ) ? I want to keep the size to absolute minimum while still having capacity for week of short commutes with a little uphill boost2. Does the BrainBox track motor temperature (I believe thats where the temp sensors goes) and prevent it from overheating?3. What is the size (dimensions) of BrainBoxs 2nd part (the one without screen) ?4. What motors are recommended for the smaller (50mm) swing arm version of CommuterBooster?5. My greatest concern is overheating, so is it anyhow possible to attach a fan to the motor?

2. Does the BrainBox track motor temperature (I believe thats where the temp sensors goes) and prevent it from overheating?

The brainbox currently has one temperature input (and expansion capabilities for more in the future).It is up to the user to decide where they would like the temp sensor installed, but I only ever put it in the windings of the motor.Current firmware only displays the temp, but it is possible to implement reducing the power based on the measured temp, just have not implemented it. If I was to implement it I would likely remove the datalogging feature, as I don't believe most people really need it, and it takes up half of the available programming memory.

3. What is the size (dimensions) of BrainBoxs 2nd part (the one without screen) ?

It uses the same size enclosure as the lcd/head unit (57x38x20mm).

4. What motors are recommended for the smaller (50mm) swing arm version of CommuterBooster?

I don't have a specific recommended 50mm motor, as all of the development effort has been on the 63mm motor.But about 270kv is about right.If you can find one with a skirt bearing it will suit high torque loads better.Then I would just find one that weighs the most. This means it is likely to have the most copper, and surface area to handle the waste heat. As this is the biggest issue with the little motor. The little motors will be limited as to how much continuous torque they will be able to handle without over heating.

In fact that is likely the next feature I will implement in the firmware, a maximum torque limit. This has a couple of advantageous. It will allow me to limit the waste heat, without limiting the maximum power at higher speeds. It could also be used to reduce the loads on motor bearings, and tire wear at low speed, high power scenarios. Of course it can just be effectively disabled by letting it to a high enough number the limit doesn't get enforced, like the max speed at the moment.

5. My greatest concern is overheating, so is it anyhow possible to attach a fan to the motor?

Yes. Others have done this already, but I haven't bothered. I have been really happy with the performance of the 63mm motor with 500-1000w limits. Without any overheating issues. If you are worried about overheating, do not go for the smaller motor. You may save 300-400g but will have half the available power, and be much more likely to overheat.

Some of the motors are now coming with internal fans like the SK3's with skirt bearings. The external fans I have seen people mount are I think replacement fans from ducted fans. I think this is the link to one that has been used on a 63mm motor. http://www.hobbyking.com/hobbyking/stor ... oduct=4846But this creates exposed blades spinning at very high rpm, so is not something I would recommend, but apparently it has worked at keeping temps in check.

I am currently taking a break and spending time with the family and should be making all the orders I have received next week.

I had a email recently asking about ways to improve wet weather traction of the friction drive, suggesting using tire material on the motor, creating a tire/tire contact. I ended up writing a wordy respsonse that includes some theories on what the wet weather issues are, and potential solutions. I thought others may ahve some opinions so I will post it here:

This is probably a better conversation to have on a thread on ES, but here goes for the theory of what options we may have.

The issue with wet conditions is that as the tire rolls through the water, the water is pulled up off the road and remains in contact with the tire. By the time the tire has rotated around to where the friction roller comes in contact with the tire, the water has created a peak by the centrifugal forces. This water is then rolled over by the friction roller. We then expect the water to be squeezed out off this contact region. If enough water is squeezed out then there is enough contact area between motor and tire to sustain the required shear stress to transfer the drive torque.

With a smooth roller, and slick road tires the water ends up just forming a boundary layer and we lose traction very quickly. (In fact this is how bearings pull oil in to the contact region between ball/roller and the inner/outer races to provide lubrication and reduce wear.) With a rough roller, and slick road tire, the water has some valleys and cracks to hide in, while the peaks are able to break through the water to touch the tire and transfer the drive torque.

So option 1 would be to change the tire to something with some tread, to give valleys for the water. But if the roller is still smooth you end up relying on having a quite defined sharp edge to the grip tread. (Just ask the formula 1 guys how important a sharp edge on their tread is for wet weather grip). This sharp edge allows the water to be pinched out when the edge first comes in contact with the roller (or road), and can ensure you get contact direct from tire to roller/road. But during normal dry use this edge is quickly lost, and a friction drive is likely to wear it out too. But it would definitely be better than slicks.

Option 2 would be to use the rough roller. But this has the downside of having higher tire wear during normal operation. Lets explore why that is. Well it turns out that for the flexible tire to conform to the rigid roller, the tire does actually shear across the roller surface slightly, as the convex tire surface get pushed into concave, and the tire bulges sideways in the process. Now with a smooth roller the coefficient of friction between roller and tire is too low to exceed the shear strength of the tire rubber, so it just slides across the can. But with a rough roller the shear force can exceed the shear strength of the rubber, leading to wear. So what can we do to avoid this. (a) change tire material, - perhaps a compound that can sustain greater shear before failing(b) change tire profile geometry, - by change to a tire with a flatter profile, the tire deforms less when conforming to the roller, thus reduce shear stresses, and wear(c) change to a tire with tread that has tread blocks small enough to "sway" instead of locally shearing the rubber. This would also give space for water to escape. But small tread blocks will not be supported by the rest of the tire jacket like slick, so they will need to sustain more shear forces through the whole block.

Option 3 you suggested was a more compliant drive roller. This compliance could share some of the conformance, and shear loads. Therefore reducing the forces that can wear the tire. But for wet conditions we still need to stop a water boundary layer from forming. So we need to give the water somewhere to go, get rid of it before it reaches the drive, and have surfaces that come in contact that can help stop a boundary layer from forming, like sharp edges. The rubber on rubber contact may have a better coefficient of friction in dry conditions, but unless we stops the water separating the drive and driven surfaces, it won't work in the wet.

Personally I would put my research efforts towards a tire with tread first, and then second a rough roller of some sort that helps pinch through water to ensure contact. Pick some tire treads that give water somewhere to run, a flatter profile, perhaps small blocks not too high, and tightly spaced not an off road knobbly. Not to sure about the small blocks theory, as the blocks will tend to sway, leading to uneven wear...

The other thing we can do is reduce the drive torque when in the wet. Not ideal I know, as this me less assist. But I am in the process of adding a max torque limit to the software of the brain box which could easily do this.

Actually I might go do a bit of a search now and see what I can find.

Please note this is mostly theory at the moment, I have been considering this as a fair weather drive personally, and haven't done a lot of testing in the wet. As most of my electronics during development has not been water proof, so I have generally not taken the bike out in the rain.

If/when I test this I will probably try a combinations of:- few different tires, - motor with and without grip tape, - in the wet, - possibly with different maximum torque setup, to ensure I have the same torque when I go through puddles independent of speed.

Then see what I learn.

A more novel approach would be to install an air blade (think dyson hand dryer) that blasts a thin high velocity jet of air at the tire jsut before the contact with the motor, to displace the water.

What a plausible explanation for tire slip during the wet, and an even better theoretical solution with blowing the of air across the tire before contact.

I'm amazed at how much thought you've put into this subject. Could brushes installed in a mud guard disperse water away from tire to the sides? Or a deflector before the water gets to the point of falling within the guard?

Limiting the torque of the motor in conjunction with water dispersion may just be the solution to wet weather commuter boosting - sorry, I couldn't help it