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@pacbell.net> 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