Motor and brake control of an electric powered vehicle following a Human Being

I am building a simple electric vehicle which will carry my gear and follow close behind me as I walk long distances day after day after…… (I like taking things with me but I don't like carrying them all on my back.) I will not pull the vehicle and it will not push me either. I don't want to concern myself with control of the vehicle. What I have come up with is a tricycle with the front wheel powered by a electric motor. Presently the motor drives the wheel through a freewheel clutch - just like most bicycles.

concept sketch http://www.flickr.com/photos/charleschandler/10470195316/

The vehicle is tethered to the walker with a telescopic tiller tube (like a kid's wagon handle) which accomplishes steering. The forward tube of the tiller is fastened to the operators waist strap. The rear tiller tube is linked to the front fork of the tricycle. The two telescopic tubes permit the trailer to wander a fair amount along the axis of travel without bumping into the forward or aft stop of the forward tube and giving a jolt to the operator. I guess this would be around plus or minus 300mm travel from the midpoint position. The control system modulates the the power of the vehicle drive motor to maintain the vehicle at the midpoint position. I guess this would be accomplished with a PID control loop.

The vehicle also has a simple mechanical brake on the left side of the front wheel. I'm thinking, follow the KISS rule for now and don't get into regenerative braking. When the vehicle is descending a hill the controller will reduce the motor power to zero. The controller must then operate the brake to control the position of the vehicle. I am not sure about the details of how this will work. I am thinking the system would be structured in one or two ways. Option 1. Operate a linear actuator which would be linked to a 5K potentiometer which provides the command voltage to the control built into the motor. The actuator would start to close the brake pads as the output voltage from the potentiometer goes to zero. Perhaps there would be a bit of overlap.This way one actuator would have control of the motor and the brake. Option 2: The motor could be controlled by outputting a 0-5 volt signal directly to the motor controller that is built into the motor and an actuator could operate the brake when it was called for. I'm not sure which way would be better.

I have already purchased the drive motor. It's a brushless 3 phase motor and is rated at 360 watts. It has a 9.55:1 speed reducing gearbox on the output. ( I don't have much knowledge of motors) It has It has a controller built into it. The controller accepts a 0-5 volt command signal. This is normally provided by a manually operated, twist grip driven potentiometer for a standard electric bicycle application. Here is a link to the motor: http://www.cyclone-usa.com/store.php?crn=200

As far as operator controls go I am thinking the operator would have an on/off switch. It should communicate wirelessly with Arduino no wires need to be run from the operator to the vehicle.

My questions:

  1. Is this project within the capabilities of Arduino?
  2. If yes, what Arduino components would be required?
  3. Recommendations regarding Option 1 or Option 2 for control of motor and brake?
  4. What type of position sensor? This vehicle will be outside and exposed to the elements. Moisture and ice etc. and temperature extremes can be expected. I can design and enclosure if necessary.
  5. What type of actuator to operate the brake? ( I was thinking maybe a stepper motor operated screw actuator. I am thinking the maximum force needed to operate the brake would be around 45 N or 10 lb. The travel of the actuator would be 100 mm for Option 1 and 50 mm for Option 2.

Thanks much for your consideration and comments.

  1. Is this project within the capabilities of Arduino?

A qualified yes. Keep an open mind and as you fill in the specifications, revisit this question. A Pi may be a better choice; but Arduino 2560 would probably do the job (primary consideration is SRAM... 328 only has 2K while 2560 has 8K. I personally like the 2560's with 16K. An Arduino Due has 96K in two banks.)

  1. If yes, what Arduino components would be required?

See my answer to #1 above. Components beyond the main uC will be selected based upon your needs. You want wireless connectivity, so Bluetooth would be a consideration? You have a bigass motor, so you will need a serious FET driver board. And so on...

  1. Recommendations regarding Option 1 or Option 2 for control of motor and brake? Option 1. Operate a linear actuator Option 2: The motor could be controlled by outputting a 0-5 volt signal direct

I'm going to plead ignorant on the approach because I am not certain that all options have been unearthed.

  1. What type of position sensor? This vehicle will be outside and exposed to the elements. Moisture and ice etc. and temperature extremes can be expected. I can design and enclosure if necessary.

My preference for position +/- the neutral point would be an optical quadrature encoder (no stops.) The uC would count forward (+) and backward (-) from the position 0 (zero) to determine where in the finite length the two telescopic tubes were positioned. I would probably start with PVC tubing and use two opposing springs (remember those long screen door springs from the old days?) set the neutral point. A stainless steel hobby cord (flex cable) could be attached to the joint of the two springs, run down the PVC tube, and rotate a cylinder (pulley) that is connected to the optical encoder. Some basic PID programming would be used to work the acceleration & deceleration needs.

  1. What type of actuator to operate the brake?

Leaving this open to forum suggestions from members with experience in this area. I'm not completely sold on the free-wheeling aspect of the drive mechanism.

Ray

I'm wondering if this new stretch sensor might not be an ideal way to measure the telescopic tube position:

http://www.adafruit.com/products/519

You'll need somehow to arrange a single control variable to smoothly transition from forward motor drive to brake application - it might be necessary to have a little overlap (so that the brake actuator starts to engage a little before the motor is completely coasting - otherwise you may get a lot of jolting on the switchovers (as when on uneven ground).

I like the idea of the project, BTW.

It doesn't sound like the computer side of this is particularly onerous. Why wouldn't it work easily on a Uno or a breadboard 328 - which would be more robust having soldered connections.

All the computer seems to need to do is move (logically) between the two extremes of full power and full brake in response to some sort of input that is logically equivalent to trying to stay at the mid-point of a potentiometer. Maybe the telescoping section could be coupled to a pot?

It looks like there is no plan for reverse. If there was, perhaps it could help with braking.

Would a bicycle disc brake work with the cable operated by a screw and nut actuator?

It may be worth having a fore-and-aft accelerometer particularly to monitor the brake force but also to allow the program to provide some smoothing to the changes in velocity.

...R

I wouldn't bother with the brake, at least at first. Your control mechanism will need to be able to apply drive in both directions and that will give you acceleration and braking anyway, and the most obvious control strategy would support forwards and backwards movement and braking without you having to implement it explicitly.

I suspect you'll find that your drive mechanism is going to be so inefficient that you will get a massive amount of braking when you turn the motor off anyway, even without powering it in reverse.

In any case, if the motor is moving in one direction and being powered in the other then the back EMF and supply power work against each other and the motor uses relatively little current - probably not enough in the scheme of things to be worth the effort to save - and converting that to regenerative braking is just a matter of sorting some electronics out which ought to be much easier than getting mechanical braking systems to work consistently and reliably.

I suggest you use a PID algorithm to maintain the following distance, and keep it well damped down so that the drive isn't continually jostling backwards and forwards (which would be very inefficient).

300mm of travel doesn't sound like very much at all, in the context of a walking human. People can accelerate quite rapidly and you don't want your trailer to be trying to match that exactly.

Actually thinking about that motor being brushless - this suggests it can't run at the slowest speeds anyway, which may be an issue.

mrburnette:

  1. Is this project within the capabilities of Arduino?

A qualified yes. Keep an open mind and as you fill in the specifications, revisit this question. A Pi may be a better choice; but Arduino 2560 would probably do the job (primary consideration is SRAM... 328 only has 2K while 2560 has 8K. I personally like the 2560's with 16K. An Arduino Due has 96K in two banks.)

  1. If yes, what Arduino components would be required?

See my answer to #1 above. Components beyond the main uC will be selected based upon your needs. You want wireless connectivity, so Bluetooth would be a consideration? You have a bigass motor, so you will need a serious FET driver board. And so on…

IThe motor is big but al the Arduino only needs to provide a zero to 5 volt command signal to the motor controller that is built into the motor. I understand command signal to the motor could be achieved by pulse width modulation or by using a digital to analog converter. I have no idea about which of these is the best way. What is the best way?

  1. Recommendations regarding Option 1 or Option 2 for control of motor and brake? Option 1. Operate a linear actuator Option 2: The motor could be controlled by outputting a 0-5 volt signal direct

I'm going to plead ignorant on the approach because I am not certain that all options have been unearthed.

  1. What type of position sensor? This vehicle will be outside and exposed to the elements. Moisture and ice etc. and temperature extremes can be expected. I can design and enclosure if necessary.

My preference for position +/- the neutral point would be an optical quadrature encoder (no stops.) The uC would count forward (+) and backward (-) from the position 0 (zero) to determine where in the finite length the two telescopic tubes were positioned. I would probably start with PVC tubing and use two opposing springs (remember those long screen door springs from the old days?) set the neutral point. A stainless steel hobby cord (flex cable) could be attached to the joint of the two springs, run down the PVC tube, and rotate a cylinder (pulley) that is connected to the optical encoder. Some basic PID programming would be used to work the acceleration & deceleration needs.

  1. What type of actuator to operate the brake?

Leaving this open to forum suggestions from members with experience in this area. I'm not completely sold on the free-wheeling aspect of the drive mechanism. I understand. I have been thinking about that myself. I will comment further soon.

Ray

MarkT: I'm wondering if this new stretch sensor might not be an ideal way to measure the telescopic tube position:

http://www.adafruit.com/products/519

You'll need somehow to arrange a single control variable to smoothly transition from forward motor drive to brake application - it might be necessary to have a little overlap (so that the brake actuator starts to engage a little before the motor is completely coasting - otherwise you may get a lot of jolting on the switchovers (as when on uneven ground).

I like the idea of the project, BTW.

Thank you . The part about the stretching resister that concerned me the most was: "Once the force is released, the rubber will shrink back, although its not very 'fast' and it takes a minute or two to revert to its original length." I think that is a show stopper. I am concerned about the transition to braking as well. I will write more below.

Robin2: It doesn't sound like the computer side of this is particularly onerous. Why wouldn't it work easily on a Uno or a breadboard 328 - which would be more robust having soldered connections.

All the computer seems to need to do is move (logically) between the two extremes of full power and full brake in response to some sort of input that is logically equivalent to trying to stay at the mid-point of a potentiometer. Maybe the telescoping section could be coupled to a pot?

It looks like there is no plan for reverse. If there was, perhaps it could help with braking.

Would a bicycle disc brake work with the cable operated by a screw and nut actuator? I think so. It works when I squeeze it with my hand. So it should work with an actuator.

It may be worth having a fore-and-aft accelerometer particularly to monitor the brake force but also to allow the program to provide some smoothing to the changes in velocity. That sounds possible to me. I figure one of the main things to solving this is to make it smooth. Perhaps putting a limit on the acceleration or deceleration of the vehicle might be key.

...R

PeterH: I wouldn't bother with the brake, at least at first. Your control mechanism will need to be able to apply drive in both directions and that will give you acceleration and braking anyway, and the most obvious control strategy would support forwards and backwards movement and braking without you having to implement it explicitly.

Presently the motor drives the wheel through a freewheeling clutch on the drive wheel hub. So there is no ability to brake the vehicle through the motor. Additionally the built in motor control has no facility for motor braking . It has a built in controller which accepts a 0-5 volt input. I am not sure what parameter this signal is controlling. I think it is torque.

I suspect you'll find that your drive mechanism is going to be so inefficient that you will get a massive amount of braking when you turn the motor off anyway, even without powering it in reverse. I am happy that you mentioned that. It doesn't matter as I am driving the wheel through a freewheel. However, you have encouraged me to think about whether the freewheel is good or bad. I started thinking about how I can't even turn the gearbox output with my bare hand. I decided I must find out how much torque is required to drive the gearbox and motor from the gearbox output. I found a wrench and rotated the shaft estimating the tough I was applying to rotate the shaft. I estimate it was about 12 inch pounds at the output shaft. I have another gear reduction by belt pulleys between the motor output and the wheel. That is a further 4.7:1 reduction. Here I assume that weld up the freewheel. I estimate the braking effect of the motor would be about 56 inch-pounds of torque at the wheel. This means at 3 mph it would take about 26 watts of power to propel the vehicle against the motor and gearbox torque. If the loaded vehicle weighed 150 pounds the downslope would have to be increased to 2.8 percent before the vehicle would start to roll against the motor. If the hill got steeper the mechanical brake would become necessary . The advantage of keeping the freewheel is reduced energy consumption and reduced wear and tear on the motor and gearbox. The advantage of eliminating the freewheel is that up to around 56 inch pounds of braking torque are built into the system and wear and tear of the mechanical brake is reduced.

In any case, if the motor is moving in one direction and being powered in the other then the back EMF and supply power work against each other and the motor uses relatively little current - probably not enough in the scheme of things to be worth the effort to save - and converting that to regenerative braking is just a matter of sorting some electronics out which ought to be much easier than getting mechanical braking systems to work consistently and reliably.

Now I'm wondering if I will need to rearrange things significantly. Eliminating the freewheel and adding regenerative braking. As far as I know my motor and built in control do not accommodate regenerative braking. That means spending more money might be in the cards. I will need to do some research. I want to see if there are any commercially available motor controls that have built-in facility for regenerative braking. This is what my motor controller does not have. One thing I know is that Lithium Ion batteries can not be charged very fast. I suspect this is not a problem for my application.

My vehicle will be solar powered. That is incidental for this discussion.

I suggest you use a PID algorithm to maintain the following distance, and keep it well damped down so that the drive isn't continually jostling backwards and forwards (which would be very inefficient).

I agree.

300mm of travel doesn't sound like very much at all, in the context of a walking human. People can accelerate quite rapidly and you don't want your trailer to be trying to match that exactly.

I agree. But I don't want a huge amount of travel. Maybe it would be a good idea to try to simulate the whole system before trying it out on a vehicle. I am building a cheap testbed that I can play with. Maybe the testbed would be just as good as a computer simulation.

I was wondering if would be a good idea to have an accelerometer on the waist strap of the human operator? I wish I knew more about controls. It does seem to me though that the job of the vehicle controller is to mimic the human. However it can tell a lot about what is going on by monitoring the position encoder. Now I'm thinking if the vehicle had it's own speed sensor and it's own accelerometer it probably has everything it needs.

MarkT: Actually thinking about that motor being brushless - this suggests it can't run at the slowest speeds anyway, which may be an issue.

I don't know about that. I do know that I walk at about 3 mph. At 3 mph my vehicle motor is turning at 1750 rpm.

When you mentioned the possibility of an accelerometer on the human's wrist it reminded me that we like to swing our arms while we walk so the wrist might be the worst place for it. My thought then followed on to the possibility that it may be very uncomfortable to walk with a hand held stiffly but not actually connected to a stiff device. When we walk towing a traditional trolley with a hand the trolley keeps the hand in place as well as the hand keeping the trolley in place. In effect, the trolley saves a lot of muscle effort that would be needed to keep the hand in that position.

It may be more comfortable to have your trolley "connected" to the walker's waist.

Have you considered making your trolley as a self-balancing "Segway" with just 2 wheels? A rigid link from the upright control stick to the walker should provide all the necessary control and feedback.

...R

GrandpaWalking:

MarkT: Actually thinking about that motor being brushless - this suggests it can't run at the slowest speeds anyway, which may be an issue.

I don't know about that. I do know that I walk at about 3 mph. At 3 mph my vehicle motor is turning at 1750 rpm.

Yes but it may refuse to start under load, that's how sensorless BLDCs tend to behave as open-loop drive is very fragile.

Robin2: When you mentioned the possibility of an accelerometer on the human's wrist it reminded me that we like to swing our arms while we walk so the wrist might be the worst place for it. My thought then followed on to the possibility that it may be very uncomfortable to walk with a hand held stiffly but not actually connected to a stiff device. When we walk towing a traditional trolley with a hand the trolley keeps the hand in place as well as the hand keeping the trolley in place. In effect, the trolley saves a lot of muscle effort that would be needed to keep the hand in that position.

It may be more comfortable to have your trolley "connected" to the walker's waist.

Have you considered making your trolley as a self-balancing "Segway" with just 2 wheels? A rigid link from the upright control stick to the walker should provide all the necessary control and feedback.

...R

Above I had proposed mounting an accelerometer on the operator's waist strap not wrist as you said. I am aware that arms flap around quite a bit. I afraid I totally disagree with your comment about having the operators's hand on a handle. That is the last arrangement I would ever want. I want my hands free and want and to to walk unimpeded. I think that is the main point of the project. I might choose to use hiking poles. I've walked thousands of miles with hiking poles. They give you a little more push, they give you a bit of an upper body workout, they can be used to intimidate mean attack dogs (I make a mental note to incorporate a bear spray unit on my waist strap for vicious fight dogs.) that come after you, you can dig a cathole with them, use them to support your tarp, save your knees on steep downhills and many more things. Also they can act as an ice breaker. People who see me say things like " Dude. don't you know there's no snow in Florida?" or " I was wondering why you have ski poles in Florida?" Then I explain to them how many long distance walkers use trekking poles and tell them the story of the time a pack of big dogs came after me…...

I have no need to mimic something that is complicated and stupid like the Segway. The Segway is a stupid invention. The bicycle is much better than the Segway and walking is even better. My tricycle is stable, simple and functional. It doesn't waste energy balancing itself.

If you aren't particularly committed to the telescopic tiller then you could replace it with a simple hinged beam with a potentiometer measuring the angle at the elbow. It would be mechanically simple and the sensor would also be a lot simpler. It would also make it possible to fold the whole thing up out of the way if you wanted.

I've been envisaging the trailer as quite a small thing, perhaps a hundred kilos. At that scale, the sort of friction you're describing on the gearbox [u]input[/u] seems excessive.

Disabling the freewheel ought to be relatively easy - if it was me, I'd want to do this in away that could be reversed if necessary. The freewheel would make a lot of sense if you were mainly towing the trailer unassisted, with the motor just coming in occasionally. If that's the case I'd stick with the freewheel and separate braking system. However, if you want this thing to follow you effortlessly it implies that the motor will be working all the time, so there is no benefit from the freewheel - the fact it then requires a separate braking mechanism is then a big disadvantage and a good reason to ditch the freewheel.

MarkT:

GrandpaWalking:

MarkT: Actually thinking about that motor being brushless - this suggests it can't run at the slowest speeds anyway, which may be an issue.

I don't know about that. I do know that I walk at about 3 mph. At 3 mph my vehicle motor is turning at 1750 rpm.

Yes but it may refuse to start under load, that's how sensorless BLDCs tend to behave as open-loop drive is very fragile.

This motor, controller and gearbox has been sold to hundreds of people who install it on their bicycles and it works. thousands of other brushless motors and controllers are being used by electric bike people. They all start at zero speed and accelerate to the speed they command with their twist grip throttle. Why would it power their bicycles and not work on my tricycle?

PeterH: If you aren't particularly committed to the telescopic tiller then you could replace it with a simple hinged beam with a potentiometer measuring the angle at the elbow. It would be mechanically simple and the sensor would also be a lot simpler. It would also make it possible to fold the whole thing up out of the way if you wanted.

I don't understand your point. The primary purpose of my tiller is to steer the vehicle. The front wheel of the tricycle is always aimed at the operator. The tricycle will follow the operator. The tiller is hinged at the fork of the tricycle. It must be hinged at the fork connection. The secondary function of the tiller is to accommodate a transducer which measures the position of the operator in relation to the vehicle.

I've been envisaging the trailer as quite a small thing, perhaps a hundred kilos. At that scale, the sort of friction you're describing on the gearbox [u]input[/u] seems excessive.

I measured the torque required to drive the 9.55:1 gearbox and the motor at the gearbox output. It is what it is. To me it does not seem excessive or unexpected.

Disabling the freewheel ought to be relatively easy - if it was me, I'd want to do this in away that could be reversed if necessary. The freewheel would make a lot of sense if you were mainly towing the trailer unassisted, with the motor just coming in occasionally. If that's the case I'd stick with the freewheel and separate braking system. However, if you want this thing to follow you effortlessly it implies that the motor will be working all the time, so there is no benefit from the freewheel - the fact it then requires a separate braking mechanism is then a big disadvantage and a good reason to ditch the freewheel.

I have no intention of dragging this trailer behind me. Even on level ground the power required to pull the trailer is significant. I have thought about eliminating the freewheel. I have thought about selling my motor on eBay and looking for another. After thinking I have slept on it.

I have decided to proceed with the system as it is. The vehicle will use the motor and controller which I have. And it will drive the wheel through a hub mounted freewheel. It will have a brake on the drive wheel. The vehicle is solar powered. This layout provides for minimum energy use. Motor use will be minimized. On steep downhills the motor will be off and a brake will control the vehicle position. The operation of the vehicle is identical to that the electric bicycle which works well and is very efficient. I am confident that I could control the vehicle using manual controls. If I can control it , it should be possible to control it with software.

GrandpaWalking: Above I had proposed mounting an accelerometer on the operator's waist strap not wrist as you said. I am aware that arms flap around quite a bit. I afraid I totally disagree with your comment …... ...snip.... I have no need to mimic something that is complicated and stupid like the Segway. The Segway is a stupid invention. The bicycle is much better than the Segway and walking is even better. My tricycle is stable, simple and functional. It doesn't waste energy balancing itself.

I apologize for misreading your earlier post and thinking you said "wrist" when in fact you said "waist".

However I feel your response to my mistake was rather stronger than necessary.

You also misinterpreted my comment about arms, I was agreeing with you on the need to have your arms free.

And I wasn't suggesting the Segway as an alternative to walking, merely as a way of achieving the sort of "follow-me" device you wish to have.

...R

GrandpaWalking: I don't understand your point. The primary purpose of my tiller is to steer the vehicle. The front wheel of the tricycle is always aimed at the operator. The tricycle will follow the operator. The tiller is hinged at the fork of the tricycle. It must be hinged at the fork connection. The secondary function of the tiller is to accommodate a transducer which measures the position of the operator in relation to the vehicle.

I understand the purpose of the tiller, but the telescopic design you are proposing is not the only way to achieve it and has the disadvantage of needing a long travel linear position sensor. You could replace the telescopic arm with a folding arm which would work in much the same way but folding rather than telescoping - visualise an anglepoise lamp and you will get the sort of idea.

Robin2:

GrandpaWalking: Above I had proposed mounting an accelerometer on the operator's waist strap not wrist as you said. I am aware that arms flap around quite a bit. I afraid I totally disagree with your comment …... ...snip.... I have no need to mimic something that is complicated and stupid like the Segway. The Segway is a stupid invention. The bicycle is much better than the Segway and walking is even better. My tricycle is stable, simple and functional. It doesn't waste energy balancing itself.

I apologize for misreading your earlier post and thinking you said "wrist" when in fact you said "waist".

However I feel your response to my mistake was rather stronger than necessary.

You also misinterpreted my comment about arms, I was agreeing with you on the need to have your arms free.

And I wasn't suggesting the Segway as an alternative to walking, merely as a way of achieving the sort of "follow-me" device you wish to have.

...R

I apologize for my behavior this morning. I was a jerk. There was no need for me to take out my frustration on you. Thank you for your comments. I just want this thing to be simple. (I have loathed the Segway for a long time.) There was no need for me to be like that.