TB6612 motor driver

@tfmccarthy

My question is this: will powering the through the USB cause damage? I'm worried the motors are trying to draw too much current and that will damage things. In general, I want to turn the battery on first but...I might forget.

It might not cause damage depending on the hardware but it probably isn't a good idea to leave it like that.

From online advice:

To avoid running the motors from USB power on the Elegoo Smart Robot Car v4.0, the goal is to decouple the motor driver power input from the Arduino's USB power source and ensure the motors only receive power when the battery pack switch is turned on.

Essential Wiring & SetupThe Elegoo v4.0 utilizes a specialized IO expansion board that sits on top of the Uno R3.

Battery Power Source: The 7.4V lithium battery pack includes a dedicated power switch. Connect this battery box directly to the power input terminals on the expansion board.Motor Connections: The four motors connect to labeled ports (M1, M2, M3, M4) on the expansion board.Isolate USB Power: The USB cable should only be used for uploading code, not for driving the motors. When uploading, simply leave the battery switch OFF.

Steps to Isolate Motor PowerUse Only Battery for Motors: Ensure that the 7.4V rechargeable battery pack is plugged into the dedicated battery port on the expansion shield, not the Arduino.Toggle the Switch: The battery connector includes a power switch. Keep this switch OFF when the USB is connected. The motors are connected to the motor driver (TB6612FNG or L298N depending on version) which receives power from this battery switch, not the USB.Check for "Backfeeding": If motors still spin from USB, ensure that no external wires have been connected that bridge the Arduino's 5V pin to the motor shield's power input.Disconnect USB during Testing: Always remove the USB cable entirely when testing motor movement to avoid drawing power from the computer and to prevent noise interference.

TroubleshootingMotor Driver Standby: The motor driver uses a standby pin (often connected to D3 or D5) that must be pulled HIGH to enable the motors. If your code or the default code sets this to LOW, the motors will not run.Common Ground: While separating power, ensure that the battery GND is connected to the motor driver GND, which is bridged to the Arduino GND via the shield.Battery Level: The motors will not operate correctly (or at all) if the battery is discharged, making it seem like they are only working on USB (if the USB manages to spin them slowly).

If the motors still run from USB, there may be a short circuit between the Vin pin and the 5V rail on the shield.

@robotbuilder 

Well, I'm not paranoid, but I am confused.

I was OK with the online advice right up to:

The USB cable should only be used for uploading code, not for driving the motors. When uploading, simply leave the battery switch OFF.

That's the problem I tried to describe.

If you follow this advice when you've uploaded the code to the UNO it exits bootloader mode and the sketch begins to execute. The UNO is reset after upload. This is the normal sequence.

At this point the battery is off and, per force, you're powering the motor driver from the USB.

This corresponds with my understanding of how the UNO determines the power source. If the battery input is on when the UNO resets, then the USB power input is disconnected; otherwise, the USB power is used. You can still use the USB to communicate but it won't provide power.

So, the online advice doesn't make sense. With the battery off, you can't avoid powering the motors from the USB when you upload a sketch.

My issue was that I didn't think the USB could provide the current to the run the motors.

But that's not true. The motors do run, albeit sluggishly.

I was worried that the low current would cause damage to the driver or other components.

FYI, there are two switches for the SmartCar v4.0:

1. A battery ON/OFF switch
2. A upload/camera switch on the shield

I haven't gotten to the camera testing yet but, as I understand it, the camera uses the serial UART for communication. The switch disconnects the serial port from the USB and connects it to the camera. (I'm worried this will be a problem unit testing the camera.) So, you can't upload a sketch when the switch is set camera. Otherwise, the camera is powered normally.

Nothing is coming back from my searches about damaging components due to low power, so I'll stay with that for now.

@tfmccarthy 

I don't understand why the motors would be ever be powered via the UNO board even if the board uses the same battery. The UNO board (microcontroller part) should provide the control signals to the motor driver circuit which would be connected to the battery directly. These signals from the board only need to be high enough to turn the MOSFETs on/off.

You could turn off the motor signals in the setup() to prevent the motors starting up.

@tfmccarthy  

Just to second what robotBuilder said ... the motor driver board +voltage should not be connected to the uno at all. It should be powered by the battery directly (another lead). Of course the driver board and the uno should have a common ground but you know that.

@robotbuilder, @noweare

I understand the point and generally agree which is what prompted my question. However, the empirical evidence says something else. And this isn't a case of wiring error as the connectors are keylock so there's no room for wiring faults.

This is a mystery I can't explain. Here's the schematic for the shield.

Note that the package has a note saying that due to chip supply issues, the driver chip DRV8835 has been replaced with chip TB6612FNG.

I don't see a connection that would power the motor driver from the UNO.

The only hint I see is the diode on the Power Module Vin pin. This appears to be an isolation diode to block input power from the board to the battery. Since the Vin pin provides the power from the battery to the rest of the board, the only reason I can think of for the diode is to block power from the UNO. This implies the UNO 5v pin is tied to the Vin line.

I just don't see it. It might be related to a mismatch of the replacement chip pins and the schematic.

I did look at the video TB6612FNG H-Bridge Motor Controller - Better than L298N? but wasn't able to find any answer there.

@dronebot-workshop, do you recall if you had the same behavior with the v3.0 car? With the battery turned off, did the motors automatically run after uploading a sketch?

@tfmccarthy 

Yes I guess that diode is preventing back flow from the battery to the USB power supply when the higher voltage battery is on.

Does turning off the motors in the setup() stop the motors starting up?

Posted by: @robotbuilder

↑

Does turning off the motors in the setup() stop the motors starting up?

I'm not sure what you mean by this. The first sketch is essentially the "Sweep" sketch. It cycles through the enumerated directions, e.g.,

// Motion Direction Control Sequence 
enum SmartRobotCarMotionControl
{
	Forward			//(1)
	, Backward      //(2)
	, Left          //(3)
	, Right         //(4)
	, LeftForward   //(5)
	, LeftBackward	//(6)
	, RightForward	//(7)
	, RightBackward	//(8)
	, stop_it       //(9)
};

struct Application_xxx
{
	SmartRobotCarMotionControl Motion_Control;
};

//...

// Motor control 
void DeviceDriverSet_Motor::DeviceDriverSet_Motor_Init(void)
{
	pinMode(PIN_Motor_PWMA, OUTPUT);
	pinMode(PIN_Motor_PWMB, OUTPUT);
	pinMode(PIN_Motor_AIN_1, OUTPUT);
	pinMode(PIN_Motor_BIN_1, OUTPUT);
	pinMode(PIN_Motor_STBY, OUTPUT);
}

//...

void setup() {
	AppMotor.DeviceDriverSet_Motor_Init();
	delay(2000);

	for (Application_SmartRobotCarxxx0.Motion_Control = 0;
		Application_SmartRobotCarxxx0.Motion_Control < 9;
		Application_SmartRobotCarxxx0.Motion_Control = Application_SmartRobotCarxxx0.Motion_Control + 1)
	{
		ApplicationFunctionSet_SmartRobotCarMotionControl(
			Application_SmartRobotCarxxx0.Motion_Control // direction
			, 200 // speed
		);
		delay(1000);
	}
}

[aside] I'm preparing a deep dive review post and don't want to get side-tracked here other than to say that enumerated values start with a default of zero, not one, and are not guaranteed to be sequential. [/aside]

So, if by "turn off" you mean "don't write the PWM values" to the motors to change direction then the sketch does nothing. The motors are still powered on,; they're just not spinning. The issue is that when the battery is off, they shouldn't be powered on.

Also, if the USB is providing power to the motors, then simply connecting the USB will make the last uploaded sketch start running. This is what I see. While the new sketch is being uploaded, the sketch stops. After uploading, the new sketch starts.

This is the normal behavior with the exception of the motors getting power.

Right now, my best guess is that the UNO 5v pin is connected to the power module Vin (before the diode.). When the USB is the power source, the 5v GPIO pin acts like the battery and is feed to the motor driver. When USB is connected after the battery is turned on, the UNO disables the 5v pin. If the battery is turned on after the USB is connected, then the diode prevents the backlash voltage from the UNO.

I tried to run a continuity test between the 5v GPIO pin and the TB6612FNG pins without consistent results. I do get a hit (pin 20: (Vcc) 5v logic pin) but not pin 24, VM1, motor power supply.

As I expect to be uploading a lot while developing the unit tests, I'm concerned that it might cause damage. I don't want damage. >:(

I'm crossing my fingers Bill has some insights.

I'm also crossing my fingers I win the lottery.

@tfmccarthy 

Ok I imagined the code written without everything being hidden in libraries.

I imagined the setup() did just that, set things up.

So with the battery off the power from the USB would be there but not being pulsed by the motor controller direction pins and so motors wouldn't move.

Ideally perhaps software recognition of the status of the battery being on or off?

In the loop() the commands written without libraries such as this example:

/*  Code to test the motors on the Elegoo Robot Car 4
    Martin H.
    Southern Illinois University, for Automotive Technologies
    
    Download, disconnect cable, place on floor with room to drive (about 4 feet clearance in all directions)
    Press the mode button, wait 2 seconds for it to begin
*/

// define IO pin
#define PWMA 5    // Controls power to right motor
#define PWMB 6    // Controls power to left motor
#define AIN 7     // Controls direction of right motor, HIGH = FORWARD, LOW = REVERSE
#define BIN 8     // Controls direction of right motor, HIGH = FORWARD, LOW = REVERSE
#define STBY 3    // Place H-Bridge in standby if LOW, Run if HIGH

#define modeSwitch 2 // Mode Switch input
//init the car
void setup() {
  pinMode(PWMA, OUTPUT);     //set IO pin mode OUTPUT
  pinMode(PWMB, OUTPUT);
  pinMode(BIN, OUTPUT);
  pinMode(AIN, OUTPUT);
  pinMode(STBY, OUTPUT);
  digitalWrite(STBY, HIGH);  //Enable Motors to run
  digitalWrite(PWMA, LOW);  // Fully on 
 // digitalWrite(PWMA, HIGH);  // Fully on
}

//main loop
void loop() {
  while (digitalRead(modeSwitch) == 1)  // wait for mode switch to be pressed (go to 0)
    ;  // Do nothing

  delay(2000);

  // RIGHT WHEELS
  // Drive Right Wheels forward for 2 second  
  digitalWrite(AIN, HIGH);    // Forward direction
  digitalWrite(PWMA, HIGH);   // Full power
  delay(2000);              //delay 2000mS

  // Stop for 2 seconds
  stopTime(2000);

  // Drive Right Wheels Backwards for 2 second  
  digitalWrite(AIN, LOW);    // Backwards direction
  digitalWrite(PWMA, HIGH);   // Full power
  delay(2000);              //delay 2000mS

  // Stop for 2 seconds
  stopTime(2000);

  // Turn off Right Motor's Power
  digitalWrite(PWMA, LOW);

  // DRIVE LEFT WHEELS
  // Drive LEFT Wheels forward for 2 second  
  digitalWrite(BIN, HIGH);    // Forward direction
  digitalWrite(PWMB, HIGH);   // Full power
  delay(2000);              //delay 2000mS

  // Stop for 2 seconds
  stopTime(2000);

  // Drive Left Wheels Backwards for 2 second  
  digitalWrite(BIN, LOW);    // Forward direction
  digitalWrite(PWMB, HIGH);   // Full power
  delay(2000);              //delay 2000mS

  // Stop for 2 seconds
  stopTime(2000);

  // Drive car Forward for 1 second
  digitalWrite(AIN, HIGH);    // Forward direction on Right
  digitalWrite(BIN, HIGH);    // Forward direction on Left
  digitalWrite(PWMA, HIGH);   // Full power on Right
  digitalWrite(PWMB, HIGH);   // Full power on Left
  delay(1000);              //delay 2000mS

  // stop for 2 seconds
  stopTime(2000);

  // Drive car Backwards for 1 second1
  digitalWrite(AIN, LOW);    // Reverse direction on Right
  digitalWrite(BIN, LOW);    // Reverse direction on Left
  delay(1000);

  // stop for 2 seconds
  stopTime(2000);
  
  // All motor power off
  digitalWrite(PWMA, LOW);   // No power on Right
  digitalWrite(PWMB, LOW);   // No power on Left
}

// Function - accepts the time in milli-Seconds to go into standby for
void stopTime(int mS){
  digitalWrite(STBY, LOW);   // Go into standby
  delay(mS);                //  Wait defined time
  digitalWrite(STBY, HIGH);  //  Come out of standby
}

I don't see how the motors are getting any voltage if Vin isn't present. Yes usb will be the source of +5V  if Vin is not present but the motors supply is Vin not +5V so to me its kind of magical that they are powered on. Unless i am missing something which is always possible.  

@noweare

As I understand it so far the battery power supply in this case is connected to the USB power via a diode. When the battery is turned on with a higher voltage it turns off the diode and takes over as the power source to the motors. I assume the battery also provides power via a voltage regulator to the Arduino board when the USB connection is absent.

This is how I imagined it but it might be completely fictional.

@robotbuilder, , @noweare,

sigh.

This is playing havoc with my evaluation process. In order to do a fair evaluation of the kit, I'm trying to do the tutorial demo examples in sequence. Unfortunately, I've encountered problems on the first demo sketch. Not a good sign. Up until then I was impressed with the Elegoo build process, which went very smoothly. There are 15 tutorial demo sketches. I've already encountered the language/cultural issue in the coding style but if this is any indication of the circuit behavior, then I'm in for a rough road.

Ideally perhaps software recognition of the status of the battery being on or off?

As it turns out, the battery sensor is included on the shield and there's a usage sketch for it that we can use. It doesn't detect on-off but should give an indication of which power source is in use.

Note of diode direction - from the battery to the board; thus, it blocks backlash power from board (i.e., the UNO) to the battery.

#define VOL_MEASURE_PIN A3

unsigned long vol_measure_time = 0;

void setup() {
	Serial.begin(9600);
	voltageInit();
}

void loop()
{
	Voltage_Measure();
}

void voltageInit()
{
	pinMode(VOL_MEASURE_PIN, INPUT);
}

void Voltage_Measure()
{
	//Measured every 1000 milliseconds
	if (millis() - vol_measure_time > 1000) {
		vol_measure_time = millis();
		float voltage = (analogRead(VOL_MEASURE_PIN) * 5) * ((10 + 1.5) / 1.5) / 1024; //Read voltage value
		//float voltage = (analogRead(VOL_MEASURE_PIN) * 0.0375);
		voltage = voltage + (voltage * 0.08);

		Serial.print("Current voltage value : ");
		Serial.println(voltage);

		if (voltage > 7.8)
			Serial.println("The battery is fully charged");
		else
			Serial.println("Low battery");
	}
}

When run with the battery off and the UNO providing power it gives a measured voltage of....

...Place your bets! Place your bets!...

1. 0 volts
2. 5 volts
3. 8 volts

Current voltage value : 4.73
Low battery
Current voltage value : 4.69
Low battery
Current voltage value : 4.77

When run with the battery ON and the UNO connected afterwards it gives a measured voltage of....

...Place your bets! Place your bets!...

1. 0 volts
2. 5 volts
3. 8 volts

The battery is fully charged
Current voltage value : 8.21
The battery is fully charged
Current voltage value : 8.21
The battery is fully charged
Current voltage value : 8.21
The battery is fully charged
Current voltage value : 8.21

For me, this is a "smoking gun." I know what connection the cause is; I just don't know where it's made. Electrically, I believe it's the nearest Vin line to the UNO 5v GPIO pin.

So, when the battery is ON and the UNO connected afterwards, the UNO disables the 5v pin and the board is powered from the battery.

When the battery is OFF and the UNO connected, the 5v GPIO serves as Vin and powers the board (including the motor driver).

When the battery is OFF and the UNO connected, then the battery turned ON, the diode blocks the power from the UNO. I have to admit, I'm not sure who powers the board at that point. I think the battery wins.

@robotbuilder I don't see circuit anywhere. USB 5V and Vin do not connect on the UNO

@tfmccarthy The only way this can happen if for some reason 5 volts is getting to the vin net via a connector (maybe via the daughter card ?. I dont know but it should not be happening. Maybe elegroo has a forum so this question can be asked ? Went through the uno schematic,  usbvcc (or +5V) and Vin do not come into contact with each other. 

Posted by: @noweare

↑

@robotbuilder I don't see circuit anywhere. USB 5V and Vin do not connect on the UNO

They probably meet up on the Arduino 5v rail where the battery is connected to the rail via a 5v regulator. All pointless guess work from me so I will leave the wiring to someone who actually knows for sure and in detail.

To use the machine I would suggest that checking pin A3 for battery power as shown by @tfmccarthy as part of turning the motors on/off. That is why I would ask if there is no commands to the Hbridge motor controller to power the motors would they still turn on thus the reason to turn them off in the setup()?