Tri-track/Rover with Basic Micro Roboclaw+++

[kurte]

Hi Alan,

@KM6VV

Yeah, a little fun! A lot of time is spent with new 2010 SS2/RS Camaro!

Nice car!

@KM6VV

Yeah, that’s a real problem with BASIC. Really need to code proper buffers, and run interrupts. One of the trade-offs in running built-in LIB functions, I guess.

If the ASM code could be made modular enough (why we like include files), then it could be a drop-in. I think I’ve moved the pins before when confronted with a similar problem.

How about a WiFi connection? The Lantronix is interesting, and it can handle the Blackfin video!

Yep, it has a lot to do with the processor only has 1 UART and the BB2 PS2 connection is on the same pins. That is where it is nice to use the Atmega 1280 processors like what is on the Axon2 board and I believe the Arduino Mega boards as they have 4 UARTS.

I do have these ASM functions in files that are included with all of my XBee programs and the like.

I have moved the pins. Having a little issue with the PS2. On a few other robots, I was successful in using the processors pull-up resistor on the data line to make the PS2 work, but on this processor/PS2 controller I think it is a bit flaky. Will experiment some more.

At one time I was going to try the Lantronix, bought one, soldered up a connection board to handle it and I think I screwed up the voltages or the like and probably fried it… I may try the Trendnet camera on my tri-track.

@KM6VV

Part of HAL (Hardware Abstraction Layer) approach is defining hardware pins and ports. From Phoenix, we have:

;[PIN NUMBERS]
#IF SSC_LM_SETUP ;Connector to the front
RRCoxaPin con P0 ;Rear Right leg Hip Horizontal
RRFemurPin con P1 ;Rear Right leg Hip Vertical
.
.
.
#ELSE ;Connector to the back
RFCoxaPin con P2 ;Front Right leg Hip Horizontal
RFFemurPin con P1 ;Front Right leg Hip Vertical
#ENDIF

As you know; this is a start. With enough ifdefs for defines, and conditional compiles, we can get the job done.

Yep - I was just sort-of whining. That is for example with my XBee stuff, on some robots I want to not use HSERIAL with them as that can screw up the serial for other things, but some I do and on those some are Bap28’s which I use HSERIAL and others will be Arc32’s which I will use HSERIAL2. Nathan(AcidTech) was working on a partial fix that if you may be able to say usehserial2 on the Bap28 and it will actually use the first serial port, which would help. On the Arc32 I like to use both as it is nice to get reliable debug serial stuff at higher baud rates. Without any help, the Xbee code will end up looking something like:

[code];==============================================================================
; [SetXbeeDL] - Set the XBee DL to the specified word that is passed
; BUGBUG: sample function, need to clean up.
;==============================================================================
wNewDL var word
SetXBeeDL[wNewDL]:
#ifdef DEBUG_VERBOSE
;bugbug;;; debug
serout s_out, i9600, "Set XBEE DL: ", hex wNewDL, 13]
#endif

#ifdef XBEEONHSERIAL
pause 20 ; have to have a guard time to get into Command sequence
hserout [str _XBEE_PPP_STR\3]
gosub WaitHSeroutComplete
pause 20 ; have to wait a bit again

hserout "ATDL ",hex wNewDL, 13, |	; Set the New DL
		 str _XBEE_ATCN_STR\5]					; Exit command mode
pause 10

#else if XBEEONHSERIAL2
pause 20 ; have to have a guard time to get into Command sequence
hserout2 [str _XBEE_PPP_STR\3]
gosub WaitHSeroutComplete2
pause 20 ; have to wait a bit again

hserout2 "ATDL ",hex wNewDL, 13, |	; Set the New DL
		 str _XBEE_ATCN_STR\5]					; Exit command mode
pause 10

#else
pause 20 ; have to have a guard time to get into Command sequence
serout cXBEE_OUT, cXBEE_BAUD, [str _XBEE_PPP_STR\3]
pause 20 ; have to wait a bit again

serout cXBEE_OUT, cXBEE_BAUD,"ATDL ",hex wNewDL, 13, |	; Set the New DL
		 str _XBEE_ATCN_STR\5]					; Exit command mode
pause 10

#endif
return
[/code]
Note: the could be changed such not as much under #ifdef, but you would then have to repeat it for each serout/hserout/hserout2… In my C libraries I handled something like this by having my functions IOPrintf, check for -1 and -2 as the IOpin and converting them to the appropriate hardware calls. I probably still have a little work in there to also abstract out some of the other calls, like: hserstat, such that I could ask is the output complete and on non hardware serial ports it would always return true… Also again this would be easier in C. You can simply define a couple of macros or inline functions, like: XBeeOut and DBGOut which default to the right calls and pass along the parameters. But…

But you use what you got…

Kurt

[acidtech]

As of 1.0.0.31 and up if you ENABLEHSERIAL or ENABLEHSERIAL2 but do NOT do both at the same time you can use either hserial or hserial2 commands(eg hserin,hserout,sethserial will work on ENABLEHSERIAL2 just like hserin2,hserout2 and sethserial2 and vis-versa).

Only when using BOTH ENABLEHSERIAL and ENABLEHSERIAL2 will hserial commands only work with uart1 and hserial2 commands only work with uart2.

Also you can #ifdef the ENABLEHSERIAL and ENABLEHSERIAL2 to the specific processor.

#ifdef BASICATOMPROARC32 ENABLEHSERIAL2 #else ENABLEHSERIAL #endif

The processor defines are added automatically depending on the attached processor(or the selected processor). All the possible defines are:

BASICATOM18NANO BASICATOM28NANO BASICATOM40NANO BASICATOM24 BASICATOM28 BASICATOM40 BASICATOM24D BASICATOM28D BASICATOM40D BASICATOMPROONE BASICATOMPRO24 BASICATOMPRO28 BASICATOMPRO40 BASICATOMPROARC32 BASICATOMPROSS2 BASICATOMPROSE2

The SS2 is the AtomPro 48pin interpreter chip
The SE2 is the AtomPro 64pin interpreter chip

[kurte]

Thanks Nathan,

So: from what you are saying, I will be able to convert all of my XBee code to HSERIAL2, which will be the only one I define for the BAP28 and will work on the only UART. On the Arc32, I would then define both, the HSERIAL2 will go appropriately to the UART2 and I can use the HSERIAL to go to the debug. That will help. Also thanks for defining which processor you are on. It will look a lot cleaner than looking for something like TMA being defined.

Another quick update:

OK, I converted the code over to use HSERIAL, move the PS2 to Pins 0-4. As I mentioned above, I ran into a problem that it appeared like the internal pull-up was not sufficient for this receiver. Why after it worked on a few others? I don’t know, but no big deal. I added a 1K pull-up to the DAT line. This time I did it internal to the actual receiver, which was easy. unscrewed the case, slipped the resistor in, which was made easy as the pins were hollow and then soldered them in. Here is a poor picture showing it.

I also then enabled the Pan/Tilt.

My L1 button now goes straight for aways, makes a turn, goes aways and stops. It also uses the query for command depth to find out when it completed. Will continue to play with this to see if I can make it do a square (Will then move the code to be done on the PS2 square key)

Kurt
rover - roboclaw.bas (32.1 KB)

[acidtech]

The internal Pull-Ups on the AtomPro are very weak. I mean seriously weak. We had 47k pulldowns on those pins and the internal pullups couldn’t even budge them. So you can use the interal pullups but they will be usefull primarily only on buttons and such things that don’t need high speed switching.

Note, that I recommend using the 2x4 button header for the PS2 controller if you are using the ARC32. You can also get vcc/vss from the AUX1 header right next to it. No pullups required since the button header already has them.

[km6vv]

@kurte

Hi Alan,
Yep, it has a lot to do with the processor only has 1 UART and the BB2 PS2 connection is on the same pins. That is where it is nice to use the Atmega 1280 processors like what is on the Axon2 board and I believe the Arduino Mega boards as they have 4 UARTS.

The multiple USARTS are nice. The dsPIC32 and other Microchip uP have a nice setup. I would have liked to see BasicMicro go that way, rather then a different chip. But I’ve made that observation several times before.

@kurte

I do have these ASM functions in files that are included with all of my XBee programs and the like.

I have moved the pins. Having a little issue with the PS2. On a few other robots, I was successful in using the processors pull-up resistor on the data line to make the PS2 work, but on this processor/PS2 controller I think it is a bit flaky. Will experiment some more.

The internal pull-up is very weak. External resistors are a pain, but probably necessary.

@kurte

At one time I was going to try the Lantronix, bought one, soldered up a connection board to handle it and I think I screwed up the voltages or the like and probably fried it… I may try the Trendnet camera on my tri-track.

I’ve only just got it working by setting up a portable WLAN. Then I sign on to the WLAN with my laptop IBM. It’s for the video, but has two serial channels, so control can run through the 2nd. The video is in packets, so commands can probably (maybe they are) piped along with the video packets. I’ve not learned a lot about all the Surveyor robot implementation. But I need a bigger 'bot! And I think I should be able to make the whole package work on multiple 'bots.

@kurte

Yep - I was just sort-of whining. That is for example with my XBee stuff, on some robots I want to not use HSERIAL with them as that can screw up the serial for other things, but some I do and on those some are Bap28’s which I use HSERIAL and others will be Arc32’s which I will use HSERIAL2. Nathan(AcidTech) was working on a partial fix that if you may be able to say usehserial2 on the Bap28 and it will actually use the first serial port, which would help. On the Arc32 I like to use both as it is nice to get reliable debug serial stuff at higher baud rates.

You mean switch back and forth between two hserials?

@kurte

Note: the could be changed such not as much under #ifdef, but you would then have to repeat it for each serout/hserout/hserout2… In my C libraries I handled something like this by having my functions IOPrintf, check for -1 and -2 as the IOpin and converting them to the appropriate hardware calls. I probably still have a little work in there to also abstract out some of the other calls, like: hserstat, such that I could ask is the output complete and on non hardware serial ports it would always return true… Also again this would be easier in C. You can simply define a couple of macros or inline functions, like: XBeeOut and DBGOut which default to the right calls and pass along the parameters. But…

But you use what you got…

Kurt

Yeah, use what it’s got. Quite convenient to use BASIC for a lot of things…

Alan KM6VV

[km6vv]

I can’t keep up! But I like the changes you made. I can get by without the tilt/pan for a while.

@kurte

Thanks Nathan,
OK, I converted the code over to use HSERIAL, move the PS2 to Pins 0-4. As I mentioned above, I ran into a problem that it appeared like the internal pull-up was not sufficient for this receiver. Why after it worked on a few others? I don’t know, but no big deal. I added a 1K pull-up to the DAT line. This time I did it internal to the actual receiver, which was easy. unscrewed the case, slipped the resistor in, which was made easy as the pins were hollow and then soldered them in. Here is a poor picture showing it.

Yeah, pull-ups can help.

@kurte

I also then enabled the Pan/Tilt.

My L1 button now goes straight for a ways, makes a turn, goes a ways and stops. It also uses the query for command depth to find out when it completed. Will continue to play with this to see if I can make it do a square (Will then move the code to be done on the PS2 square key)
Kurt

I’m thinking of a set of fwd one cell, right, & 180 turn. Things that I might do in a maze.

Alan KM6VV

[kurte]

@KM6VV

The multiple USARTS are nice. The dsPIC32 and other Microchip uP have a nice setup. I would have liked to see BasicMicro go that way, rather then a different chip. But I’ve made that observation several times before.

Understood. But don’t get me wrong. I really do like the Renesas H8 chips. They have full 32 bit math and their instruction set is nice. It is always a trade off. I like the Atmega 1280 processors as they have 4 hardware serial channels, plus lots of hardware PWM channels, but all of their math is done in 8 bits…

@KM6VV

@kurte

… On the Arc32 I like to use both as it is nice to get reliable debug serial stuff at higher baud rates.

You mean switch back and forth between two hserials?

With the latest IDE build, I can now change all of the code for my XBEES to use HSEROUT2 and HSERIN2. That way on the BAP28 I will simply define USEHSERIAL and it will go to the only hardware serial port. On the Arc32 version I will define both USEHSERIAL and USERHSERIAL2. The XBee code will go to the second hardware serial port and some of my debug code will go to the primary hardware serial port which is the one that talks to the USB (S_IN, S_OUT). More details on the build changes posting. I have changed my Bap28 phoenix/chr3 code like I mention and it still appears to work. Now back to my conversion to Xbees in packet mode…
Kurt

Kurt

[km6vv]

@kurte

Understood. But don’t get me wrong. I really do like the Renesas H8 chips. They have full 32 bit math and their instruction set is nice. It is always a trade off. I like the Atmega 1280 processors as they have 4 hardware serial channels, plus lots of hardware PWM channels, but all of their math is done in 8 bits…

I guess it’s just what one’s used to. Takes a bit of work to come up to speed on a new uP. Great, if I can do it for a job.

@kurte

With the latest IDE build, I can now change all of the code for my XBEES to use HSEROUT2 and HSERIN2. That way on the BAP28 I will simply define USEHSERIAL and it will go to the only hardware serial port. On the Arc32 version I will define both USEHSERIAL and USERHSERIAL2. The XBee code will go to the second hardware serial port and some of my debug code will go to the primary hardware serial port which is the one that talks to the USB (S_IN, S_OUT). More details on the build changes posting. I have changed my Bap28 phoenix/chr3 code like I mention and it still appears to work. Now back to my conversion to Xbees in packet mode…
Kurt

Sounds like an elegant solution! One could do something similar with the Lantronix. No Arc32 in my mix.

Alan KM6VV

[km6vv]

I spent considerable time attempting to shift over to your 1st rover code. No motor spin.

I went back to the packet demo, and it ran. I had some concern about the change in I/O assignments, so I put the new pin 11/12 into the packet demo with conditionals. Wouldn’t work! I finally observed that RoboClaw 5a wasn’t resetting. Seems to need resetting every time. Is there a proper sequence for power up? This data is poorly linked, may not infer anything at all. Maybe logic on BB2 first is the key.

Getting really funny getting into BasicMicro, or I might have asked there. Says “logged in”, and then puts up a log-in box again. Can’t post. I’m going to try from another computer. Of course Thunderbird was trying to remember log-in, might be part of the problem.

Now maybe I can get back to trying your RoverRoboClaw (1st) code.

I’m assuming tri-track with two motors is not that different from a Micromouse, even 'tho it has tracks. i did see two control modes, track and Single joystick, so it looks like you’ve covered it rather well.

After this reset problem is cleared up, I’ll shift over to your 2nd RoverRoboClaw code. What Display are you using? Maybe it was in the thread, and I missed it. Oh, but I bet it’s serial. I have a bunch of parallel LCD displays.

Happy 4th!

Alan KM6VV

[kurte]

Hi Alan,

Sorry you are having problems.

I don’t think it would make any difference, but I think I have a 10 not a 5… Next I would check to make sure your switches on the Roboclaw are set the properly.
Mine or( 0 0 1 1 1 0 0 0 0 0). Never noticed roboclaw reseting… Also check power. I have two switches. One for Logic and one for motor controller. The motor controller one appears to also power everything up. Probably because my two communication IO lines still have the power wire installed…

Code should work fine with track or with wheels. The original code was extracted from the Rover with Arm code. I think Xan did the earlier work with 1 stick or 2 stick mode.

My LCD is a S.E.E ILM 216.

Not sure what else to check?

Kurt

[km6vv]

Hi Kurt,

Working now.

The reset seems to be the problem. I have to reset to get anything to work. Is your RoboClaw power (motor) also powering the logic, or do you get your logic power shared with the BB2? Your “power wire”? I have the logic power separated, and a 9V battery on the BB2. Maybe I’ll change that, see if the reset improves. I was surprised to see a reset on a driver board anyway. But it’s great to see a line of driver boards that can USE the encoders. Something I have been waiting for (I know, I should have finished mine).

A 10 might work slightly different; I’m hoping that all three share the same command set. I’ve got a few other candidates for a good driver board in various power ranges.

I did document the baud rates and the command pins:

RClAW_BAUD		con	i38400	; for tri-track RoboClaw sw 3 & 4 & 5
;RClAW_BAUD		con	i19200	; original 		RoboClaw sw 3 & 5

RCLAWSeroutPin	con	P11		; for tri-track
RClawSerinPin	con	P10
;RCLAWSeroutPin	con	P15		; original
;RClawSerinPin	con	P14

To make it a little easier to set up. #defines could improve that.

Spinning wheels just fine now. Fine piece of code!

Next “shop break” I get, I’ll experiment with your 2nd Roboclaw code.

Thanks!

Alan KM6VV

@kurte

Hi Alan,

Sorry you are having problems.

I don’t think it would make any difference, but I think I have a 10 not a 5… Next I would check to make sure your switches on the Roboclaw are set the properly.
Mine or( 0 0 1 1 1 0 0 0 0 0). Never noticed roboclaw reseting… Also check power. I have two switches. One for Logic and one for motor controller. The motor controller one appears to also power everything up. Probably because my two communication IO lines still have the power wire installed…

Code should work fine with track or with wheels. The original code was extracted from the Rover with Arm code. I think Xan did the earlier work with 1 stick or 2 stick mode.

My LCD is a S.E.E ILM 216.

Not sure what else to check?

Kurt

[kurte]

Sounds great: I was out having fun today. Did get some code working that gets me pretty close to going around in a square…

Looks like:

	IF (DualShock(2).bit7 = 0) and LastButton(1).bit7 THEN	;Square Button test
	; lets try to do a square...
		SQUARE_FORWARD	con 	1900*12
		SQUARE_TURN		con		14600
		SQUARE_SPEED	con		20000
		
		; cmd 43 Speed1, Distance 1, speed2, Distance 2, Clearbuf
		for i = 0 to 3
			gosub RCLAW_DriveSpeedDistance[SQUARE_SPEED, SQUARE_FORWARD, SQUARE_SPEED, SQUARE_FORWARD, 0]
	
			; now lets try to turn...
			gosub RCLAW_DriveSpeedDistance[SQUARE_SPEED, SQUARE_TURN, -SQUARE_SPEED, -SQUARE_TURN, 0]
		next	

		gosub RCLAW_DriveSpeedDistance[0, 0, 0, 0, 0]	' should bring us to a stop...
		
		' now lets see if we can figure out when the stop actually happens.
		' Note the ReadBufferDepth returns two counts, one for each wheel we are done
		' when both go to zero so simply checking the word for zero should be sufficient.
		sound p9, [50\4000]
		do 
			gosub RCLAW_ReadBufferDepth], EncoderBuffCnts
		while EncoderBuffCnts
				
		'pause (REncoderCnt/REncoderSpeed)*1000*2 + 500	; pause until we think the command should be done.
		sound p9, [50\5000]		
		ENDIF

Note: to compile you will need to define the variable i somewhere…

I am going to play around more with it before I repost it. I am going to try to capture how far it goes on each turn. I will try to detect when the buffer count changes and grab the encoder counts. Will then change my R2 code to know that I have some cached up values and print them. IE after I do the square I will then plug the RS232 cable back in…

Kurt

[km6vv]

Sounds like you are off to a good start. A square is a good way to evaluate the odometry.

I want to work on standard length moves, i.e. the standard length of a maze. And standard rotates in-place.

Got into Basicmicro, posted on the reset problem. I had to use Internet Explorer. It might be related to a recent update of Firefox.

I tried changing the logic power from internal to external, no help with the reset problem.

But it’s a start.

Alan KM6VV

[kurte]

I did have a little time to play with this code. I added code that when the claw says the number of buffered commands has decreased, I then ask it for the encoder counts and later I can dump out the counts. The code is not perfect but it gives me some hints on counts. I uploaded the updated program in case you wish to play with this part. Here is a dump from a sample run of it running a square:

Left Encoder: 32261 80 Speed: 0 0 Right Encoder: 149544 80 Speed: 0 0 538(0) 468(0) 22898(22360 -> 22,898) 22895(22427 -> 22,895) 9139(-13759) 37587(14692) 31040(21901) 60497(22910) 17354(-13686) 75174(14677) 39200(21846) 98102(22928) 25616(-13584) 112755(14653) 47372(21756) 135702(22947) 32642(-14730) 149491(13789) 31192(-1450) 148931(-560)
The numbers are the left encoder (delta from the previous count) right encoder (delta from previous count). Note to be accurate the first two counts should probably be dded together as the code simply default to -1 commands and when it changes (first all through) it gets the count… I edited the results above and show the values added… Also if you delta the last values from the main encoder counts reported on the first line, that is probably the distance it went after the last command completed? The deltas were 1069 and 613.

Note: the square is not perfect, it overruns the area by a little bit. You can see that in the really really poor video. s416.photobucket.com/albums/pp245/Kurts_Robots/?action=view&current=MOV03381.mp4

But at least it is reasonably working…
Kurt
rover - roboclaw.bas (34.1 KB)

[acidtech]

That worked pretty good. I’m using jims monster truck wheeled 4wd rover which slips a lot on turns. This may be because my rear tires are not encoder corrected. I’m waiting on 2 more motor encoders so I can run the 4wd from 2 2x5 Roboclaws to see if it’s the fat tires or the unencoded rear wheels causing all the slip.

Also to help combat slippage you may want to add some accel instead of using the non-accel commands. Sorry if I missed you using them.

P.S. Whose tracks are you using on that robot?

[km6vv]

I moved the PS2 over to pins 0-3, and I get a constant stream of beeps from the speaker. I’m assuming that the PS2 connection is failing, probably because of the lack of pull-ups on the CLK and DATA lines?

No simple way to temporarily add the 1K pull-ups.

I hear the BBQ calling…

Alan KM6VV

[kurte]

@KM6VV

I moved the PS2 over to pins 0-3, and I get a constant stream of beeps from the speaker. I’m assuming that the PS2 connection is failing, probably because of the lack of pull-ups on the CLK and DATA lines?
Alan KM6VV

It is interesting that it has worked for me on a few different boards/receivers, but my latest one did not and yes the beeping sort-of implies it did not work on yours either… Need to check to see if I actually set it properly… I think you only really need the pull-up on the DAT line as the CLK line is always set to output on the BAP and will either be driven high or low. As I mentioned in a earlier post, it was easy to slip the leads of the resistor inside the pins of the receiver. I soldered them, but they would probably make enough contact without it…

@Acidtech

That worked pretty good. I’m using Jim’s monster truck wheeled 4wd rover which slips a lot on turns. This may be because my rear tires are not encoder corrected. I’m waiting on 2 more motor encoders so I can run the 4wd from 2 2x5 Roboclaws to see if it’s the fat tires or the unencoded rear wheels causing all the slip.

Also to help combat slippage you may want to add some accel instead of using the non-accel commands. Sorry if I missed you using them.

P.S. Whose tracks are you using on that robot?

I also have a Lynmotion Rover kit with 4 motors. It also has 2 wheels with encoders. But I decided to try the Claw out on the Lynxmotion Tri-track lynxmotion.com/Category.aspx?CategoryID=121 as it only has two motors and I thought it would be fun to try it there and I wanted to try out a track system.

As you mention the 4x4 does a lot of slipping when turning. My guess is that is sort-of by design on this type of design that does not have a steerable front axle.
Not sure how two more encoders will help, but could be fun. You plan on hooking up two Roboclaws?

Kurt

[km6vv]

Yes, I did read “inside the receiver”, the XBEE? I suppose one could open up the PS2 XCVR, but then you’ve got the extra resistors in case you move back to p10-p15. The resistors could be added to the BB2, on bottom side. But still, rather a little permanent. I might just rework the “Schmart Board” jumpers I use. I just noticed that BasicMicro also offers some sort of jumper sets.

Alan KM6VV

@kurte

It is interesting that it has worked for me on a few different boards/receivers, but my latest one did not and yes the beeping sort-of implies it did not work on yours either… Need to check to see if I actually set it properly… I think you only really need the pull-up on the DAT line as the CLK line is always set to output on the BAP and will either be driven high or low. As I mentioned in a earlier post, it was easy to slip the leads of the resistor inside the pins of the receiver. I soldered them, but they would probably make enough contact without it…
Kurt

[sevenclarks]

Hi Guys
i know this is an old topic but i am attempting to do a similar project to this making my Tri-Track travel in a square would be the first step, i have the Tri-Track with motors with encoders but I have a Sabertooth 2x5 RC Motor controller board (instead of the Roboclaw used in this post) wired up as can be seen in this tutorial lynxmotion.com/images/html/build138.htm

Is it possible to do a similar thing to what is done in this post with a Sabertooth ?

and if so Would the Code (rover-roboclaw.bas) written by Kurte Further up in this post ( sorry i don’t know how to quote an attatchment ) be easy to modify to work with the sabertooth and how would i go about doing this?

I am relatively new to this and any help would be much appreciated !!

Andy

[kurte]

The simple answer is No. That is I don’t know of any of the Sabertooth motor controllers that allow you to plug the encoders into it and have commands that allow you to control the motors through the encoders.

The not so simple answer is Sort-of. That is you can use the Sabertooth to control the motors. Depending on which version you have, you can use the same form of serial packet control like I did to the Roboclaw. If however you have one of the Sabertooth controllers whose name ends with something like RC (like the one you mentioned), then you will probably need to use the PWM type control (same type of signals you send to servos).

You can then connect the two inputs from each of the encoders to your computer/micro-controller and do the work to count the pulses, calculate speed,distance… From which you can update the speeds and the like sent to the Sabertooth. This is a reasonable amount of work and writing the code to properly handle the number of pulses. It has been awhile since I played with this, but I think that if you use a GHM-16 at full speed (200 RPM), Which has a 30 to 1 reduction, which I believe implies the shaft that the encoder attaches to will be running at 6000 rpm and the encode has 100 cycles per revolution, which implies you could have 600000 pulses per each of the inputs per minute or about (10000 per second) and if you are reading both inputs of both encoders, that is 40000 per second. So you need to be careful on how you handle it.

Kurt