Friends:
Any ideas or links on how to encode the Lynxmotion Tri Trac drive for position data? Maybe there is a way of encoding without referencing the wheels (like by bouncing a signal off the floor)?
Ideas welcome,
Migs
You can use the GHM-03 (7.2V, 291 RPM) , GHM-04 (7.2V, 175 RPM), or GHM-16 (12V, 200 RPM) motors. All of these have the external shafts that allow adding the QME-01 shaft encoders. You would have to ask to substitute one of these three motors for the GHM-02 (12V, 120 RPM) motors that are standard with the Tri_Trak chassis. The price for all these motors is the same, so there should not be a problem doing a substitution if you ask Jim real nice. 
Why would you not want to reference the wheels with encoders to get position data? Data from the QME-01 shaft encoders will provide direction traveled, and a calculation based on number of encoder ticks and wheel diameter will get you distance traveled.
8-Dale
You can’t just put encoders on the motors of a tracked drive.
You might try using an optical mouse to “read” the floor. You could even make up a “trailer cart” to carry a pair of wheels with encoders.
Alan KM6VV
Why not? The encoder would go on the rear shaft of the motor, not the shaft the sprocket would be on. Why wouldn’t this work on a tracked base?
8-Dale
Anything other then a simple differential steered (two drive wheels in the center) robot will slip too much to give useful odometry. Even a four powered wheel drive will demonstrate too much slip-slide for it to be useful to read the motor revs.
A “cart” drive, with two driven wheels in the back can provide useful data, either on the rear wheels or on a front “tricycle” wheel. Less so on a pair of “Ackerman Steered” front wheels.
In short, you can’t get good odometry out of a “slip-steered” 'bot.
Alan KM6VV
I’m just not sure this is completely the case. It seems like a lot of folks use encoders on all different types of wheeled robots, so I guess I will find out. I think the degree of slop in movement depends a lot on the terrain a robot is trying to navigate over, so this can no doubt affect the usefulness of the data the encoders provide. I’m still going to experiment, and will be putting encoders on all four wheels of ASTRID (four), as well as all wheels of WALTER (two or four).
8-Dale
It all depends on what you expect from the arrangement. A lot of performance improvements can be had with an encoder equipped 4WD rover. For example it would be very easy to use them to ensure the vehicle moves in a straight line when commanded to do so. If the vehicle properties don’t change; weight, COG, operating environment (tile floor, and nothing different) then it can be used with some success to do dead reckoning. At least that’s what I’m hearing from Basic Micro in reference to their upcoming RoboClaw motor controllers.
I’ve never actually used wheel/shaft encoders before, so it’s something I want/need to learn how to use properly. With independently steerable wheels on each hybrid leg I have designed, it should be an interesting experiment with encoders on all four motors.
Being able to have a robot move in a more straight line is one of my goals. For my initial experiments, they will all be done indoors, so I don’t see terrain being an immediate problem. Once I get a handle on indoors, I can start experimenting outdoors. 
Seeing this hybrid leg completely assembled, with motor, wheel, and all, has really got my excited about experimenting with this. I really want to get some pictures and videos of all this before I get too far along. This new hybrid leg design has a lot of potential for being able to shift weight around and go places a regular robot (not a hybrid) wouldn’t normally be able to go. This leg looks pretty awesome with a motor and 5" offroad wheel at the end.
8-Dale