Probably an entirely different speed controller package that uses PWM and is able to handle the motor current load. Not simple.

 

Probably an entirely different speed controller package that uses PWM and is able to handle the motor current load. Not simple.

Thanks Mr Bill, I'm here to learn so why is this not simple?

Since my motor seems to only speed-up or slow-down when receiving 5 different voltages (4.1, 5.3, 6.6, 8.9, 11.3v)
I was thinking it would be possible to use a voltage regulator circuit to control the speed.

If that works, then maybe an ultrasonic sensor to measure the distance from me to the golf (push) cart and auto-increase/decrease the voltage. If I get too far away (>15 ft) or too close (<3 ft) then it should drop to < 4v.

 

I was thinking it would be possible to use a voltage regulator circuit to control the speed.

Controlling the voltage in steps like that won't control the speed well. If the motor is driving a heavy load, e.g when the golf cart is going over rough ground or uphill, it will slow down and draw more current.

 

Certainly you could use an ultrasonic distance measuring device and some logic to switch to a lower speed as the distance increased and switch to a higher speed as the distance grew smaller. That would need to have a cutoff so that it will t
revert to manual control when yu grab the handle. And really that system would not need a processor board, although a processor will make it simpler. This may be the very simplest scheme.

 

I haven't forgotten about this. I have been tinkering with my old RPI3B and am working on this solution.
The RPi3 has these components attached:

• a TF-Lunar LiDAR distance sensor tells me how far away from the cart I am
• an IR receiver accepting IR codes from my IR remote
• an Arducam 8MP CSI camera that tracks distance to my face via opencv
• a SunFounder PCA9856 Servo controller and a digital servo that turns the existing Rheostat to a calibrated position that I know corresponds to a speed (1 of 5 speeds)

I have all the pieces working individually. Now I'm working on getting it all packaged into a closed box and working out the actual algorithm that moves the servo based on distance and/or remote IR codes.
The camera and distance measurement via opencv isn't really useful since the cart moves around so much. Video stream stabilization takes too much effort to keep focused in real time so I opted for the LiDAR

 

I have a dumb question. How do you steer this? Doesn't it need you holding on to the handle to steer it, like most small golf bag carts?

 

I have a dumb question. How do you steer this? Doesn't it need you holding on to the handle to steer it, like most small golf bag carts?

I have seen write-ups about a couple of them that use what I think is an IR flashing beacon clipped to the user's belt.That makes the system a lot more complex because now it needs to track and steer. I am guessing that it steers by the speed of the two larger wheels and that the balance wheel castors as it turns. I am guessing that the TS steers theirs with either the handle or a short leash. The original complaint was that the preset speed settings were either too slow or two fast, requiring constant adjusting of the speed control.

 

Yes, I have not addressed left/right steering. This electric push cart has 3 wheels and slight pressure on the handle towards the right or left is enough to steer. Not sure how but I'll address steering later. Maybe a new wheel type at the front and another servo to respond to left/right buttons from my remote.

 

You probably already know but->

You can wire directly to the motor without the microcontroller if you put it in a potential divider rheostat mode, cause u dont want to increase resistance into a motor. (you dont want to be more than 1/2 an ohm really!!!) you want to change the voltage, not the resistance.

 

Can't believe it hasn't been brought up yet, but... digitpot? I think you could just replace the existing speed pot with a a digipot and then use one one those cheap Amazon wireless relay modules to step the speed up and down. One channel could switch between handle control/remote control. One channel for speed up and one for slow down.

 

The control will be vastly more efficient if the otor speed is controlled using PWM instead of a variable resistor. And the effort of moving will be less if it is pulled, not pushed.
What is totally missing is a detailed view of the drive scheme. If both wheels are driven through a differential, or by two motors, different methods will be required. It is obvious from the photo that the front wheel does not steer and can not swivel and so evidently steering is intended to be a strong-arm method. Possibly a dual motor drive system will allow a bit of directional control, but even then it will not be very satisfactory because it will require skidding the front wheel.

 

I think t

The control will be vastly more efficient if the otor speed is controlled using PWM instead of a variable resistor. And the effort of moving will be less if it is pulled, not pushed.
What is totally missing is a detailed view of the drive scheme. If both wheels are driven through a differential, or by two motors, different methods will be required. It is obvious from the photo that the front wheel does not steer and can not swivel and so evidently steering is intended to be a strong-arm method. Possibly a dual motor drive system will allow a bit of directional control, but even then it will not be very satisfactory because it will require skidding the front wheel.

theres nothing wrong with a variable voltage divider in my mind. no arduino.

 

theres nothing wrong with a variable voltage divider in my mind

Theory is one thing; practicalities are something else.

 

Theory is one thing; practicalities are something else.

For direct motor speed control a voltage divider places a resistor in parallel with the motor load, and that is not efficient at all.
If the control is for setting the control input of a motor drive controller, that is quite totally different. An earlier post commented that the limited number of preset speeds were not suitable but it gave no hint about the actual control system, only that the choices were "too fast or too slow".
So the controller may already be a PWM system with poor control options.

 

I think t

theres nothing wrong with a variable voltage divider in my mind. no arduino.

As long as you don't mind wasting battery power in heat. PWM does it without wasting power from the battery. That is why RC models use PWM instead of a rheostat.

 

For direct motor speed control a voltage divider places a resistor in parallel with the motor load, and that is not efficient at all.
If the control is for setting the control input of a motor drive controller, that is quite totally different. An earlier post commented that the limited number of preset speeds were not suitable but it gave no hint about the actual control system, only that the choices were "too fast or too slow".
So the controller may already be a PWM system with poor control options.

your supposed to use some very low resistance wire, like nychrome, and then they do put a small load on the motor but the torque loss in minimal, it is present tho, yes.

 

You probably already know but->

Yes, that was my initial thought. I wanted to build a circuit to directly control the existing single-driver motor on the axel of the cart. I'm a software guy (don't know much about microelectronics) and when you guys start talking about resistance, voltage, pwm, ohms, etc. I failed to understand how to implement your're suggesting.

That's why I ended up using a Raspberry and writing software. My logic is basically this:

1. The LidarD tracks my distance to the cart and sends a HTTP/PUT request to the ThrottleD to adjust the speed.

If I'm < 2 or > 15 feet away it will stop the cart, if I'm between 10 and 15 feet it will set a "crawl" speed until I catch up.​

1. Using a remote control I can adjust the speed up/down or directly to 1 of the 5 possible speeds. I can also send a code to toggle an "ignore" flag in the ThrottleD so that it ignores speed changes from the LidarD.

With the software solution I can easily try alternative approaches to controlling the cart.
Like OpenCV and a camera on the RPi I could use hand signals instead of sending IR codes.
Or, since the keeping the video focused was an issue for me I thought of trying voice commands. "Hey cart slow down".

 

If you need to steer it as well it will be quite a distraction from any conversation you may be having. Plus you will be needing to carry the RC transmitter And it will need to have a "loss of signal" shutdown function.

 

Yes, that was my initial thought. I wanted to build a circuit to directly control the existing single-driver motor on the axel of the cart. I'm a software guy (don't know much about microelectronics) and when you guys start talking about resistance, voltage, pwm, ohms, etc. I failed to understand how to implement your're suggesting.

Every once in a while someone comes along who sounds savvy enough that they get talked to like they have a basic understanding when they don't. I think you might be one of them. So let me break this down.

PWM = pluse width modulation. Let's say your battery voltage is 24V and when you apply 24V to the motor your cart cruises at sprinting speed. You want it to go about 25% of max, so you want to give the motor 6V instead of 24V. But your battery is 24V, not 6V. What you can do is turn the motor off and on really fast (a few thousand times per second, AKA a few kHz). You turn it on (apply the full 24V) for 0.0001 seconds and then you turn it off for 0.0003 seconds and then on for another 0.0001 seconds and on and on repeatedly. What you're doing is PWM. You're pulsing the motor with a PWM voltage. Your PWM duty cycle (the ratio of on : off time) is 25%
0.0001s ÷ (0.0001s + 0.0003s) = 0.25
This is in effect the same thing as applying 6V to it.
This is a very efficient way to control a motor and most likely the way your existing controller board already works.

The other suggestion to use a high power/low-resistance rheostat in series with the motor is wasteful. It is a viable solution and was employed for years in the ride-on golf carts but has been entirely abandoned as far as I know.

If you want the water analogy here it goes... say you want to fill a bucket at 10% of the flow rate your hose is capable of. With PWM you would be opening and closing your water valve thousands of times per second to modulate the flow to 10%. With a rheostat you're opening the faucet all the way and placing the bucket partially in the flow stream so that 10% of it goes into the bucket and the other 90% spills on the porch, wasted.

Resistance, ohms, etc not relevant to the conversation at this time. All you need to know is: PWM good, rheostat bad. And you already have PWM (probably... almost certainly).

That's why I ended up using a Raspberry and writing software.

You're indicating pretty strongly that this is something you've already done/written but that doesn't seem to jive with your apparent lack of any concept of the physical side. The circuits and the software are things that, if I were designing this, would be designed in parallel. Actually I'm not sure how I would go about it any other way. One informs the other. So can you clarify what among the following quote is something you've actually written already and what is just something you plan to write?

My logic is basically this:

1. The LidarD tracks my distance to the cart and sends a HTTP/PUT request to the ThrottleD to adjust the speed.

If I'm < 2 or > 15 feet away it will stop the cart, if I'm between 10 and 15 feet it will set a "crawl" speed until I catch up.

1. Using a remote control I can adjust the speed up/down or directly to 1 of the 5 possible speeds. I can also send a code to toggle an "ignore" flag in the ThrottleD so that it ignores speed changes from the LidarD.

With the software solution I can easily try alternative approaches to controlling the cart.
Like OpenCV and a camera on the RPi I could use hand signals instead of sending IR codes.
Or, since the keeping the video focused was an issue for me I thought of trying voice commands. "Hey cart slow down".
View attachment 271090

Raspberry Pi is gross overkill for this project, and not even in a good way. I get that you want a programmable approach to the solution and you can still have that, no problem, for much cheaper and without waiting 3 minutes for your golf cart's OS to boot up. Why did you abandon the Arduino? That was perfect for your project.



If you've been skimming, stop and actually read this part.

This is what you need.

Whether you go with arduino, RPi, or MacBook. It emulates the speed pot (what you were calling a rheostat in post #1, it's a Potentiometer AKA Pot AKA speed pot, not a rheostat) on your handlebar. You can control it from your program and it will send a signal to your speed controller that will be indistinguishable from a twist of the throttle to the golf cart.

 

Thanks for the explanations @strantor; I'm just not familiar at all with this stuff at the hardware level.
As for the software items I mentioned, I've already written them all. Everything basically works already but I still need to figure out how to put it all into together into a box that I can mount onto the handlebar. I'm sure there will be other issues to sort out once I try it outside.

I do have an Arduino but I felt like the Pi gave me more options. Maybe just because I'm more familiar with it.
BTW, it only takes 45 seconds for the Pi3 to bootup.

All I wanted to do originally was control the speed of the electric push cart via remote control instead of having to keep my hand on the handlebar all the time. Sounds like all I needed then is an Arduino, an IR receiver and then wire the Arduino directly to the existing potentiometer?