hi,
I have an Equipment request:
a portsplitter for motors,
looping through all pins for the master encoder motor
and branching just the pins 1+2 for the H-Bridge, not the rest, for a slave motor (in order not to muddle up the encoder signals)
by that we could use 2 Lego motors parallely to be driven by identical pwm signals, e.g. on 1 common axle for a stronger propulsion, because the BrickPi3 H-Bridges will surely serve enough power for both motors simultaneously on each single motor port
The BrickPi3 was designed to run one motor on each motor port. Although each H-Bridge should be able to handle 2 motors on a port under normal running conditions, it really wasn’t designed to do so (no guarantees). Rather than making a splitter that shares pins 1 and 2 with a second motor, I think a software solution with each motor plugged into it’s own BrickPi3 motor port would be preferable. This can either be done in user code (custom algorithms) or even by using the firmware motor control (e.g. with the firmware controlled target position control) as long as you make sure both encoders are equal (using offset_motor_encoder), and then you set both motors to the same target position (either the encoders and target need to be equal, or the target needs to be equivalent so the motors don’t fight each other). For reading the encoder position in user code, you could either use one or the other, or you could average the two.
then actually for all motors individually to 1 single port each it would cost too much:
all axles of my robot (propulsion + 5 DOFs of the robot arm) are driven by 2 Lego motors each, so over all 7 axles x2 = 14 motors, plus 3-4 single motors for lighter load.
Only when being able to plug all doubled motors at 1 port each it would be feasable and eventually finaceable.
Like I said, the configuration you described will probably work, I just recommend doing it the way I described. For such a custom application-specific need, perhaps you could cut and solder together some cables.
