EasyGoPiGo3's stop() method does not turn off power to the motors

GoPiGo OS, DexterOS and Bloxter
1

I noticed an interesting thing while working on my joystick project.

The stop() method in EasyGoPiGo3 does not release the motors.

If you do anything using the easygopigo library that runs the motors, the motors still have power applied even after the stop() method has been called, and even after the program has stopped.

Apparently, the easygopigo stop method does not put the motor driver “to sleep” in the same way you can turn off power to the servos.

Viz.:

    def stop(self):
        """
        This method stops the `GoPiGo3`_ from moving.
        It brings the `GoPiGo3`_ to a full stop.

        .. note::

             This method is used in conjuction with the following methods:

                 * :py:meth:`~easygopigo3.EasyGoPiGo3.backward`
                 * :py:meth:`~easygopigo3.EasyGoPiGo3.right`
                 * :py:meth:`~easygopigo3.EasyGoPiGo3.left`
                 * :py:meth:`~easygopigo3.EasyGoPiGo3.forward`

        """
        self.set_motor_dps(self.MOTOR_LEFT + self.MOTOR_RIGHT, 0)

In order to have the stop method turn off power to the motors, you need the following line added at the very end:

        self.set_motor_power(self.MOTOR_LEFT + self.MOTOR_RIGHT, -128)

Adding that to the stop method of the easygopigo library should save you serious battery if you have the robot moving around and then stopping.

2 Likes
2

I’m running a test now that includes:

  • cold boot
  • 1 minute settle time after test program initiation
  • 5 minute load and power usage before first motor use
     
  • drive_cm(10) for first motor usage
  • 5 minutes load and power usage after drive_cm() usage
     
  • sending set_motor_power(left&right, -128)
  • 5 minutes load and power usage after drive_cm() and power off cmd
     
  • drive forward() for 1 second
  • 5 minute load and power usage after forward() command
     
  • sending set_motor_power(left&right, -128)
  • 5 minutes load and power usage after forward() and power off cmd

Not sure if 5 minutes will be enough to show the power usage difference. It’s a best effort at a controlled test for my fellow DM (Robot Dungeon Master).

2 Likes
3

BTW, (MOTOR_LEFT + MOTOR_ RIGHT) = 3

I have to add useless explanatory text before the forum will allow me to post it, otherwise it responds with “Body seems unclear. Is it a complete sentence?” and refuses to allow me to post the message.

1 Like
4

( MOTOR_FLOAT is defined in GoPiGo3 class, so test was valid)

[Redacted] and restored.

RESULT

Absolutely no difference detected in load or power consumption
with or without the set_motor_power(Left&Right,-128)
after either drive_cm(10) or forward()

  • with a 10mA precision ammeter,
  • nor with a 1mW instantaneous Power meter,
  • nor with 1mAH precision Power-over-Time meter

I’m working on condensing the 27 minute videos of the test so you can judge for yourself if you can see a difference.

It would appear from my test that any resting current would have to be less than 10mA. For Carl with a 7 hour 1800mAH normal playtime, a 10mA savings would be roughly 17 minutes extra minutes.

I think to prove this, you will need to put a voltmeter across the motors to be sure there is a voltage applied, and then repeatedly perform endurance tests with and without the power off command, to get an average with and an average without and see if the averages show significant difference.

2 Likes
5

I used your code:

self.set_motor_power(self.MOTOR_LEFT + self.MOTOR_RIGHT, self.MOTOR_FLOAT)

The test code: OOPS MOTOR_FLOAT Is defined in the GoPiGo3 base class, so no issue.

2 Likes
6

NEW RESULT

TLDR;) - Inconclusive, or no proof stop_with_power_off() saves energy over stop()

New run with class constant MOTOR_FLOAT=-128, new code here

Voltage   Current(Amps)    Power(Watts)
11.8         0.47            5.655    boot, no drive commands yet           

11.7         0.48            5.635    immediately after drive_cm(10)
11.6         0.48            5.616    after 5 minutes

11.6         0.47            5.494    immediately after stop_with_power_off()
11.6         0.47            5.475    after 5 minutes

11.6         0.48            5.577    immediately after forward() for 1 second, then regular stop()
11.5         0.48            5.553    after 5 minutes

11.5         0.48            5.548    immediately after stop_with_power_off()
11.5         0.48            5.524    after 5 minutes
  • The power consumption was trending down consistently during all 5 minute dwell times indicating a consistent 2mA drop in load per 5 minutes.
    ( start watts - end watts) / average voltage
  • The power_off, 5 minutes after a drive_cm() could indicate a 10mA drop:
    (5.616W-5.494W)/11.6v
    but the precision of the measurements and the single test prevent confidence in the value.
  • The power_off, 5 minutes after a forward() could indicate a 1mA drop:
    (5.553W-5.548W)/11.5
    but the precision of the measurements is not sufficient to be certain.

CONCLUSION: Test does not prove stop_with_power_off() will have a measurable effect on playtime.

I have another meter that has 1mA load precision (instead of 10mA load precision), and 10mV voltage precision (instead of 100mV), that I will use for a second run of the test tomorrow. Sometimes the additional precision just bounces around too much to be of value, but it will be interesting regardless.

2 Likes
7

Very interesting!

Did you notice that prior to shutting power off to the motors that they were “locked”, (i.e. could not be turned), but after shutting off power the motors free-wheeled?

These results are totally counter-intuitive as one would expect that sending power to the motor to lock it would actually “consume power” - and the power consumed would be distinct and measurable.

Can you provide details about your setup, perhaps including a schematic?

One thing I am tempted to do is create a fixture that will allow me to place an amp-meter in series with the power leads.

(!!! - :man_facepalming: )

Remembering the fancy supply I built, (and how could I forget it?!!), I attached it to Charlie and ran both ways.

The results were, (being generous), inconclusive.

The measured current draw was about 0.3± amps at 12 volts, with a variation of almost a tenth of an amp.  It appeared to trend higher with power being delivered to the motors, but the variation was so high that it was impossible to distinguish a real trend from the noise.

Visually, there appeared to be about a 0.05 - 0.10 increase in current draw for the motors being driven at 300 dps in free air, (not actually moving the robot.), with about a 0.05 amp increase if the motors are not being allowed to free-wheel when stopped.

Conclusion:
If I have to filter the results using Bessel functions to see whats happening, the results aren’t worth talking about!

Interesting observation:
The current draw of the robot as measured at the 12 volt battery terminal with no other external attachments, (monitor, keyboard, joystick, etc.), was extremely noisy, though the voltage as measured was rock-solid.

It would be interesting to try filtering the power using a few μhenry inductor - or a pi filter, (no pun intended) - to see what’s actually happening.

Additionally, it would be interesting to research where all this current noise is coming from - but that’s absolutely out of scope for me at the present time.

@cyclicalobsessive,

Did you notice any significant current noise in your measurements?

1 Like
8

MotorWarning

NO, NO - Not only didn’t I check that, the mere mention causes me to cringe. In addition to the sticker on the motors saying “WARNING: Do not turn wheels by hand.”, when Dave was brand new I wanted to run all the Dexter tests, one of which is an encoder test that instructs you to turn the wheels - I could feel that attempting to turn the encoders via the wheels was not a good idea. (I do remember running that test on Carl some years before and the wheels turned easily.)

OK - curiosity got the best of me - checked it and indeed the wheels turn freely after the test which issued a power off in the last phase.

As a general purpose multi-tasking OS, Pi OS is constantly nudging different processes from sleep, with the concomitant variable frequency processor clock trying to respond quickly to meet increasing load.

Right now in the current poweroff_easygopigo3 test, “idling”, the current bounces between 0.279A and 0.285A with spikes to 0.345A. Of course this is not a bare machine test - I have a number of user processes running in addition to the pages and pages of system processes running.

Battery->barrel-cable-to-USB-plug->
  -> Power Meter->  
  -> USB cable to barrel plug3-way power splitter cable->
      -> to GoPiGo3 red board
      -> (to 5v buck normally but disconnected for this test)
      -> Socket unused
2 Likes
9

The real danger of that is “forcing” the motors, not turning them.

If the motor does not turn easily when you try to move the wheels, then don’t force them.

That sticker is a great idea for those who don’t know the difference between a gentle nudge and using a breaker-bar, as the typical classroom often is.

My system’s variation was over a tenth of an amp idling, and even more so when the wheels were running, and I don’t have a zillion processes running like you do - just the “plain vanilla” GoPiGo OS stuff.

2 Likes
10

RESULTS

  • Power Off after drive_cm again showed 10mA reduction resulting in 6mWh difference in 5 minutes
  • Power Off after foward() again showed -1mA to +1mA change with no difference in 5 minute mWh consumption
  • Confirmed wheels can easily turn motors at end of test (after final power off)
  • Note: turns, spins, and orbits were not tested

These results suggest if all motion was via drive_cm/drive_inches commands (which do not require stop() btw), then 72mW per hour could be saved by sending a power_off after the drive_cm/drive_inches commands, which translates to an additional 8.4 minutes of playtime:

  • 7h 8m vs 7h for 25wH battery consumption.
     

The results seem to suggest if all motion is via forward()/backward() followed by sleep(x), stop(), power_off(), then no additional playtime will be granted.

 

This “GoPiGo3 Mythbuster” calls the hypothesis “True, in some cases …”

27 minute video and extracted measurements available on request - I gotta get away from the keyboard now for my Monday 5k.

2 Likes
11

Here are the measurements for the second test run (same result as first):

GoPiGo3_Power_Off_vs_Stop
GoPiGo3_Power_Off_vs_Stop1185×775 139 KB

Code and results on GitHub

2 Likes
12

Well, there goes my fine theory down the tubes.  You might want to look up “Falsification by experiment”.  The name’s strange but what it means is “you had a fine theory, but my experimental evidence poured sand all over your barbecue.”

Are you going to publish this on the GitHub issue?

2 Likes
13

No, I’m not getting involved in the issue.

My interest was to see if you had discovered a “GoPiGo3 Fountain Of Youth”.

You correctly identified that something is going on, and gave me an explanation why I couldn’t run the encoder test on Dave. (Would have worked if I tried the encoder test before the motor test.)

Thank you for putting to rest one mystery-of-the-universe unbalancing my world.

3 Likes