Can you sneak a PWM signal into a motor controller?

Maybe a digital potentiomenter?
https://www.instructables.com/id/Digital-Potentiometer-MCP41100-and-Arduino/

I notice the pot includes an on/off switch.

I wouldn't try and insert my own pwm as that would I think be controlled by special chips that may do all sorts of things like soft starts and/or low battery protection.  It may even have an adjustable pulse frequency to reduce motor noise.

I had imagined if I ever got hold of a electric wheelchair I could could allow a computer to work the joystick physically by using servo or stepper motors. Even buttons could be actuated using a solenoid.

In the majority of cases a potentiomiter is used as a simple voltage divider. If this is the case with this driver card and the voltages mach up then using a MCU (e.g., ESP32) that has a DAC could be used to replace the pot. Also a PWM signal fed into an integration circuit might do the trick as well. But any of this is hard to know without the board to do some measurements or a schematic.

Thank you for the replies!  The market seems pretty limited for what I'm looking for.  I may just have to build my own controller or integrate one into the PCBs I'm going to get manufactured.   The goal is to make an easy to install all-in-one device for Power Wheels with an Android app to go with it.  The arduino would read the battery voltage, default the car to 12V  (regardless if it's 24v, 18v, or 12v battery setup), and allow a bluetooth connected phone or tablet to adjust the target voltage for the duty cycle to match.  

One of the biggest issues with increasing voltage to 24V in one of these cars is that the gearboxes are plastic and the teeth strip on the gears. And when the cars are driven into something (or someone), it can also strip the gears.  So with a little code, I'm adding acceleration control to help smooth out the power delivery to the gearboxes  and even throwing an HC-SR04 into a case to mount on the front bumper to detect collisions and drop the duty cycle to 0 for a few seconds when someone/thing gets within a certain distance of the front of the car. 

Wish me luck!

Tim

Just for kicks, here's a really rough flowchart showing what I'm going for. If anything looks wrong or is missing, please let me know  🤣 

@tagivens

If you look at the circuit schematic you might be able to figure out where to inject the pwm from the arduino into the h-bridge. I see blocks of 3 mosfets so I am not sure exactly what the circuit layout is. You can work it out by inspecting the connections.

I once used a h-bridge kit where I just left out all the control circuits replacing them with my own pwm source and simply made use of the MOSFET H-BRIDGE part of the circuit board.

With regards to stripping the gears a slip clutch might be used.

Another solution might be to just find a suitable h-bridge circuit with control circuitry and build it yourself? 

Yeah, I might order one of these boards and poke around or try to find the schematic somewhere.  

For the gears and such, I'm not worried about my personal Power Wheels, I'm just trying to make an easy option for others to use if they'd like.   The Ford F-150 Power Wheel I'm currently working on has been modified to bypass the gearboxes with a live-axle and a 24V motor. Chain-driven and geared for about 12mph at 100% duty cycle. It's also got pneumatic tires and wheels from a golf cart and is set up as a dually  (2 wheels on each side in the back). It's teetering on the edge between Power Wheel and Go-Kart lol. 

I'll probably look into adding some really beefy MOSFETs to my PCBs with extra wide traces and heat sinks. I don't need full H-bridge functionality, since the shifters will still be in the cars (device I'm making goes between battery and shifter). That may end up being the easiest (and cheapest!) route, and it'd put everything on one single board. 

Looks like I've got some new stuff to YouTube! =)

Thanks,

Tim

@tagivens

If you end up building your own power circuits for the motors you might want to consider using motor breaking when an object is detected at close distances. This could be another reason to consider a commercially available H-bridge.

Also consider using interrupts to measure the HC-SR04 echo pulse width. I found that you can switch between looking for a falling edge interrupt to start a timer then switch the interrupt to looking for a rising edge to stop the timer. This prevents the problems with pulsein hanging up your code when there is no echo response. And even helps with a similar but lesser problem with the NewPing library. In these cases your MCU is essentially useless for anything else while waiting for a echo. Using an interrupt may not be as precise at returning the exact measurement to an object but in this application that is probably not critical. PulseIn can halt processing for as much as a second, which would prevent changing settings for the PWM during that time.

I did some more digging into that digital pot (MCP41100) and now I'm itching to mess around with one! But for the current project, I think I can go a bit overboard on the FETs and keeping them cool for far cheaper than ordering driver boards.  

@Ruplicator   The Power Wheels' shifter and pedal already have a brake built into them where it'll short/reverse the motors when the pedal is released and hard stop them. I may look into using a relay and breaking the circuit between pedal and shifter to get the same result.   

I've never used interrupts before.  The part of the code that's actually looking at the HC-SR04 is pretty bare bones.   If it's only looking for distances between 2 and 90 (90 is just a placeholder. Will need to do some tests to see how far it needs to stop in time), would it still get hung up the way you're thinking?  This is everything that's in the loop regarding the HC-SR04. 

 (Edit)  Ohhh I see, you're saying it can get held up calculating the new value for 'duration' in the code below? How frequent does pulseIn get tied up, or why does it? 

digitalWrite(trigPin, LOW); 
delayMicroseconds(2); 
digitalWrite(trigPin, HIGH);
delayMicroseconds(10); 
digitalWrite(trigPin, LOW);

duration = pulseIn(echoPin, HIGH);
distance = (duration / 2) * 0.0343;

if (distance >= 2 && distance <= 90)
{
analogWrite(pwmPin, 0);
delay(2000);
adjValue = (speedValue * .5);
analogWrite(pwmPin, adjValue);
delay(5000);
}

analogWrite(pwmPin, speedValue);

The problem with pulseIn is that it waits for the sonic echo from an object. If one is not received it continues waiting for 1 second while no other MCU activity will occur. Obviously, if you are looking for an object and one pops up you would think it would detect it. However, once the pulse is sent and let's say there is nothing in its 400 mm range then pulseIn just times out in 1 second. In your application I see this as a potential problem as most of the time, hopefully your daughter will not be running into stuff and there is a good chance there will be no ultrasonic echo and you script will constantly be waiting for pulsein to time out.

The library newPing is better because setting the timeout to a shorter distance will return control to your program potentially sooner. newPing is easy to use and should be sufficient for your needs. 

@Ruplicator Thanks again for explaining stuff for me! I'll look into the newPing library next!