Forum Replies Created
- AuthorPosts
- March 10, 2020 at 2:19 pm #7469Scott MurchisonParticipant
Got it working. I wrote one routine for CW and another for CCW. Thanks.
March 10, 2020 at 11:10 am #7464Scott MurchisonParticipantI’ll try it and report back. Thanks.
September 13, 2019 at 3:13 pm #7240Scott MurchisonParticipantThe 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 2Sabertooth 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 ST1ST2.motor(1,POWER) // for M1A (RR) on ST2
ST2.motor(2,POWER) // for M1B (LR) on ST2I 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.September 13, 2019 at 12:01 pm #7238Scott MurchisonParticipantThank 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.
September 13, 2019 at 10:22 am #7236Scott MurchisonParticipantThanks. 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.
September 12, 2019 at 11:06 am #7234Scott MurchisonParticipantI’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 signalRR = 206;
digitalWrite(Driver1Control, HIGH); // enable
mySerial1.write(RR); // send command to rotate right rear wheel
delayMicroseconds(50);
digitalWrite(Driver1Control, LOW); // disableLF = 206;
digitalWrite(Driver2Control, HIGH); // enable
mySerial1.write(LF); // send command to rotate left front wheel
delayMicroseconds(50);
digitalWrite(Driver2Control, LOW); // disableBTW, 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 - AuthorPosts