Sabertooth -botboard communication

I’m having some issues with my rover’s motor controller. It is all standard stuff from the rover kit.

Often, the bot board and the sabertooth don’t seem to communicate. I need to turn on the controller just a split second before the sabertooth, or other wise around to get it to work, I can’t figure out quite which. It is not always a big deal, but sometimes it takes 3-4 resets to get it to work correctly. It’s done it since I got it, and figured that was just how it w0orked, but today I’m having a hard time getting it to go at all. It always lights up normally, the motors just don’t always spin. I haven’t seen this on the forum anywhere, is this a problem unique to me, or intended in the hardware? (thinking about those old mac 2’s that needed the monitor on before the cpu or the drivers wouldn’t run) Is this a timing issue? or are my dips messed up? Thanks for any input!

Hmmm! maybe you should post your dip switch settings. :wink: Other board jumper settings as well.

1 Disable Mixed Mode
2 Disable Exponential
3 Non-Lithium Mode
4 R/C Flip Mode
5 Disable Autocalibrate
6 Disable Timeout

or in other words
off
off
on
on
off
off

which agrees with tutorial, other than mixed or independent mode. Its not code, because it does it with every program I’ve run, no matter how simple. I write pulseout 3500 as a main routine and sometimes the motor spins, sometimes it doesn’t. strange eh? it always goes eventually - I tried again today and it went on the second try. I’m recharging all the batteries and will give it another go in a day or so. The motor batteries were pretty close to shot, though they had seemed fine during my tests before.

hm never really thought of it before, but how does that timeout work. if it doesn’t get any pulses at all turns the board off? does it restart itself when pulses appear? wondering now if the dip might be over but not ALL the way over, hard to see inside the case. (I had the brilliant idea of putting hinges on the lid so I could open it… then added a second deck. Now the deck won’t let the lid hinge!)

3500? Can you please post your code? In what context is 3500 used for creating servo pulses?

What is your program supposed to do? Is it autonomous? Going to need to see your code.

sure, but from everything I’ve seen the sabertooth doesn’t use standard servo pulses, or that the timing is different when using pulseout? The provided sample code shows 3000 as centered, ~2000 as full forward and ~4000 as full reverse, and this seems the same on my set up. So 3500 should be slightly reversed. The code works, I’m running it around nicely right now. It just takes a few resets to start up most of the time. This is a fairly standard PS2 control set up, using one of the push buttons for “turbo mode” to speed it up, and writing all sorts of junk to a serial LCD.

'PS2 Controller / BotBoard II
DAT con P12
CMD con P13
SEL con P14
CLK con P15


index var byte
temp var byte(18)
mode var byte

rhori var word
rvert var word
lhori var word
lvert var word
lmotor var sword
rmotor var sword
boost var byte
circlelast var bit
squarelast var bit
displaybutton var word
displayvalue var word

'---------------------------------------------------------------------

high CLK

test
low SEL
shiftout CMD,CLK,FASTLSBPRE,$1\8,$43\8,$0\8,$1\8,$0\8] ;Config Enable
high SEL

low SEL
shiftout CMD,CLK,FASTLSBPRE,$01\8,$44\8,$00\8,$01\8,$03\8,$00\8,$00\8,$00\8,$00\8] ;Set Mode and Fix(Analog
high SEL

pause 100

low SEL
shiftout CMD,CLK,FASTLSBPRE,$01\8,$4D\8,$00\8,$00\8,$01\8,$ff\8,$ff\8,$ff\8,$ff\8] ;Vibration Enable
high SEL

low SEL
shiftout CMD,CLK,FASTLSBPRE,$01\8,$4F\8,$00\8,$FF\8,$FF\8,$03\8,$00\8,$00\8,$00\8] ;Enable Pressure
high SEL

low SEL
shiftout CMD,CLK,FASTLSBPRE,$01\8,$43\8,$00\8,$00\8,$5A\8,$5A\8,$5A\8,$5A\8,$5A\8] ;Press_trans_start
high SEL

low SEL
shiftout CMD,CLK,FASTLSBPRE,$01\8,$43\8,$00\8,$00\8,$00\8,$00\8,$00\8,$00\8,$00\8] ;Config Exit
high SEL

main
' This section find the mode the PSX controller is in.

low SEL
shiftout CMD,CLK,FASTLSBPRE,$1\8]
shiftin DAT,CLK,FASTLSBPOST,[mode\8]
high SEL

low SEL
' asking data to PS2 controller
shiftout CMD,CLK,FASTLSBPRE,$1\8,$42\8]
' reading data from controller
shiftin DAT,CLK,FASTLSBPOST,[temp(0)\8,temp(1)\8,temp(2)\8,temp(3)\8,temp(4)\8,temp(5)\8,temp(6)\8,temp(7)\8,temp(8)\8, |
temp(9)\8,temp(10)\8,temp(11)\8,temp(12)\8,temp(13)\8,temp(14)\8,temp(15)\8,temp(16)\8,temp(17)\8,temp(18)\8]
high SEL

'---------------------------------------------------------------------

'temp 3-6 are joysticks
'temp 7-10 are d-pad buttons
'11=triangle    12=circle    13=X    14=square
'15=L1          16=r1        17=L2   18=R2         255 is full on, 0 is off

' this section takes the status of circle, if on, double the speed
if (temp(12) >10) and circlelast = 0 then

	if (boost = 1) then
		boost = 2
	elseif (boost = 2 or boost = 0)
		boost = 1
	endif
	
	circlelast = 1
	
elseif temp(12) = 0

	circlelast = 0
	
endif

'---------------------------------------------------------------------

' this section will control servo position using L & R buttons -interrupts?








'---------------------------------------------------------------------
'prep the inputs to be displayed to screen. this is debugging more than anything
if temp(11)>0 then

	displaybutton = "^" 'triangle
	displayvalue = temp(11)

elseif temp(12)>0

	displaybutton = "O" 'circle
	displayvalue = temp(12) 
	
elseif temp(13)>0

	displaybutton = "X" 'x
	displayvalue = temp(13)
	
elseif temp(14)>0

	displaybutton = "=" 'Square
	displayvalue = temp(14)
	
else
	displaybutton = "  " 'blank
	displayvalue = 0

endif

'---------------------------------------------------------------------

' this section does the mixing for throttle steering on a diff steered vehicle.
rhori = (temp(3))
rvert = (temp(4))
lhori = (temp(5))
lvert = (temp(6))





if lvert < 80 then
    lvert = 0
    serout 4,i9600,[254]                             'send command
    serout 4,i9600,[128]                             'send position to move to
    serout 4,i9600,"l: forward   ", displaybutton]   'write the text
elseif lvert > 200
    lvert = 255
    serout 4,i9600,[254]
    serout 4,i9600,[128]
    serout 4,i9600,"l: reverse  ", displaybutton]    
else
    lvert = 128
    serout 4,i9600,[254]
    serout 4,i9600,[128]
    serout 4,i9600,"l: stopped  ", displaybutton]
endif


if rvert < 80 then
    rvert = 0
    serout 4,i9600,[254]
    serout 4,i9600,[192]
    serout 4,i9600,"r: forward ", dec3 displayvalue\3]
elseif rvert > 200
    rvert = 255
    serout 4,i9600,[254]
    serout 4,i9600,[192]
    serout 4,i9600,"r: reverse ", dec3 boost\3]    
else
    rvert = 128
    serout 4,i9600,[254]
    serout 4,i9600,[192]
    serout 4,i9600,"r: stopped ", dec3 lmotor\3]
endif


lmotor = 3000 - ((4 * boost) * (128-lvert))  ;converts 0 to 2000, 128 to 3000, 255 to 4000
rmotor = 3000 - ((4 * boost) * (128-rvert))



pulsout 0, lmotor
pulsout 1, rmotor

'---------------------------------------------------------------------

goto main 

Actually, the Sabertooth does use standard servo pulses. The Basic Atom Pro however, has .5us resolution so that when you send 4000, it is actually sending a 2000us pulse.

Ah, ok. :open_mouth: :smiley:

Yes, the Sabertooth does in fact respond to standard servo pulses. The Atom Pro’s pulsout is 0.5uS resolution, so a value of 3000 is really generating a 1500us pulse. The Sabertooth does not have an accurate clock, so the stop value might be off by as much as 100uS. However once you find the sweet spot for stopping the motors the delta from that stopped value should be the same for forward and reverse max speed. I will ask John at Dimension Engineering to chime in here. I’m not sure what could be causing your problem/

I edited my post figuring you guys wouldn’t have read it yet…and two replies lol. Yeah that makes a whole lot of sense actually. I was having issues with servo control using pulseout a while ago, and this explains it. so I could use a standard servo command to control the sabertooth, though this works nicely and I’ll stick with it. Any thoughts on the functionality of the sleep/timeout?

This is a really old post, but I had a similar problem and noticed there was no resolution posted.
My set up was not identical but it sounds exactly like the issue I was having.

My problems was simply related to a dead battery, causing too much current draw from the SSC32.

The underlying problem was, I missed a step in the instructions to remove the center(red) lead from the connector between the Sabertooth and the botboard (in this case I was using the SSC32)… This caused the sabertooth to draw too much current from the SSC32 shutting it down.

Probably a good thing it didn’t work, I can only imagine what it would do to the botboard or SSC32 were 4 motors to pull all their current through there.

The symptoms were that the SSC32 ‘seemed’ to run fine but wouldn’t not talk to the Sabertooth. Of course the SSC32 was restarting every time it tried to run the motors.

Hope it helps someone else…

I’m surprised that it is too much current. The ssc32 can draw what, 10 amps overall? I’m not really picturing the sabertooth drawing much more than those power hungry servo’s unless you are stalling out a rover. But yeah, my set up doesn’t have the ssc32 on it. I’ve been playing around with the bot, rewrote all the code. It still runs beautifully, and I’ve found that about a third of a second delay from turning on the main board until the sabertooth usually gets it working first try. I may actually try adding a delay before my main loop out of curiosity. Force the pins low, wait half a second then loop or something. But no other solutions have come up so far. As I said, it works, its just kinda annoying.

Normally I wouldn’t think it would pull that much current either.
My belief of what happened is,
the Sabertooth is actually set up to run power from the large batteries to the controller, which is why the red wire needs removed.
The issue I had was I had the SSC32 jumpered so the servo power came from the VL (litle 9 volt battery). This shouldn’t have mattered since at the time I wasn’t running any servos and didn’t require allot of power.
What I think happened was the ‘large’ batteries expected to only run the motors, went dead… the 4 motors then pulled their power through the sabertooth from the VL on the SSC32, which was way too much for a little 9v battery…

Incidentally I did it twice, originally thinking I just had a dead battery… it worked for a bit then died within the first hour of just testing.
I also believe with it wired like that (incorrectly) the batteries were trying to level out… I felt bad for the little 9v ??mah that just tried and tried to keep up with two 7.2 1800mah batteries wired in series.
Just glad I didn’t smoke any of the electronics during my “education”.

That’s the kind of explanation you get from someone who only dables in electronics… :slight_smile:

yeah, those 9v’s are only like 500 mAh batteries, they’d last a REALLY long time running a rover :wink:

do

low pinofthesabetooth

in order to be sure that it is positve logic pulse.

This would remove your problem