Power Conservation

[tbalatka]

Hello Y'all, On my 4WD platform, I noticed that the four BTS7960 drivers are powered on and the motors are, what appears to be, in brake mode when the robot is stationary and not receiving commands to move. This would be great when it's paused on an incline, which we have many on our farm, however after an hour or two of this the battery needs charging. I'm wondering if anybody reading this can suggest a change in the code so as to extend battery life. Any help would be most appreciated.

[tbalatka]

I did some digging. On the BTS7960, pins 3 and 4 are for enabling & disabling the forward and reverse modes. HIGH = enable, LOW = disabled. The circuit diagram shown here have both pins permanently connected to 5V (HIGH): https://github.com/linorobot/linorobot2_hardware?tab=readme-ov-filehttps://github.com/linorobot/linorobot2_hardware?tab=readme-ov-file. Other Arduino examples I have found online show the same setup. I thought that bridging pin 1 (PWM) to pin 3 and pin 2 (PWM) to pin 4 could work, but it is not recommended, so says Gemini: ..."You cannot safely or functionally bridge pin 1 to 3 and pin 2 to 4 on the standard BTS7960 module. These pins serve fundamentally different functions, and bridging them could lead to incorrect operation or damage to the module or your microcontroller " I guess I'm left with modifying the microROS code to first enable pins 3 and 4, then send PWM to pins 1 and 2, followed by disabling pins 3 and 4 when pins 1 and 2 are inactive...???

[hippo5329]

@tbalatka You may measure the load current of your robot, with/without the motors. Do you use esp32? Do you have a robot computer?

[tbalatka]

Hi Thomas, Good idea to measure the load, however even without doing that I strongly suspect that the four surplus automotive seat motors I use in my 4WD robot draw many amps, I believe believe between 5-10, when idle. I hope the following provides more information. The electronics consist of an ESP32-S mounted in a Freenove breakout board. There is also a Wyze cam, and that's it. To power it, I'm using an 8ah LiFePO4 battery connected to a solar charge controller. The robot computer is a mini PC running ROS2 that communicates with ESP32-S3 over wifi. So I'm thinking that when you add it all up, the robot should not deplete the battery that fast while it's idle waiting for /cmd_vel commands.That leads me to think that the motors draw considerable power while idle. Or maybe it's the solar charge controller, yet it stays cool while providing power to the robot's electronics and motors. Also, more telling is when the power is off, the wheels have noticle play vs when the robot is powered on. All the above points to the motors being the culprit, or more precisely, the way the motor controller modules are wired and communicate with the ESP32-S3. So If I could modify the code so that the motor controller modules are enabled before the velocity commands are sent, and then disabled after a period of time when no commands are sent and the robot sits idle, that would extend the life of the battery.

[hippo5329]

@tbalatka You may add a delay to turn off motor driver.

[tbalatka]

Good idea. Sort of like a switch that detects inactivity and then changes the logic of pins 3 and 4 to low.

[PaulBouchier]

@tbalatka - Thomas suggested you make an actual measurement to determine if the motors are being powered, and reading this thread, I don't think you've done that yet. I think you need to. You should also feel the motors to see if they're warm while the robot is idle, which would indicate power consumption. I couldn't see a way that the code could be sending power to the motors when cmd_vel is not asking for motion. Not saying it can't be so, just I couldn't see it.

Regarding your observation that "when the power is off, the wheels have noticle play vs when the robot is powered on" - the USE_SHORT_BRAKE macro defaults to true, which looks to me like it would short the motor pins together by drivng both low-side FETs on. In this condition the motor acts like a generator with shorted outputs, and will resist motion quite strongly. You could try to rotate the wheels and see if they can be turned with difficulty but don't try to move back to where they were. If so, this is the most likely explanation.

[tbalatka]

Hello Paul,

Yes, as Thomas first suggested, I will indeed check to see if the motor's are being powered while the robot is idle.

Thank you

[tbalatka]

Paul, You are bang on. I tested the voltage to the motor when the robot is idle = no voltage. And you are correct about the motor acting as a generator when turned.

I posed the following question to Gemini, "Why when I turn a motor connected to an enabled but with no PWM signal bts7960 controller there is physical resistance, but not when there is no power?" and it came back with: "The resistance you feel is due to a phenomenon called back EMF (ElectroMotive Force) and the internal circuitry of the motor driver. This is essentially an effect of dynamic braking or regenerative braking.

Here is a breakdown of why this happens:

With the Controller Enabled (No PWM)

When the BTS7960 controller is enabled (the R_EN and L_EN pins are high), its internal circuitry, including the power MOSFETs that form the H-bridge, is powered up and connected to the motor.

• When you manually turn the motor, it acts as a generator, producing an electrical voltage (back EMF).

• With the H-bridge enabled, even without a PWM signal to drive the motor, the motor's coils are connected through the low-resistance on-state of the internal MOSFETs or their integrated body diodes, creating a closed circuit loop through the driver's power supply rails.

• This closed loop allows the back EMF to drive a current through the motor windings and the driver circuitry.

• According to Lenz's Law, this induced current creates a magnetic field that opposes the original motion, resulting in a physical resistance or "braking" feeling when you try to turn the motor. The motor is effectively shorted by the active H-bridge.

With No Power (Powered Off)

When the BTS7960 motor driver board has no power supply (no main power and no 5V logic power), the internal MOSFETs are in a high-impedance (floating) state, meaning the motor leads are electrically disconnected from the main power rails and from each other.

• Although turning the motor still generates back EMF, there is no complete, low-resistance circuit for the induced current to flow through.

• Without a current to oppose the motion, there is little to no magnetic braking effect, and the motor turns freely with only minimal mechanical resistance from its bearings.

In essence, the controller's "enabled" state creates the necessary closed electrical circuit for the motor's self-generated current to flow, thus causing the noticeable resistance. When powered off, this circuit is open, and the motor spins freely.

[PaulBouchier]

Yep, that's right. Your surprisingly-high energy usage must be going elsewhere.