Subject:
|
Re: rotation sensors and input limitations
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Fri, 12 Feb 1999 19:51:19 GMT
|
Reply-To:
|
bryan.beatty@autodesk.+avoidspam+com
|
Viewed:
|
1590 times
|
| |
|
|
John A. Tamplin wrote:
> ...I need to be
> able to tell where the shifting mechanism is to make sure I consistently
> get the proper gear, yet I also need to count the output of the "shifted"
> motor (since it is doing things like moving arms etc, and if I rely on
> timing it eventually gets off and I have no touch sensors to spare to detect
> end-of-travel).
You've come up with an admirable solution to the problem! Here's
another idea, one that works on a general class of problems and doesn't
require any sensor input for controlling motor positioning:
The general problem class is one where you're using a motor to control
some kind of switch, and need to move it back and forth among various
positions. This generally requires knowing what the motor axle's angle
of rotation is. Trying to do this via timing is sticky, because
inaccuracies accumulate and eventually cause it to drift off. The
question is, how can one do this without requiring adding an angle
sensor to the axle?
Here's one approach:
Motor turns small pulley #1, which turns belt, which turns small pulley
#2. Belt is not extremely tight, so it slips fairly easily. Pulley #2
is on the "switcher" axle. The switcher axle handles your control, and
you need to be able to position it accurately at, say, positions A, B,
and C. A is the furthest to counterclockwise.
Attach some sort of a limiter to the "switcher" axle (say, an arm or
something) that prevents the axle from turning counterclockwise any
further than A. If the motor tries to drive the axle further
counterclockwise than A, all that happens is the belt slips.
Let's suppose that if the switcher is at position A, it takes 0.3
seconds of clockwise motor output to move it to B, and another 0.3
seconds to reach C. In this case,
To select A: Rotate counterclockwise for 1 second.
To select B: Rotate counterclockwise for 1 second, then clockwise for
0.3 seconds.
To select C: Rotate counterclockwise for 1 second, then clockwise for
0.6 seconds.
...Basically, you take advantage of the slipping belt so that every time
you need to switch axle positions, you "re-zero" the axle position
against the physical limiter at A. Thus, any errors of motor position
do not accumulate; the only error is whatever builds up in rotating from
A to B or C, once. The tolerances on the motor and on the positioning
of B and C are probably good enough for this to work.
In this way, you don't need any sensor inputs at all to accomplish this.
|
|
Message has 1 Reply:
 | | Re: rotation sensors and input limitations
|
| (...) Another possible error is slippage of the belt (aside from when you want it to slip at end-of-travel). I haven't played with belts & pulleys much because when I did at first I found slippage to be a problem. Am I missing something or are you (...) (25 years ago, 12-Feb-99, to lugnet.robotics)
|
Message is in Reply To:
| | rotation sensors and input limitations
|
| It seems that in all the designs I think of, I wind up needing two rotation sensors. Since I need one input for 4 touch sensors (muxed as previously discussed on this list) and 1 for a light sensor, I have a problem. I have been trying to come up (...) (25 years ago, 10-Feb-99, to lugnet.robotics)
|
4 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
