Page 1 of 1

2x7A motor controller: unreliable response to packet serial commands from RasPi

Posted: Mon Apr 15, 2019 10:48 am
by andre
I am using RoboClaw'sPython library to drive two 2x7A's from my Raspberry Pi. But, the motors' actual movement is flakey. I've condensed the problem down to a test case, with the code below. This test case just runs all motors forward for 2 seconds, stops for two seconds, runs them backward for two seconds, and repeats.

Running this code, the motors will usually respond correctly for a few commands, and then one of the motors will fail to respond to a command within 30 seconds or so. For example, the motors will be running, but not all of them will stop for the stop command. It's not always the same motor that fails to respond to a command -- it's unpredictable.

Note that the code shows 9600 baud communication, but I've tried it at the default 38400 and a few other speeds, with the same results. The initial setup is all based on the Packet Serial Bus Operation article.

Any help would be appreciated! Trying to stop my robot from running into walls ...

Code: Select all

from libs.roboclaw import Roboclaw
import time

class Motors(object):
    # motor controller addresses
    c1=128
    c2=129

    def __init__(self):
        self.roboclaw = Roboclaw("/dev/ttyS0", 9600)
        self.roboclaw.Open()

    # Takes 4 values, representing speed for [front left, front right, back left, back right], and an optional acceleration arg.
    # Each speed value should range from -128 (full reverse) to 128 (full forward). Pass 0 to stop the wheel
    def move(self, fl, fr, bl, br, accel = 30000 ):

        duty_factor = 259.9 # 128 will give you duty value of 32760, which is top speed forward

        self.roboclaw.DutyAccelM1M2(self.c1, accel, int(fl * duty_factor), accel, int(fr * duty_factor))
        self.roboclaw.DutyAccelM1M2(self.c2, accel, int(br * duty_factor), accel, int(bl * duty_factor))


if __name__ == '__main__':
    m = Motors()

    while True:
        t = time.clock()
        m.move(64,64,64,64)
        print("call to m.move() took {:d} milliseconds".format(int((time.clock()-t)*1000)))
        time.sleep(2)

        t = time.clock()
        m.move(0,0,0,0)
        print("call to m.move() took {:d} milliseconds".format(int((time.clock() - t) * 1000)))
        time.sleep(2)

        t = time.clock()
        m.move(-64,-64,-64,-64)
        print("call to m.move() took {:d} milliseconds".format(int((time.clock() - t) * 1000)))
        time.sleep(2)

        t = time.clock()
        m.move(0,0,0,0)
        print("call to m.move() took {:d} milliseconds".format(int((time.clock() - t) * 1000)))
        time.sleep(2)

Re: 2x7A motor controller: unreliable response to packet serial commands from RasPi

Posted: Tue Apr 16, 2019 12:26 pm
by Basicmicro Support
1. Check your firmware version. Make sure you are up to date.
2. You should add code to check the return value from the Duty commands. This should indicate if the command failed or not and you should retry atleast once in that case.
3. I would not recommend using 9600 bps. Change to 57600 or higher.
4. You can set a packet serial timeout setting. If a new byte is not received in that timelimit the motors will stop automatically. The setting is in General Settings in Motion Studio under the serial baud rate setting.

Out of all this you will probably need to add some code to the roboclaw library to try to determine why a command is failing. The return value just tells you it did fail.

Re: 2x7A motor controller: unreliable response to packet serial commands from RasPi

Posted: Wed Apr 17, 2019 12:54 pm
by andre
Hi, thanks for the response.

So, I just switched over to your pre-release Python 3 version of roboclaw.py, and it seems to have cleared up all the problems. Previously I was using this suggested change to roboclaw.py for Python 3.

So I'm good for now. If problems crop up again, I'll go through your troubleshooting steps. Thanks!

Re: 2x7A motor controller: unreliable response to packet serial commands from RasPi

Posted: Fri Apr 19, 2019 9:46 am
by Basicmicro Support
Yes, the old suggested modifications to get the python working with Python 3 had issues and were unsupported. We havent officially released the final Python 3 library but you can always ask for it from support@basicmicro.com