Some assorted thoughts today

The two biggest things I want to achieve with this bike are simplicity of mechanical efficiency and low-cost.

The low cost I can do a lot of by using recycled parts wherever possible, since this is not a commercial venture but rather a personal transportation. :-) It'd be nice to make a saleable product, but I doubt anyone would want to ride something as ungainly as this.

The simplicity part of the first requirement is hardest to stick to, because every feature I add could double or more the complexity. The efficiency part for the current design is going to require some sort of feedback loop control via either hardware or software, taking a setpoint for speed and comparing it to actual wheel speed vs motor speed/current draw, and shifting the derailer gears automatically to maintain the lowest current draw possible for a given speed, but with the least amount of mechanical chatter switching back and forth. This feedback control loop is looking to be the most difficult part of this entire design, as I have not yet even found my starting places for it yet.

I am just about certain doing it in software would be far easier than hardware, because changing parameters for different sets of parts (like different motors) would be a whole lot easier that way. The catch is that I don't have the programming knowledge (especially with microcontrollers (uC)) to do this, and getting it right is a non-trivial task.

I would need to design the actual output hardware (power switching amplifiers, etc) first, to meet the current and voltage requirements, with certain safety cutoffs hardwired in to prevent a stupid bug from frying everything, then deciding which of several existing microcontroller (uC) boards to use (since developing one of *those* is out of my league, right now). The catch is that all the uCs are expensive. The programmers for them equally or more so. *And* I'd have to write the software from scratch, as I don't know any well-documented open source stuff available to do this sort of thing that I could use as an example. I have ideas on how to block it out, but not yet to actually write it.


I'd want a uC I could program via USB, preferably. Serial is ok, too, and very common, but many computers nowadays do not have serial ports, especially laptops! Mine does not have one (preventing me from using my drawing tablet on it, amongst other things, since the serial-to-USB adapters so far tried do not work for it). Thus, if I had a programmer that was only software in the computer, for a uC that interfaced via USB (or serial), the cost for the programmer would be theoretically nothing, because the controller developer has no hardware cost associated with the programmer to sell to users, only the software cost that hopefully is amortized into the cost of the actual uC, and then the whole thing would be pretty cheap to buy for my low-volume (i.e.: ONE uC) application. Also, if the programmer software has a simulation function, I could use that to give various input conditions to check for fatal flaw conditions of output (though I don't yet know what those would be). I have not yet looked to see how many uCs are actually made this way now, but any that are would be in consideration for this project.


I've also looked at simply buying an existing PWM controller, either software based or not, especially those from 4QD. Richard there is an *invaluable* help to me, and I wanted to be sure to credit him and his excellent technical resource site for basically providing me with the start and much of the rest of my knowledge of PWM controllers, as well as many other design considerations for other aspects of this project that I did not know where to start from, until I found 4QD. Even this entire blog entry is a result of a discussion with him, which I had not formulated into words until then.