This Forum is Dedicated For all The Object Oriented PIC Lovers .......... The concept behind OOPic is straight forward. Use preprogrammed multitasking Objects from a library of highly optimized Objects to do all the work of interacting with the hardware. Then write small scripts in Basic, C, or Java syntax styles to control the Objects. During operation, the Objects run continuously and simultaneously in the background while the scripts run in the foreground telling the objects what to do.

Saturday, November 10, 2007

[oopic] Re: OOPIC and CMUCAM

--- In oopic@yahoogroups.com, jon.buford@... wrote:
>
> On the other hand, there is something to be said for just adding a
> simple pot or optical encoder. It sounds like the serial solution will
> be fairly limited as it is, and it is good to consider if it will save
> time. Oh, depending on the amount of rotation, you might consider one
> of the flex sensors. You could even do some simple mechanical stoppers
> that give you increasing flex with the camera movement to help bias it
> to center.
>
> Jon

Since we are only interested in 'forward', an optical encoder could be
quite simple. Consider two concentric rings: the outer ring is black
when the platform is counterclockwise from 'forward' and the inner
ring is black when the platform is clockwise from 'forward'. The
non-black portion of each rings should be reflective - perhaps white.
You want to drive the vehicle such that the two retroreflective
sensors both see black. Space the sensors to minimize the included
angle where both sensors see black.

This type of sensor will work well:
http://www.junun.org/MarkIII/Info.jsp?item=14

A similar scheme using cams and limit switches would also work.

Resolution isn't important because the 'bot will eventually drive far
enough away from 'forward' that the error will be noticeable.

The PAK-VII is just implementing a counter. The platform 'forward'
position could be established as the servo receiving a 1.5 mS pulse
width. Any chip could be used to count with an internal timer the
width of the pulse. The output could be as simple as one IO line to
indicate the pulse is less than, say, 1.4 mS and the other to indicate
the pulse is greater than, say, 1.6 mS. Even a little 6 pin PIC could
do this job. I would probably go with an 8 pin device just because
they could probably be had in an DIP package.

The timing could also be measured by putting the pulse into an RC low
pass filter (probably buffered and run through a diode to prevent
contaminating the signal) and into an A/D port. The integrated
voltage would be a measure of pulse width. The problem with this
approach is that a 1.5 mS pulse every 20 mS would only produce a
0.375V signal. I might multiply that by 10 with an op amp. In fact,
use a dual op amp and let the first one buffer the signal. It might
even be possible to do the entire buffer/integrate/rescale operation
with a single op amp. Send the output of the op amp to a dual
comparator and there would be no need to use an A/D approach. When
the output is above some voltage, steer left. When it is below some
other voltage, steer right.

There are probably dozens of ways to get the 'bot to drive in the
direction of the camera.

Richard



Yahoo! Groups Links

<*> To visit your group on the web, go to:

http://groups.yahoo.com/group/oopic/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:

http://groups.yahoo.com/group/oopic/join

(Yahoo! ID required)

<*> To change settings via email:
mailto:oopic-digest@yahoogroups.com
mailto:oopic-fullfeatured@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
oopic-unsubscribe@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:

http://docs.yahoo.com/info/terms/

No comments: