The GoPiGo3 firmware does not really support a multi-process architecture. There are some features that are mutex protected to allow multiple processes to command or access GoPiGo3 features, but the GoPiGo3 board does not maintain a complete set of state variables needed for the multi-process use case.
A supported example would be the encoders. Multiple processes can read the encoder values, and I think the current speed of each wheel, and motor statuses.
An unsupported example is the servo package. The GoPiGo3 board only has a set command for the servo, no get command for current angle, (or last angle command if the servo is now off). For two independent processes to use the servo, they should have a mutex protected set and hold command, and a get status command that returns [bool_powered, deg_last_angle_command].
That way, if one process needed a forward range measurement from the distance sensor mounted on the servo package, and another process wanted to perform a scan, each could grab the servo mutex, re-orient the servo, take a reading and then release the servo mutex.
A way this could be accomplished (without requiring a DI firmware change) would be for bot owners to put a single marshaling process over the GoPiGo and have all processes message command and status requests to the marshaling process.
Then again, this is exactly why ROS was invented, so why reinvent the whole mess.