Forum Replies Created

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • #7469
     Scott Murchison
    Participant

    Got it working. I wrote one routine for CW and another for CCW. Thanks.

    #7464
     Scott Murchison
    Participant

    I’ll try it and report back. Thanks.

    #7240
     Scott Murchison
    Participant

    The Packetized Serial Mode, although more complex, looks enticing to use. Correct me if I am wrong, but it is already scaled to -127 (full speed reverse) to 127 (full speed forward) and each wheel can be controlled individually. Let me see if I have this right.

    #include <Sabertooth.h>

    #define RF 1
    #define LF 2
    #define RR 1
    #define LR 2

    Sabertooth ST1(128) // for first Sabertooth driver, set the address bits to 128
    Sabertooth ST2(129) // for second Sabertooth driver, set the address bits to 129

    // commands will look like this
    ST1.motor(1,POWER) // for M1A (RF) on ST1
    ST1.motor(2,POWER) // for M1B (LF) on ST1

    ST2.motor(1,POWER) // for M1A (RR) on ST2
    ST2.motor(2,POWER) // for M1B (LR) on ST2

    I can change the individual motor power setting to compensate for differences between motors

    Therefore, to move to the left, I would have a subroutine that looks like this.

    void MoveLeft(int power){
    // all motors get the same power to move directly left
    ST1.motor(RF,POWER);
    ST2.motor(LR,POWER);
    ST1.motor(LF,-1*POWER);
    ST2.motor(RR,-1*POWER);
    }
    where power equates to speed and the individual power numbers can be slightly different for each motor to compensate for differences.

    #7238
     Scott Murchison
    Participant

    Thank you for the explanation. It does make sense and it does help. In my case, I plan to use an OpenMV camera to locate a target position on the floor beneath the robot. Their software finds the target, say an Apriltag, and tells me where the center of it is in the FOV, along with its rotation angle. By simple math, I can determine what angle I need to move the robot over top that Apriltag. Whereas an RC controller gives three signals, I’ll have just my calculation and I have to figure out how much power to give the two pairs of motors to move in the right direction. That’s the secret sauce. While the robot is moving, I can keep update the robot position with respect to the Apriltag and tweak the motor settings.

    There is still the issue of calibrating the wheel pairs such that I compensate for any speed differences between the motors. I have found that if I send each motor 100 for 5 seconds, they don’t end up in the same place. I may have to adjust one motor to say 98 to get them to the same distance.

    #7236
     Scott Murchison
    Participant

    Thanks. I’ve done many Arduino projects, many with stepper motors, but this is the first with mecanum wheels. I have to get my head wrapped around the concept. Given that the wheel speeds aren’t all the same, I still have to tweak the numbers for some of them.

    Also, since I’m not using RC, I’m finding it hard to understand how or if I need to incorporate strafe, drive and turn signals. i understand that these would come from the joystick(s) on the remote, but in my case, I will use other means to navigate. I’ll have the stock routines for moving fwd, rev, left, right, turn cw, turn ccw and beyond that, I’ll just need the math for moving off at a different angle, say 37 degrees.

    #7234
     Scott Murchison
    Participant

    I’m wishing now that I had purchased the encoder version of the motors. Had I known about this problem, I would have. In any event, your explanation makes sense and I will work on a formula to compensate for the differences between the wheel pairs. The original reason that I did not go with encoders is because I plan to use a camera on the robot facing down to identify April Tags or barcodes on the floor, which identify where I want the robot to end up. The visual feedback coupled with live calculations for vectoring will guide the robot to be centered over the symbol. I didn’t expect to run into differences in the motors.

    My robot is going to run on a smooth hard floor or flat carpet (in an office), so there will be no terrain changes.

    I’m using an Arduino to run the robot. Here is a partial sample of code to show how I am moving a motor pair. Does this look right to you? In this case, I have reversed the polarity of one motor so that I can give both motors the same value. Once I figure out the numbers I need to compenste for speed differences, I’ll incorporate them into the values, in this case, for RR and LF.

    #define Driver1Control 4 // control signal
    #define Driver2Control 5 // control signal

    RR = 206;
    digitalWrite(Driver1Control, HIGH); // enable
    mySerial1.write(RR); // send command to rotate right rear wheel
    delayMicroseconds(50);
    digitalWrite(Driver1Control, LOW); // disable

    LF = 206;
    digitalWrite(Driver2Control, HIGH); // enable
    mySerial1.write(LF); // send command to rotate left front wheel
    delayMicroseconds(50);
    digitalWrite(Driver2Control, LOW); // disable

    BTW, I wasn’t able to send int 0 to stop all motors, so I re-wrote the stop code to look like this.

    digitalWrite(Driver1Control, HIGH); // enable
    digitalWrite(Driver2Control, HIGH); // enable
    mySerial1.write((byte)0x0); // send command to stop all wheels
    delayMicroseconds(50);
    digitalWrite(Driver1Control, LOW); // disable
    digitalWrite(Driver2Control, LOW); // disable

Viewing 6 posts - 1 through 6 (of 6 total)