signal work? Could you then read the signal and empirically determine
servo position?
Always looking for the easy way out...
--- 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
>
> On 11/10/07, rtstofer <rstofer@...> wrote:
> > > I'm doing this as a project for a university course. If it
makes any
> > > difference, they've got a lot of equipment lying around. I can
have as
> > > many oopics as I need. They've also got cmucam2's.
> > >
> > > Would it help if I had the processing power of more than one
oopic?
> > >
> > > Also, this is from the cmucam2's manual:
> > >
> > > "For even slower processors, the camera can operate in "poll
mode". In
> > > this mode, the host processor can ask the CMUCAM2 for just a
single
> > > packet of data. This gives slower processors the ability to more
> > > easily stay synchronized with the data."
> > >
> > > I'm thinking... I only need the X position to move the base of
my
> > > robot. One sample a second is plenty fine. Can't the oopic do
even that?
> >
> > The problem is that the hardware USART (the oSerialPort object)
only
> > has a 4 byte FIFO. Your code needs to prevent overflow at the
data
> > rate established for the camera. You do this by setting the Track
> > command to return the minimum amount of data required for the
> > application. There's a way to do this but I don't have the
manual in
> > front of me.
> >
> > Next, you need to be waiting in a loop for the data to arrive.
You
> > need to grab it and put it in a buffer as quickly as possible so
you
> > can get back to the polling before the queue overflows. Once you
have
> > the complete response, you can begin to process from the buffer.
> >
> > I would think there is a problem sitting around waiting on the
USART
> > rather than driving the 'bot. Part of that is resolved by making
the
> > 'bot motion run from virtual circuits. This pushes the logic out
of
> > code and down to the interpreter object evaluation loop, a very
good
> > thing to do. Or at least make sure that your loop gets back to
the
> > USART as quickly as possible.
> >
> > If you don't want to buffer the data, have your loop look like a
state
> > machine that is interpreting the data as it arrives.
> >
> > Serial I/O is not a strong point for the OOPic.
> >
> > You could try two OOPics connected by oDDELink. One OOPic handles
> > only the serial I/O and leaves the value in a variable that the
> > oDDELink object serves up.
> >
> > People have had problems with the I2C link. Check to be sure you
have
> > pull-up resistors on the order of 2.2k or so. Higher values may
be a
> > problem. OTOH, I have heard that OOPic-R boards don't like the
low
> > value resistors but that is specific to the 16F877A chip and not
the
> > OOPic-II+ which is based on the 16F877 chip.
> >
> > 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:
No comments:
Post a Comment