Commuter Booster - <1kg Friction Drive

Sounds like the "Brain Box" development is going really well. The Arduinio is a great platform to work with that's for sure. I will be interested to see what path you take in relation to locking the device down. This has been a real issue for me too which is why open source was the original approach we were going to take. However it just ended up having to much time, effort and money invested into the code to go this way.

There are many obvious advantages of keep the device as simple as possible. The complexity of my interface is certainly one of the key reasons why its taking so long to get it out on the market. Also locking it down is another big problem that still needs more work.

Any clues on how you are going to work your button logic or is this still a closely guarded secret? :) I know you aren't too keen on speed match logic I am using.
 
Your tales were one of the reasons I was nervous releasing my "Brain Box" design. So until I understand the pros/cons better I'll keep it inhouse. In order to lock it down I may drop back to a non-Arduino but still ATMEL AVR.

I hope to keep the same design philosophy for the "Brain Box" I was following for the Commuter Booster, trying to strip the design/features back to the bare essentials. Hopefully this will also help in differentiation between our offerings.

As for the throttle button logic, nothing is set in stone. I have my preferences, but I am sure this wont suit everyone. I think this is dependent on the style of riding you do, and the power level of the drive. I have quite a few options in my head, but have not road tested them yet. In the end I will probably try and stick (as always) with the simplest solution.

One of the options I am unlikely to pursue has a 5way button on the dropbars. (Got the nice weather proof buttons already made) You would love it! Heaps of options to explore you could have on the fly adjustment of current, speed, cruise, throttle response rates, PID parameters. Shall I drop it around with a list of elaborate implementations to help distract you. :lol:

BTW did you get your PCBs made and loaded by an external supplier, or are you populating them inhouse?

- Adrian
 
At this stage, the boards are populated in house. My associate is fairly well geared up for small production runs and has tools such as solder baths, component oven, and an industrial stereoscopic Microscope for board inspection.

The multi button sounds interesting. Is this a commercial multi button set-up or something you custom built?
 
They are not a custom design, but similar in manufacturing processes that I will probably pursue, which is why I bought it. I have the buttons if you are really interested, it even has a pretty back light so you can find it in the dark. But I was joking when I suggested them to you.
10411-05_i_ma.jpg


Just to distract you further, I was looking at 2 axis sliding joysticks. Pretty cool, but not exactly waterproof. Imagine what you could do with that! Time to re-write your code for another throttle input style. :lol:
09426-01_i_ma.jpg
 
adrian_sm said:
... In order to lock it down I may drop back to a non-Arduino but still ATMEL AVR ...
Adrian, excuse the dumb question, but are saying that once the code is compiled, it is as easy as dot.NET to reverse engineer? Not that it makes any difference to me as I probably will release mine into the public domain (only if there's a need mind you), but I thought you would be marketing this as a package, and the end user would not have access to the source code?

GT
 
The issue is if I want to allow people to update the code for units they already have. Without sharing the whole code base.

Basically I know I don't know what I am doing, so better to wait until I have more of a clue. :lol:

Remember I am the programming newb here.

- Adrian
 
I installed the IDE after I last posted, and it appears to compile in memory and then upload to the Arduino. If this is the case, I can't see a way to avoid sharing the code base if you want users to update the code themselves. I'll do some more digging though, but I'm not hopeful. In case you're wondering how I write code without the IDE - text editor (300% quicker) :wink:
 
gtadmin said:
... I can't see a way to avoid sharing the code base if you want users to update the code themselves....


Thats why I thought I may have to revert to non-arduino. But I haven't put a lot of research or thought into it. I'll revisit it once the features has settled down. Then I will know what level of user configuration may be required. That is one of the advantages of going for a bells & whistles system, it makes it easier to reprogram once you have displays, external memory cards etc.
 
adrian_sm said:
... But I haven't put a lot of research or thought into it. I'll revisit it once the features has settled down ...
"com::transformers::supermangletron::Mangler" may help, but I can't find too much about it but it's interface (or signature) suggests it can "mangle" the code. Visual Studio has a similar tool, but that works on the intermediate code files generated by the compiler. Perhaps someone else could chime in, as I only have a couple hours at this so far.
 
My understanding is that its impossible to lock it down completely. If someone really wants the code, they can extract it. The best we can do is make it as difficult as possible.

We now split the code so that items that need to be adjusted are done in eprom with the base code residing in the main memory. Still doesn't mean some couldn't extract it, just means we only need to expose part of the code.

I am glad I dont need to figure this stuff out myself as I have zero programming experience. Allows me just to concentrate on mechanics.
 
Ah! See you are more wise than I. I have this delusion I can do everything myself. It has some advantages, but I am not sure if they outweigh the disadvantages.

:lol:
 
I'm loving how this is moving along. I had one thought for your brain box. If you are worried about people stealing the code and building their own brain box, don't build the box, have the customer build it. How hard would it be for you to make an e-book of the entire process with a list of parts and code. You could offer to have ready built units, kits or just the e-book. I'd drop 10 bucks on the e-book right now if I knew it was something that I could build and would save my ESC. It is the information age, you could make money in your sleep and have no real overhead or product inventory to deal with on an e-book. Of course some people are going to digitally steal stuff but I'm sure the majority of ES members would pay to support a fellow addict. Just a thought.

Carl
 
Adrian,

Good stuff! It should be interesting see how your interface works when it's all done. A couple of years ago I would have never thought we would see this much work going in to friction drive designs. It's fun to watch.

Are you still planning on using the Delrin clamps on your production models? We may have discussed this before but I do quite a bit of work with Delrin. From everything I've read it appears that it degrades rather quickly when exposed to uv. I would be a little concerned about using it outside long-term, especially for something structural on the drive.
 
Carl,
If you want to make your own "Brain Box" seriously it is not that hard. Get an Arduino board, spend a couple of hours researching how to activate the internal pull up resistors, do servo control, methods of doing rpm measurements, buy an off-the-shelf current sensor and you are most of the way there. I am not trying to stop people from making there own, but I have delusions of making this a larger scale product, and don't want to release the exact details until I am sure this want hurt my plans. Sorry.

Todd,
Thanks for leading the way mate. I am not sure if I would be dedicating so much of my time to this if I hadn't seen builds like yours and keplers.

As for the Acetal. The natural acetal doesn't like UV, the black grade I picked is okay. It was chosen based on not only it's strength, but also the easy of manufacture to suit the tools I have access to. I am still happy with it for the small batch production, but if/when I scale up, the material options and manufacturing methods open up. So don't be surprised if it changes significantly.

- Adrian
 
The temptation to keep the code to yourself is going to be strong. But I'd really urge you to think carefully about open sourcing the code and what that would mean. I haven't done the research, but I don't see any problem with the legality of selling a packaged hardware-software solution that is legal, but where enterprising individuals can re-program the brain box. Particularly with an Arduino based version, you can't really stop people doing that unless you pot the whole circuit board and bury the programming interface in plastic. You probably don't want to do this because I can guarantee that you'll want to enable software upgrades as you improve the software over time.

After all there are lots of commercial e-bikes that use the Infineon controllers. Quite a lot of these can hot-rodded and made illegal by simply disconnecting a wire. The programming code has leaked out and there's even an open source project to reverse engineer the program on ES.

Are you going to try and have a version that meets EU rules? That's 250w, 25Kmph max, Pedelec only (but with throttles allowed in some countries like the UK).

I'm still curious to find out if there's any way of measuring the motor rpm rather than the wheel rpm perhaps from an output on the ESC. That might give you finer control over current limits at low rpm and with a stall cut out to save the rider from hitting the power at 0mph. I suspect that the ideal for ESC safety would be a ramped current limit for the bottom 50% of the speed curve. So at 10% of max speed, you'd have a much more aggressive current limit than at 50%.
 
Just to be clear, I am not ruling out releasing the code or schematic for my little Arduino based brain box. But I will not do it until I am sure it won't stuff up my plans. Of course this is all about my delusion of scaling this up to a commercial product. I have decided to give it a go. So I need to starting being a little be more level headed about what I release.

A major part of those plans is to provide fairly complete drive kits ( including all the custom mechanical and electrical bit to just bolt together with off-the-shelf parts) that meet all legal restrictions for the various markets around the world, including the EU. People will just have to be a little patient with me while I work out the best way of acheiving this. But as you point out it is pretty easy for people to reprogram a XieChang controller, so what am I worried about. And you may have a point, but I don't want to rush into things.

As for using the motor RPM from the ESC, I wanted the brain box to plug and play with essentially any ESC. This really rules out tapping into anything on the ESC other than GND & 5V on the 3 wire servo connector. For people willing to play around, open up controller, decipher schematics, and do fine soldering it might be possible, but that is not what I am aiming for.

The bigger issue is that for my friciton drive the motor is totally disengaged from the wheel prior to the throttle being applied. So it has no knowledge of if the bike is standing still, or doing 40kph. Without more direct access to what the ESC does during start-up the only way I know of to protect it from large FET killing current spikes is to enforce a minimum speed. For now I am happy with just making the rider pedal first before allowing the drive to engage. If I start trying to get true start from a stand still performance I will have to take a different strategy. The alternative are to force the use of more expensive ESCs, go to an ebike style controller, or start getting fancy with writing my own ESC code which I am not to keen on right now. It wold be pretty cool in the future, but I think I will avoid it for now.

- Adrian
 
Sounds like a familiar dilemma :). Its funny, my associate who does all my programming was an idealist who was all for open sourcing the code on our interface. The argument was that we would have a whole community of programmers working together to create a universally better product. Didn't take long to figure out that there was going to be way too much time and effort invested in this project to just simply give the IP away. Its true, someone with the right skills could de compile and extract the code. We place a "Creative Commons" statement in our code and although this is not legally binding, it is a code of conduct that we would expect other ethically minded programmers to respect and adhere to.
 
No dilema for me. Yet. Just leaving my options open. :D
 
Life, both work & home, is very busy at the moment. No time for CB work. :(

But that will be changing soon. Expect things to accelerate in a couple of weeks or so. :D
 
For those of you wanting to make your own throttle interface/brain box, I just stumbled across a cheap easy to use arduino nano on dealextreme. This unit has the usb port, so you don't need the fancy FTDI cable for arduino programming, also has standard ICSP header. All for $20 delivered. Too easy.

http://www.dealextreme.com/p/arduino-nano-v3-0-81877
sku_81877_2_small.jpg
 
adrian_sm said:
For those of you wanting to make your own throttle interface/brain box, I just stumbled across a cheap easy to use arduino nano on dealextreme. This unit has the usb port, so you don't need the fancy FTDI cable for arduino programming, also has standard ICSP header. All for $20 delivered. Too easy.

http://www.dealextreme.com/p/arduino-nano-v3-0-81877
sku_81877_2_small.jpg

And when you have the prototyping finished you can switch it to a standalone atmega168 with a crystal and two capacitors. Cheap, simple and nice. You will need a voltage regulator that outputs a stable 3.3V-5V.

EDIT: To program a standalone atmega168 chip you need the standard arduino so you can put the empty uC in arduino.
 
Back
Top