jimwest
USA
Asked
— Edited
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?
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.
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.
You might need a level converter like THIS
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:
See page 16 of the attached Sabertooth manual. Sabertooth 2x60 PDFSo, 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):
@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...
@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.
I thought the serial command to the sabertooth to stop was 64 for motor1 and 192 for motor2.
In essence, the following two lines of code should do the same thing: