Motor, Encoder, Driver?

Hi all,
I’m making my own robot rover and I’m in the critical phase of choosing Motors :question:

I saw this motor
lynxmotion.com/Product.aspx? … ategoryID=
combined with this encoder
lynxmotion.com/Product.aspx? … ategoryID=

Now my problems are:

  • Which driver can I use?
  • How can I read encoders? (I know that 16fxxx PIC cannot do this)
  • Is this motor enough for tracks? ( lynxmotion.com/Product.aspx? … egoryID=94 )
  • How can I mount tracks on my robot without using 4 motors?

Thank you for help
Walter

As for motor selection…
That’s going to depend entirely on the overall design of your rover.

If you’re making a rover to traverse smooth surfaces slowly, then those motors/encoders will do great.

If you’re making a tracked vehicle for more rugged terrain (i.e. carpet, grass) as it sounds you are, I’m not sure that you’ll be satisfied with them.
From what I hear, GHM-13’s are the best deal, there.

As for using the encoders, you should be able to mount the encoder wheel on the drive wheel and the encoder electronics on either the motor or the outer motor mount surface, depending upon how you mount your motors.

The driver that you use will depend upon the sum off all your motors’ stall torques.
You need a driver capable of sourcing at least that much current to stay in the clear.

If I remember rightly, encoders output a train of pulses that you then capture the duty cycle of.
If that’s indeed the case, then all you need is an interupt pin that’s edge-triggered.
When the pin goes L-H, and fires off an interupt, your interupt code needs to start a timer.
Then when the pin drops back low again, your interupt code stops the timer, records the value and restarts the timer, but this time timing the low-time (sorry for the redundance there :stuck_out_tongue:).

I’ve only been using 18Fxxxx PICs, so I can’t help you with 16f’s.
Maybe Eddie, Andy, or Pete can.

How can you use tracks without 4 motors?
Well, I think that Jim’s either got idlers in the works (or maybe already selling).
In any case, sprockets + bearing + bearing mount/axle will do the trick.

Have you seen the Nubotics Wheel Watcher and Wheel Commander products? You might want to look into these as they are an integrated solution for operating motors. I have not used them, but am planning to in a future rover.

8-Dale

Myzhar,
The encoder you linked has a quadrature output so what you get are two square waves shifted 90 degrees from each other. Since the two signals are always related by this phase shift you can use them to determine the direction as well as its speed and accumulated distance traveled. An easy way to think about decoding this is the state of 1 output determines the direction of rotation when the other output makes a transition from low to high or high to low. I am not certain where the PIC16Fxxx reference came from but if decoding a pair of these signals is the only thing you wish to have one do the task is almost trivial with such a PIC. A better question may be how can you communicate the decoded signal to whatever micro you are controlling the rover with, and that depends on what your controller has available for resources. So, what ARE your plans for controlling your rover, and then maybe we can make a helpful suggestion or two on how you can efficiently decode and interpret the wheel encoder information.

The Nubotics encoders seem to function just the same as the ones Parallax sells. Since size/ weight is very important with robots, I would recommend taking a look at the Parallax ones since they are smaller and thus easier to mount (especially if you’re not using a continuous rotation servo). The engineer at Parallax wrote a nice 30 page manual about how to implement the encoders, which makes using them nice. Granted if you have the money, just using the wheel encoder board from Nubotics and letting the hardware handle all the low-level stuff is nice. However, I found learning how to implement the encoders manually very interesting.

The only component those encoders have that the Parallax ones don’t are the codewheels, so that you can use any wheel type as opposed to the BOE bot v3 wheels. I’m actually really glad you linked, since I had thought about upgrading to Matt tracks for my BOE bots, but didn’t want to have to ditch the encoders. If I bought a pair of wheels and servo adaptors I could use the tracks and encoders at the same time. The 32 vs. 16 division should also double accuracy.

I have two full sets of mattracks here - I got an extra vehichle for parts when I bought one. :smiley: A couple of my mattracks seem to have problems, but I think they are fixable. I may put a pair of them on my little Octabot II differencial drive bot. :slight_smile:

8-Dale

The GHM-04 7.2vdc 50:1 reduction will work for the tracks. I have a prototype here and they work fie. I would recommend keeping the weight below 6 lbs total though. If you need more weight you may want to use a more powerful motor.

We have a Dual H-Bridge motor controller in development. It will be able to read the encoders. It’s still 6 to 8 weeks till it will be available though.

If you setup the capture hardware (CCP1 and CCP2) for interrupts, you should be able to count the transitions without having to use a timer. You can count either L-H or H-L transitions if you want to count every pulse. The capture inputs each have their own interrupts. I have been looking at this as a possible way to make use of the Nubotics hardware on my Octabot rover. Most PICs have at least two capture inputs.

8-Dale