EasyGoPiGo3(use_mutex=True) Multiple Python Initializations

I would like to verify my understanding of the Python EasyGoPiGo3(use_mutex=True) object when there are multiple processes/jobs instantiating the class.

Is it correct that there is actually only one instance and one set of instance variables across all processes?

The value of all existing instance variables is reset to default values by the last process to initialize (wheel dia, base, default speed, use_mutex)?

In my new programs I am setting the speed slow for better turning and driving accuracy. I have noticed the default speed change after I ran a battery check program, (which I wrote very early, and does not configure the instance). I need to review all my early utilities and include myconfig.setParameters(egpg) in each.

As far as I know, you can instantiate as many objects of the EasyGoPiGo3 class as you want. I never actually tried that though, but it should work by design.

In my new programs I am setting the speed slow for better turning and driving accuracy. I have noticed the default speed change after I ran a battery check program, (which I wrote very early, and does not configure the instance). I need to review all my early utilities and include myconfig.setParameters(egpg) in each.

You are saying that after just checking the battery level of the GoPiGo3 by using its API, the default speed changes? I don’t think that should happen.

You should think of all these instances of the EasyGoPiGo3 class as just end-points that all of them have access to a common resource - the GoPiGo3 robot. In this fashion, everything that is issued to the GoPiGo3 is processed in a sequential manner, no matter how the processes on the Raspberry Pi are being run.

No. Checking the battery is not the cause, initializing the EasyGoPiGo3 a second time is the issue.

The sequence is:

  1. Program A (findDock.py) instantiates EasyGoPiGo3 object (sets default speed = 150)

  2. 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…

  3. 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.