See Ben Heck's Motorized Wheelchair Episode -- Episode 48

Hi there Ben, I noticed that the motors are humming and are choking at high power.

I had the same problem with my project and I suspect that issue is the same.

First I used analogWrite function and it worked well for small motors but the big ones were acting as yours do. So I included PWM.h library to my Arduino project, increased frequency of PWM signals (apparently bigger motors like higher frequency) and solved the problem. 

Ben,

What H bridge controller did you use?

As a safety FYI for you, involving stray RF causing problems to controls parts

I recently was given a electric "scooter" to assist me in getting out of the house due to a accident I had several years ago which left me with limited mobility. Unfortunately it failed a couple hours after I bought new batteries for it (Murphy's law I guess) and of course this was made by a company now out of business. I had failed in locating any service info on it other than the controller was made in NZ. (no response to my emails to them, I think as the device is a proprietary one)

But the point of all this, is, in my research I discovered a big safety problem that has occurred in home brew motorized wheelchairs and scooters. involving stray RF causing the controls to be overridden, (police radios, cabbies, CB's and what not) which in the past has apparently caused a few incidents of the motorized chairs to suddenly dart out into the streets by themselves causing injury to the riders (or is it sitters?)

I have no idea how to test the devices for this occurrence, but did locate several incidents posted online about the unfortunate folks involved. Anyone have feedback or ideas on this? As I watched the episode on my Tivo, I once again had even more admiration for Ben for his humane efforts to help out a couple nice folks, and would hate to see anything go wrong for any of them, and felt I should risk being a "bummer" by posting this info, but better safe than sorry I hope.

PS: No disrespect meant at all to anyone who has been involved in this project! I am sure you all have forgotten far more than I know about current electronics, as I am a dinosaur who learned from repairing Attwater Kents, Crosleys, & Philcos, (Note: I love the fact none of the previous names appear in spell check!)  in the 60's, who had a very enjoyable carrier in repairing (professionally) electronic devices until 1996 when a car accident ended my career, but I still remember when it was so enjoyable to be one of the first tech's to get to repair a defective new home entertainment electronic (or Pro, or mobile, whatever) device, quite often before the service information was released by the manufacture! Discovering something new, and to have had a career that got to ride the wave of electronics from the days before (tape) walkmans, continuing  past the days of CD walkmans ( I have no doubts these items were in use before some here were even born! lol) But is the reason I enjoy so much the Ben Heck Show, as he is able to do things I had only dreamed about "back in the day" which makes me so envious of his abilities, as well as so glad he shares himself with all of us in the community.

Hey, send me an email at colecago at gmail.com

Much appreciated, as said I already have deadzones set up on the controller end, my arduino based remote controller does a lot of the heavy number crunching to get more "usable" variable values to work with here is the stick related code in the controller:

http://pastebin.com/8xDRbLxj

the values might look odd but I pulled these sticks out of a very old logitech gamepad, I've basically made the middle dead-zone the value is showed with the stick centered +/- 100 etc, same with top and bottom values, the hole in the enclosure stops the stick moving far enough to engage the pot's whole range, I basically moved the sticks around to different places, wrote down the numbers in the serial monitor and adjusted up/down as needed to get good ranges including a "medium" deadzone in the middle and a bit of a deadzone at the far ends in all directions to ensure you don't need to push hard against the edges. The values are unique per stick due to them not being flawed in quite the same ways etc.

I did something like this on our AGV at work.  I ended up using the 4 quadrant approach.  It wasn't a single continuous function, but it didn't feel real weird at the border conditions.  I also had a deadzone around each axis so you could achieve straight moving pretty easily.  I'll see if I can write up some pseudo-code from it tomorrow.

Is the code available somewhere? I've had a head-scratcher over the same tank steering with a stick thing,

Problem is that I currently have 3 ranges to do different things because I can't figure out how to do it in one continuous range, which cases a weird discontinuity, basically within a deadzone in the middle left/right is directly mapped to wheel speed with one being reversed as you'd expect, and above and bellow the deadzone the vertical axis is mapped to wheel speed and if you move left/right it reduces the speed on that side compared to the other, this works fine as long as I never hold full left/right and move the vertical axis between those 3 ranges, if I do it suddenly changes behavior in a very ungraceful manner, it's going forwards and to the left, bring the throttle back to the middle and it suddently spins in place full speed, but it was slowing down as I brought back the throttle and similar.

Here is my actual arduino code: http://pastebin.com/5KSYyRvM  I've basically split the controls over 2 sticks one being used for vertical and one horizontal but combined they're the same as ben's, and I've split them into 8 distinct variables for ease of math and the deadzone part is handled by the remote controller side. (Arduino in the remote as well that grooms the numbers a bit to ease the robot's burden).

I also have directly mapped tank steering controls, vertical axis of each stick directly controls the motors which works nicely, but it's not very intuitive for people used to driving cars.

Any help figuring out how to get something close to that "graph" above with a single continuous function would be great.

If you're interested here is what the code lives in: