Asked — Edited

Sabertooth 2X60 In Simplified Serial Mode

I am using a Sabertooth 2x60 motor controller in Simplified Serial Mode and the Sabertooth programming module from the ARC program to control two tank tracks. Note that there are times when clicking one button for forward, reverse, left or right turning, that only one of the two motors turn. Note that both should turn and I do have both programmed to turn at the same time with the Sabertooth module in ARC. Most of the time, the pushing of the buttons does indeed operate both motors properly, but still there is that occasional push of a button that only one motor turns.

Any ideas as to why this sometimes happens? Are there any suggested work-a-rounds?


ARC Pro

Upgrade to ARC Pro

Become a Synthiam ARC Pro subscriber to unleash the power of easy and powerful robot programming

#1  

Double check that your wire connections from the Sabertooth to the motor that sometimes does not respond are tight. Check that the connection from the EZB to the Sabertooth is tight. Also check that your battery is fully charged.

Good luck and maybe someone else has a better idea.

#2  

I'm sure everything is tight and the battery is not the problem.

United Kingdom
#3  

What's the spec on the PC? How good is the wifi connectivity?

Movement commands for the Sabertooth use two serial commands in quick succession to move both motors, it could be that one of the serial commands is getting lost in comms somewhere.

You could try a variety of scripts which send the same commands and see if there are issues with those also, this will eliminate the Sabertooth control from the problems (however I am sure it isn't the problem since it's worked fine for many others).

I'll post some quick scripts (unless someone else beats me to it) shortly for the movements.

#4  

Are you sure you have the dip switches set correctly on the sabertooth?

#5  

how long are your wires and what do they pass next to? May want to look at shielding them. Serial connections can be susceptible to electromagnetic interference.

Probably wouldn't work at all if this were not the case, but also confirm that you have a common ground between the EZ-B and the Sabertooth.

Alan

#6  

In an initialize script set both motors to stop. This will get the communications working between both motors. I had same situation with my tracks, telling to go forward from initial boot up only one track would move. Pressing stop and then pressing forward a second time allowed both motors to drive. Or maybe give a very very slow speed command to both motors in initialize script, sleep 100, then send stop command again. Unfortunately at work or I would post my script for getting around this. Btw it does the same thing on the robo claw type controllers.

#7  

To: Rich: You bring up a lot of good points about the PC and the serial connection speed. The computer that is running ARC on is very old and slow. It is a 32 bit, Pentium 4, 2.53GHz, with 3GB of memory being used with Windows 7.

To: Richard R: I am sure the switches are set correctly. I reviewed the Sabertooth manual extensively in that area.

To: thetechguru: I believe I do have the ground common between all of the devices, but I will double check that. I don't think it is a situation with a long wire with EMI noise. Excellent ideas on everything to check though.

To: kamaroman68: By the way, I did notice that It did seem to occur more from the initial boot. Also, like you noted, by pressing stop and start a second time, the motors worked properly together. I like the idea of maybe doing something with the script to get around this problem. Where did you actually place the script? In essence, did you do it right on connect or was it run separately? Was the script placed on the servo module? Also, if you could post the script later that would help. Thanks.

#8  

@Jimwest... Forgot about that... in an initialization script send a stop command to both motors they will usually respond perfectly after that...


sendSerial(D0,38400,0) #stop command for both channels

#9  

Richard r that's almost exactly what I said. But I've found that doesn't always work hence my post. Jimwest yes do it in the boot up initialize section.

#10  

Jimwest, You may already know this but an initialization script is a special script that runs as soon as ARC starts up. What is usually placed in this start up script is settings, speeds and positions you want your motors, servos and other things to be set at as soon as the robot wakes up. It's also used to have ARC auto connect to EZB when it starts. It also a good place to set any Variables you'll be needing.

#12  

I wanted to update this thread with things that I have found that make a difference. First off, placing the sendSerial(d0,38400,0) script recommended by Richard R., kamaroman68 and others at startup helped fix the startup problem of only one motor running on a command for both motors to run from the servo control module designed for the Sabertooth motor control in Serial mode. However, I still had problems of only one motor running intermittently with commands from the servo control module.

So, after trying some other items, including looking at the output with a scope (and not seeing anything of a noise problem) I tried a cheap H-Bridge from China which quickly smoked. Once this happened, I went back to the Sabertooth serial hookup and thought about trying servo scripting for the speed and direction. I tried placing the stop code in front of the various speed codes for each motor. For example: sendSerial(d0,38400,0,90,218) This seemed to make a difference, but then I started to experience what looked like conflict issues between the servo script and the Sabertooth servo Motor Controller module in the EZB software. I also tried sendSerial(d0,38400,90,218) without the "0" stop code, but still had conflict issues. At that point I removed the Sabertooth servo Motor Controller module from the EZB build project, and had just the keyboard control module and the new script module for each motor direction movements.

Continuing on from that point, I saw that ARC software provides a Custom Movement Panel located under the tab Scripting. The nice thing about the Custom Movement Panel is that it allows you to place the script directly into the movement selection area. Once I got all the single lines of sendSerial code for forward, reverse, right and left directions (leaving out the speed variable code - though I might try to figure that out later - which might be cool to do), I then removed the individual script module called "Movement Script." At this point, the motors were running better, but every once in awhile I still had the problem, with only one motor turning when both should be moving.

I started thinking about other possible reasons that this problem was so persistent. Reading of the Sabertooth manual, it talks about baud rate settings. Note that the servo Control module for Sabertooth in EZB has a preset baud rate of 38,400, with no way that I can tell of changing the baud rate in that Sabertooth servo module. Here is what the Sabertooth manual states:

Quote:

What baud rate to use is dependent on what your host can provide and the update speed necessary. 9600 baud or 19200 baud is recommended as the best starting points. If communication is unreliable, decrease the baud rate. If communications are reliable, you may increase the baud rate. The maximum update speed on the Sabertooth is approximately 2000 commands per second. Sending characters faster than this will not cause problems, but it will not increase the responsiveness of the controller either.
See page 16 of the attached Sabertooth manual. Sabertooth 2x60 PDF

So, I tried setting the Sabertooth baud rate switch configuration to 9600 and edited the script code to 9600 instead of 38,400 and low and behold, it is working flawlessly! I tried to make it fail, by quickly switching directions, and quick touches from the keyboard control module, and it functioned perfectly!:):) :)

With that information in hand, I then tried other baud rates, after changing the switch settings on the Sabertooth and the code in the Custom Movement panel, and found that 9600 baud was always perfect, and the other speeds all glitched out with fast changes of directions from the keyboard from time to time.

By the way, I just researched the bytes per second vs the baud rate and 9600 baud, and find that it works out to be 1200 bytes per second, whereas 38400 baud works out to be 4800 bytes per second. According to the Sabertooth manual, the maximum is 2000 commands per second (or this would be equivalent to in simplified serial mode, 2000 bytes per second). Each command consists of one byte (8 bits) in simplified serial mode. Based on this information, it does not make sense that the Sabertooth would function properly at a 38400 baud rate. If that is the case, then why would the Sabertooth manufacturer offer higher baud rates if the effective baud rate is limited by the maximum of 2000 commands per second?

So, my suggestion for EZ-Robot is for the built in ARC servo Movement module for Sabertooth that there should be a means of changing the baud rate on the movement module itself. ;)

Thank you all for the help, and I found all the suggestions were excellent to get to this point in the troubleshooting of this issue.

One last point, obviously I changed the startup script to reflect the lower baud rate setting on the Sabertooth, and set it to the following value (port d0, baud 9600, and with "0" representing setting both motors at zero speed):

sendSerial(d0,9600,0) 
#13  

@Jimwest.... Good info.... I was having a few issues a while back with a sabertooth 2 x 12 doing what you described.... I'll try what you did (reduce the baud to 9600) and see if that helps....

It's funny, I use 38400 with several of my sabertooth 2 x 5 controllers without any issues at all...

#14  

@Richard R. Maybe the issue has to do with how responsive each of the controllers are based on their current carrying capabilities. In essence, Dimension Engineering probably uses the same electronic serial interface for each of their motor controls, but the ones that handle more power might not respond as quickly as the ones that are of a lower power design. I've noticed that the Sabertooth 2x60 seems to have a large inrush of current when first powering up probably due to the quick buildup of a charge of the onboard capacitors.

Just a thought.

#15  

I thought the serial command to the sabertooth to stop was 64 for motor1 and 192 for motor2.

#16  

Quote:

I thought the serial command to the sabertooth to stop was 64 for motor1 and 192 for motor2.
@Purple... Yes for each motor individually, but there is also a special case scenario of using a "0" zero to stop both motors at the same time. See page 16 of the manual:

Quote:

Because Sabertooth controls two motors with one 8 byte character, when operating in Simplified Serial mode, each motor has 7 bits of resolution. Sending a character between 1 and 127 will control motor 1. 1 is full reverse, 64 is stop and 127 is full forward. Sending a character between 128 and 255 will control motor 2. 128 is full reverse, 192 is stop and 255 is full forward. Character 0 (hex 0x00) is a special case. Sending this character will shut down both motors.

In essence, the following two lines of code should do the same thing:

sendSerial(d0,9600,0)
sendSerial(d0,9600,64,192)
#18  

@Jimwest.... OMG THANK YOU! my eyes are burning from reading every thing on Sabertooth @ ez-robot and @dimensionengineering all day.

I got soo excited to get my wheelchair to respond to my app and key strokes. but then realized that motor movement was incorrect and 1 or the other was actually null.

I'm not sure about where to write code to fix the baud rate like you did.... "One last point, obviously I changed the startup script to reflect the lower baud rate setting on the Sabertooth, and set it to the following value (port d0, baud 9600, and with "0" representing setting both motors at zero speed):" I'm more the hardware guy and software is where the magic happens... CAN YOU PLEASE help?

thank you soo much for keeping us posted otherwise Ild still be bleeding from the eyeballs.