|
[DPRG] RE: Wheel encoder theory
Subject: [DPRG] RE: Wheel encoder theory
From: Vimal Shankar
vimalsshankar at yahoo.com
Date: Wed Oct 11 14:55:56 CDT 2006
> >> Are you in the Dallas area?
Quite far away actually... I am from India !
And that too, in the most robotics ignorant portion of
it - West Bengal.
> > There are a number of easy to use transmissive
> type optical encoders
> > out there which are already amplified and will
> produce a digital
> > output. Check Mouser or Digikey for these. They
> will have 3 wires on
> > the receiver for power, ground, and output instead
> of 2 wires of a
> > phototransistor. When selecting a device, make
> sure that the aperture
> > is as small or smaller than the smallest encoder
> slot in your wheel.
I would have been happy to. This would have solved ALL
my problems, but they are not at all available here..
Homebrew is the ONLY way out for me.
> >> Actually, I already have 2 articles on motor
> control stuff on the DPRG
> website, look under tutorials. I could write some
> more, but I haven't really
> seen much interest.
I am looking out for a PIC controlled Dual Diff motor
controlled system with PID in the firmware.
S o I am looking to having a schematic and firmware.
Only - I don't expect it to be handed over to me on a
silver platter - willing to work for it.
If you have even some rough sketches, if not concrete
code, just let me know.
I am your man to get the writeup done.
Once we have the article, hits and emails will come
pouring in.
Most people don't know what the are looking for.
That's the reason why you did not see any "interest".
> > On a separate note, I have also used this
> technique of a separate
> > controller for each motor in a 6 axis robotic arm
> and it works quite
> > well. In this application though, there is not the
> critical need for
> > correlation between the motor speeds.
All the better.
> >> For your trigonometric position calculations
> (dead reckoning) with a
> differential drive robot, you will need an encoder
> for each drive wheel.
> Then the calculations are straightforward.
Oh yes.. I need materials on encoder design too !
Something like :
http://www.geology.smu.edu/~dpa-www/robo/Encoder/imu_odo/
> >> For your robot encoder, you shouldn't really need
> a quadrature type. The
> robot is unlikely to move in a direction other than
> what the motors are set
> to, so you're going to know the direction.
My robot will be required to move against slopes.
A qudrature encoder just needs an extra F/F .. right ?
And little more Code space.
> There is a technique you can
> use however to use
> quadrature sensors to multiply the resolution of the
> encoder by 4 for more
> accurate position.
Can you tell me more ?
More ! More I tellz ya !
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
More information about the DPRG mailing list
|
