No. Checking the battery is not the cause, initializing the EasyGoPiGo3 a second time is the issue.
The sequence is:
Program A (findDock.py) instantiates EasyGoPiGo3 object (sets default speed = 150)
Program A sets a custom “default speed” value with egpg.set_speed(120)
… findDock.py executes .drive_cm() with the reduced default speed of 120. Life is good…
Some time later I start Program B (status.py) to monitor the battery and distance sensor readings. This program also instantiates an EasyGoPiGo3 object (to get access to the volt() method and the distance sensor). This program will not use the motors at all, but the effect of the init method of the class sets default_speed back to 150.
…findDock.py is unaware that it was affected by the status.py initialization and uses speed 150.
The init method of the EasyGoPiGo3 class doesn’t (can’t?) check to see if there is already an instance of this object to know that the existing object should not be (re)initialized.
Perhaps I should not be thinking about this as sharing an object and instance variables at all. Maybe I need to look at it as the separate GoPiGo3 controller hardware and state variables that are getting re-initialized by multiple EasyGoPiGo3 objects.
I understand my use-case is not the norm, so no one planned to have the EasyGoPiGo3 object query the GoPiGo3 controller to see if it has been initialized, and not initialize it multiple times. I can work around this now that I understand what is happening.
Please do not take my observations as complaints about the design choices made for the GoPiGo and software. Now that I understand better, I can improve my use of this great platform.