(A few months late in posting this)
Plan was to pivot to using multiple SPI channels from the Pi to the MCUs versus running through one.
I realised Pi 5 has a different approach than the earlier versions with limited access to SPI buses and the peripherals available on the GPIO.
Now I can understand why others have not embraced the use of the Pi 5 over the earlier models.
Pivoted to Pi 4B, was quite quick just reduplicating what I’d done on the 5, the only change was enabling SPI1.
Can run 2 SPI buses with 2 MCUs for SPI0, and use SPI1 for the third MCU.
Adjusting the telepresence program to work was mostly straight forward.
Mostly, in that I had an issue with one motor not starting reliably.
Once I put another motor on the bus and tried to use that it worked fine, should’ve tried that sooner.
It’s still not clear why the motor wasn’t behaving as expected.
I ended up making another small tool for control of one motor at a time to help work through the problem.
It allowed me to configure the bus setup, select and connect to an individual motor, then control with different gains for either Torque, Speed, or Position. Somewhat recreating a stripped down version of the SteadyWinMotor windows program but running on the Pi, and without the random hang-ups. It definitely made trialling different things easier than changing magic numbers in the code.
Add some screenshots of the program.
The tool allows:
- motor selection from the drop down
- connect and disconnect from the motor
- start, stop, and homing of the motor (helpful for when the motor starts running away)
- Status of the motor, and its dynamics
- Max limits for each mode, symmetric about zero
- Mode selection
- Slider and value of target command
Through the testing I observed that the GIM4310-36 motors require ~7Nm of torque to begin moving, less than that and it would at least appear static. The GIM8115-9 motors didn’t have this problem. The GIM4310-36 does have a much bigger gearbox so more static friction is expected. If the numbers are true values (still something to be verified) that’s still quite a jump. An effective dead-band around zero will need to be accounted for in the software.
I followed up with the motor starting issue with Steady Win, I got a bit of a dismissive reply which didn’t solve the issue. Haven’t got any further info on this back yet. Whilst the motor hardware seems ok, I’m beginning to question the motor controller and it’s software an increasing amount, and whether its usefulness is going to outweigh its “quirks”.
Alternatives, compatible with the motors, are available. These are based on the MIT driver from Ben Katz. This has a basic interface which could give me an easier path to a minimum viable product (MVP) but would require a readjustment of the existing libraries. More testing is needed with the Comms board once it has arrived.
Leave a Reply