Hi. I have Dual G2 18v22 motor controllers powered by 24v Li-Ion batteries. The motor controllers power Raspberry Pi 4B 8Gs (via their 40-pin headers), and a single motor per controller. The power to the Raspberry Pi is always solid. However when setting the motor speed, either forward or reverse, the green LED (forward indicator) or red LED (reverse) are initially solid, but then begin dimly flickering after several seconds. The motor doesn’t get enough power to turn when the LEDs are flickering. Often the flickering will stop after a few seconds and will turn solid again and power the motor. The LEDs show the same symptoms whether the motor is connected or disconnected. This same setup was working one 2 separate systems for months before this started happening on one of the systems.
In case this is a clue: the system that is still working doesn’t work when using a Raspberry Pi 4B 2G (fails with the same symptoms described above). All configurations use the same model batteries and motors.
To clarify the last point, what is the model of the Raspberry Pi in the working system, and if you swap the Raspberry Pis between the two systems, does the problem follow the driver or the Raspberry Pi? Are you sure that there are not any other differences between the two setups?
Along that same line of thinking, did you make any changes to the problematic setup between when it was working and when you started seeing this behavior?
Please post some pictures of your setup that show all of your connections along with information about the motors you are using. (A datasheet or product page link for the motors would be ideal.) Do you see the same behavior if test the driver with the motors disconnected, and does the driver report any faults if you test it with the example program from our G2 High-Power Motor Driver Python library?
Clarification: if I swap the Raspberry Pis between the two systems, the problem follows the Raspberry Pi. However note that there are 2 cases with the same Pi model (both 4b 8G): one works fine all the time, the other works for short time spans. These 2 cases represent two complete systems - 2 motor driver boards, two batteries - however the motor drivers and batteries (and the 2 Pis) are all the same models for the same component in each of the 2 systems.
I don’t know of any event that caused the aberrant behavior. In the case of the system with the 4b 8G Pi that works only sporadically, this system was working fine for about 6 months and progressively got worse. Since the purpose of this system was software development on the Pi, the motor was never loaded, and different power levels were used at various times for test (but the use of different power levels doesn’t seem to correlate with the gradual degradation).
I see the exact same behavior with the motor disconnected (I only use one of the 2 channels)
If you can swap the Raspberry Pi, keep everything else the same, and the problem follows the Pi, then the Pi is likely the source of the problem as opposed tot he driver or some other part of your system. You mentioned that you are using the problematic Raspberry Pi for software development, is it possible you have other software or configuration changes that could be interfering with the GPIO pins used to control the driver?
We have heard cases of software updates causing pigpio to not work correctly, so one thing you could try is carefully reinstalling pigpio. However, if that does not work, then the next move is probably to get a better idea of what the GPIO pins on your Rasberry Pi are actually doing by looking at them with an oscilloscope.
Another thing you can do to do narrow the cause down more confidently is swap the SD cards for your Raspberry Pis and see if the problem follows the card. If it does, then there is definitely some difference in the OS/software setup.
If there is nothing on the problematic card that you want to keep, then one easy fix might be to clone the good one to the other one (create a disk image of the good card and write it to the other one). Otherwise, you probably need to try to investigate what might be different. Checking that the system packages and the libraries installed on both cards are fully up to date or at least have the same software versions might be a good start.
Regarding other software that could interfer: I can’t imagine that’s the case since the software development I mentioned is only for this particular project and the only thing I install, other than my own scripts for the application, is pigpio. Our application scripts won’t work at all unless the pigpio service is running, so I’m certain it’s both running and working.
The problem doesn’t follow the card. I’ve got both microSDs and USB Jumpdrives from which I boot - all with the same scripts we write (and all with the pigpio service running) and the problem depends on which Pi we’re using, rather than which card/jumpdrive it boots from.
An O-Scope is a good suggestion and something I’m planning once I get my hands on one.
Looking at the choices for the motor and at the battery, I take it nothing there jumped out at you as problematic? (I believe the parts are compatible but just wanted to see if you agree)
Thanks again! I honestly wasn’t expecting this level of support… it’s excellent!!
Unfortunately, that makes it seem likely that somehow the hardware for some of your GPIO pins on the problematic Raspberry Pi has been damaged. Looking at the pins with a scope once you are able to access one would still be a good way to confirm that though.
As for your battery and motor selection, I think you are probably pushing the limits of what this driver can reliably handle, but it might be okay if you careful. Maybe the fact that your systems were working without incident for several months is evidence of that you are taking appropriate precautions and your setup is fine, but for reference, here is what we would typically recommend:
Motor: Your motor’s datasheet lists a stall current over 70A motor, so we would typically recommend using a driver or controller that can continuously handle that much current, like one of the RoboClaw or MCP motor controllers since the motor will draw its stall current whenever it starts up or switches direction. However, as mentioned on their product pages under the “Real-world power dissipation considerations” header, the G2 High-Power Motor Drivers can handle high transients, so they might be okay considering that you are not loading the motor in your application, and you could further reduce the risk of problems by limiting your motor’s acceleration and deceleration rates, using the board’s current sensing and limiting features, and adding appropriate fuses to your circuit.
I am not sure why changing the PWM frequency makes behavior like this go away, but I am glad to hear that it is working for you now! Thanks for letting us know.
