Commuter Booster - <1kg Friction Drive

[gtadmin]

Update: Brain Box

Here is the update on my throttle interface, or as I like to call it the Brain Box. It is based on Arduino so I can get hardware off the shelf, and speed up development. Later on who knows.

So finally got the bits on Friday, only had a couple of hours to play with them yet, but managed to get the following working:
- wheel sensor (using an interrupt)
- button throttle input (digital)
- battery current sensor (analog)
- battery voltage sensor (analog)
- basic PWM out for the throttle out to ESC (PWM)

This gives me most of the building blocks I need. Now I "just" have to get all the logic working. So far I am really happy with it. It looks like it will be able to do everything I want, and has been really quick and easy to get things working.

- Adrian

[sternvoice] Is this part of the CB80 implementation plan? If not, stop pissing around and get on with the important stuff [/sternvoice]

Top stuff Adrian, it's getting closer. Are there going to be (user) adjustable set points, or will it have presets for the different motor sizes, or doesn't it matter? If the wheel sensor was to work off the chainrings (ie no pedal, no assist), it'll almost be legal , or do you want an absolute speed reading before assist?

Cheers,
GT

 

[Tiverion]

I've been following this thread quite closely and I get the distinct impression that a lot of posters have got the wrong idea about current limiting. I found an FAQ on the Castle Creations support site that should clarify a lot of things.

http://www.castlecreations.com/support/faq/faq-general.html#gen6

The important one is question 6 at the bottom of the page.

--
Bill

 

[jbond]

No plan on phase current limiting. The current sensor I selected is not suited to this task, and I don't understand the value of doing it. What is the advantage?

As I understand it, two things break controller FETs. Too much current at 100% PWM, and current spikes at low rpm, mid-throttle, mid-PWM. Low rpm means there's not enough back EMF to limit the voltage, and even if battery current is limited, the peak current during the PWM on phase can be too much for the FETs. I think that's the reason for checking and limiting the phase current during these peaks. The problem is that actually measuring the peak is difficult due to the short duration and high values. So Infineon controllers take a guess at it based on rpm and PWM% and average battery current. People setting up the controllers then take a guess at what's an acceptable maximum value, typically 2.5* battery current. So if you have a 20A limit, you'd set a 50A phase limit, which is guessing at anything less than 40% PWM when the peak phase current is at it's maximum.

 

[adrian_sm]

Top stuff Adrian, it's getting closer. Are there going to be (user) adjustable set points, or will it have presets for the different motor sizes, or doesn't it matter? If the wheel sensor was to work off the chainrings (ie no pedal, no assist), it'll almost be legal , or do you want an absolute speed reading before assist?

Depends. I can do both. For initial testing I'll have user adjustable limits, in the future I may have to lock it down to set power limits to meet legal restricitons in different markets.

The idea is to be able to make it legal for all markets. So it will have a crank sensor option later. But I also need an absolute speed reading before assist to allow cheaper sensorless ESC to survive. Otherwise I would have to spec better ESCs, or go for bulkier ebike type controllers, like a 6fet "infineon".

I've been following this thread quite closely and I get the distinct impression that a lot of posters have got the wrong idea about current limiting. I found an FAQ on the Castle Creations support site that should clarify a lot of things.

http://www.castlecreations.com/support/faq/faq-general.html#gen6

The important one is question 6 at the bottom of the page.

--
Bill

Thanks Bill. So the fets must be able to survive the max current the motor can draw plus some, then it is a mater of longer term heat effects due to switching losses. By enforcing a minimum speed I allow the back EMF to help limit current. But by limiting current (via my brain box closed loop control reducing PWM) I make life harder on the ESC, but easier on the motor.

As I understand it, two things break controller FETs. Too much current at 100% PWM, and current spikes at low rpm, mid-throttle, mid-PWM. Low rpm means there's not enough back EMF to limit the voltage, and even if battery current is limited, the peak current during the PWM on phase can be too much for the FETs. I think that's the reason for checking and limiting the phase current during these peaks. The problem is that actually measuring the peak is difficult due to the short duration and high values. So Infineon controllers take a guess at it based on rpm and PWM% and average battery current. People setting up the controllers then take a guess at what's an acceptable maximum value, typically 2.5* battery current. So if you have a 20A limit, you'd set a 50A phase limit, which is guessing at anything less than 40% PWM when the peak phase current is at it's maximum.

So for true phase limiting to work it would have to be quick enough to actually catch a current spike before it exceeds your limit. Otherwise you are guesstimating like most ebike controllers. The way I see it I wouldn't be able to implement the phase current limiting, without more direct control over the ESC PWM, as I am limited by the normally servo signal input. This would push it into real ESC developement. Not something I am capable of at the moment. Especially if the only advantage is being able to engage the drive without pedalling first. You would be better off just going for a CC HV-160 or an ebike controller. Remember the Commuter Booster is target at low power systems. I'll leave the high power systems to others.

[sternvoice] Is this part of the CB80 implementation plan? If not, stop pissing around and get on with the important stuff [/sternvoice]

Well maybe I'll have a quick dabble with a high power system... :lol:

I have the mount all made, but am just waiting on full-throttle modifying the controller for my voltage. I told him there was no hurry as I have a lot of other things on my plate at the moment.

- Adrian

 

[gtadmin]

... So it will have a crank sensor option later. But I also need an absolute speed reading before assist to allow cheaper sensorless ESC to survive. Otherwise I would have to spec better ESCs, or go for bulkier ebike type controllers, like a 6fet "infineon"...

Crank sensor, even just a pulse type, is only another input into the uC so should be relatively easy to implement (once the other functions are sorted - speaking with my programmer's hat on here).

Sensored "infineon" introduces extra bulk and an onus on the end user to add halls to the motor - if they're capable of that they probably won't want FD. However, the SX3 may 1] be marketing hype; 2] be a better quality SX; or 3] be a better quality SX sensored. That would change the game eh 8)

Sensorless "infineon": would it be an any better solution than what you are working on?

 

[adrian_sm]

SX???? SX3?????? You have lost me.

Sensored would only be a solution if I had someone making custom motors for me with sensors. All to hard for joe consmer otherwise. And i cant be bothered.

Unfortunately the sensorless infineons have not been up to the task based on someone elses intial testing. They had some intermittent stutter issues.

 

[Miles]

SX???? SX3?????? You have lost me.

Maybe this?

SK motors to be replaced by SK3 Series 29/05/2011
Customers may have noticed that HobbyKing is low on SK motors right now. Thats because we're about to launch the next generation of SK's, the SK3. The SK3 represents a huge leap forward in performance and price with a serious step up in efficiency and quality over the original SK series.
The SK3 should be in stock in several weeks and we will be announcing more news closer to the date.

 

[gtadmin]

Yes, sorry (bloody memory; I need some extra RAM).

 

[kevo]

Adrian,
This is probably on your list of desirable features, but deserves repeating. Hope you can add a thermal sensor input to keep the 6374 from overheating. For places that have few speed/watt limits and lots of hills this seems desirable.
Thanks for all the great work,
Kevin

 

[adrian_sm]

Temp sensor is on the list. But will not make the first revision.

Update: Commuter Booster - Brain Box
Arduino rocks. I can't believe how quickly, and trouble free things are falling together.
I now have the interface all wired up controlling the motor, streaming instantaneous Volts, Amps, and Power readings to a terminal.
Wheel sensor interrupt works nicely.

I love it when things go right for a change.

 

[Wheazel]

Oh the arduino minipro
I use the same for multirotor heli applications.
Good stuff! Interesting to see where this one leads.

 

[gtadmin]

...Update: Commuter Booster - Brain Box
Arduino rocks. I can't believe how quickly, and trouble free things are falling together.
I now have the interface all wired up controlling the motor, streaming instantaneous Volts, Amps, and Power readings to a terminal.
Wheel sensor interrupt works nicely.

I love it when things go right for a change ...

I know how that feels :wink: (post double-checked to ensure there are no SX today )

Brain Box
1. The Arduino replaces the ramp control hardware (servo speed regulator) and the servo tester, feeding the output into the ESC
2. Instead of a twist throttle, you use a push button
3. Along with some other inputs, like the speed sensor, this controls the throttle output into the ESC
4. Other outputs are to some kind of LED display, possibly the watt meter

Is this how the interface works? It may appear that I'm a bit unclear on this, so could you post a block diagram (at some stage) with part # please? What is clear to me is that you are happy with it

I had a look at the code samples on the Arduino website, and other than the commands that are hardware specific, it looks just like C# (which is really cool, because I've spent the last 7 years writing C# code in my day job). If it's not restricted and you don't mind, could you please post your code (beta is fine, just want to have a look at uC code)

Is there much refining to do now before you are comfortable in releasing a beta version of the CB?

A lot of questions, sorry for that. Great advancement 8) BTW

Cheers,
GT

 

[adrian_sm]

I have no idea what the final feature set will be, but I am aiming for this to be the only thing you need between your throttle (button, hall or pot), battery and ESC.
First revision will definitely NOT have any bells or whistles like displays, just raw basic functionality.

The purpose of the Brain Box is to make it dead simple to get the electronics hooked up, and ensure the Commuter Booster behaves itself. But the bigger picture is to be able to make the drive legal for various markets around the world. So it needs to limit power, be able to do PAS, and limit max assist speed etc. And here is the kicker .... I am not allowed to make it too easy to over-ride the restrictions. So until I really understand what this means, I am going to have to keep the code and schematics to myself.

But given your coding background, it really should be a piece of cake to get something similar working. :wink:

Sorry for being all secret squirrel about this. But I don't want to shoot myself in the foot on this one.

 

[gtadmin]

I have no idea what the final feature set will be, but I am aiming for this to be the only thing you need between your throttle (button, hall or pot), battery and ESC.
First revision will definitely NOT have any bells or whistles like displays, just raw basic functionality.

The purpose of the Brain Box is to make it dead simple to get the electronics hooked up, and ensure the Commuter Booster behaves itself. But the bigger picture is to be able to make the drive legal for various markets around the world. So it needs to limit power, be able to do PAS, and limit max assist speed etc. And here is the kicker .... I am not allowed to make it too easy to over-ride the restrictions. So until I really understand what this means, I am going to have to keep the code and schematics to myself.

But given your coding background, it really should be a piece of cake to get something similar working. :wink:

Sorry for being all secret squirrel about this. But I don't want to shoot myself in the foot on this one.

At least I understood your aims then :lol: And no worries about the code. I'm thinking I just might need to buy one and have a play :lol:

 

[adrian_sm]

Do it! Do it! Do it! :lol:

 

[gtadmin]

Do it! Do it! Do it! :lol:

Ha! The hard part for me (as I have no "feel" for it) is the electronics ie what sensors to use, how to buffer them etc. The next hardest is wiring them, they're too small for me to see properly, even with a magnifying glass :x The code should be relatively easy, and I'll get a heads up by lurking on the Arduino forum :wink:

I'm wanting to use this to control my hubbie THIS time

 

[adrian_sm]

For the button throttle I connected a switch directly from ground to a digital input. Then initialized the internal pullup resistor.
For the wheel sensor I just used a cheap bike computer sensor, that appeared to use a reed switch. So wired it up in the same way, but to one of the inputs that allows you to set is an an interrupt.

Too easy.

Surely you can bribe someone to solder it up for you. I have always found beer a good currency.

 

[gtadmin]

For the button throttle I connected a switch directly from ground to a digital input. Then initialized the internal pullup resistor.
For the wheel sensor I just used a cheap bike computer sensor, that appeared to use a reed switch. So wired it up in the same way, but to one of the inputs that allows you to set is an an interrupt.

Too easy.

Surely you can bribe someone to solder it up for you. I have always found beer a good currency.

Thanks for the heads up, but "initialized the internal pullup resistor" :? Don't understand this, but also don't want to pollute your thread much more :lol: Beer: hmmm, I make a mean home brew to!

 

[adrian_sm]

Gotta make you do some homework yourself.
http://www.arduino.cc/playground/Main/ReadingRPM

I am too impatient for homebrew. Plus it's too friggin' cold in Victoria, you end up having to keep the brew warm. But mainly just too lazy.
I don't mind drinking others brews though. If they are decent. :lol: Beer does work as a currency on me. But single malt scotch will get you more.

 

[gtadmin]

Excellent! Thanks, I understand now. Onto more important things, I home brew and use a heat pad. After I have bottled (and I use coke bottles), I store them in a waterproof crate, fill it with warmish water, and drop a fish tank immersion heater into it. 4 days in winter, 2 in summer! woo hoo! I also home brew whiskey on special request (the cook) :lol:

Now back to normal programming ...

 

[adrian_sm]

 

[adrian_sm]

I have had quite a few people PM me asking about the "Brain Box" and possible access to my code and schematics etc. This has re-enforced the need for something like this for friction drives. But unfortunately I won't be able to make it all public. If I do get serious and want to sell this on a larger scale, I need to make sure it isn't too easy for people to overide the things that will make the drive legal in various parts of the world like power limit, max speed, pedal first etc.

So the options for now are:
1) Wait until I have debuged it, and got all the features working
2) Wait for Kepler to get his released
3) Take the ES DIY path and build your own
4) Take the ES "More Power is Always Better" stand point, and disregard minimum speeds, max powers limits and build a bare bones interface.

Here is my recommended bare bones interface.
- use a servo tester modified for the throttle of choice (button, hall, pot)
- add ramp control to smooth out engagement and disengagement, or
- use a soft start controller that softens the throttle response, something like this one

Obviously this won't give you power limiting, or minimum speed enforcement, but definitely makes the whole kit work very nicely. It is just not as idiot proof as it could be once I release the "Brain Box". I hope you all understand.

- Adrian

 

[adrian_sm]

Update: Brain Box

Code now does power limiting, pedal first, throttle ramp up & down, LVC. Basics are all there, just need time to get some serious road testing done. Damn day job keeps getting in the way. This unit has much quicker response times than my hacked Watt-Meter, so I don't foresee any major issues.

- Adrian

 

[gtadmin]

Update: Brain Box

Code now does power limiting, pedal first, throttle ramp up & down, LVC. Basics are all there, just need time to get some serious road testing done. Damn day job keeps getting in the way. This unit has much quicker response times than my hacked Watt-Meter, so I don't foresee any major issues.

- Adrian

Excellent Adrian, I wondered whether you were going to incorporate LVC 8) Is this user configurable (as in the user selects some switches or jumpers and that configures the uC on battery size:- 5S, 6S etc)? Is the current sensing on the battery, or on the motor phases (as per another thread in the Technical Area)?

I'm about 25% through my code (different use case) and already 3 pages I'll be using DIL switches to set all the user configuration so that I don't have to recompile for different options, with an external switch for "Limp" mode.

And you are so right about the day job, but we gotta eat

Cheers,
GT

 

[adrian_sm]

At the moment everything is hard-coded, while I got the functionality right.
Current sensing is on battery, not phase. This suits my needs.
LVC, I have started off with Auto, based on a 3.5V per cell.

My code has been really tight so far. The slow ramp up & down rates of my friction drives really helps with this.

Once I get the basics rock solid, the key decision then will be whether to lock down the adjustment, and features so I can get a custom board made. Or if I do the planning on future features, so the one hardware build can be expanded in the future. Not sure which path I will take yet. But I don't want scope creep to delay release of the first batch too much.

- Adrian