Friday, April 4, 2008

Re: [oopic] Re: Providing a clock/time to the PIC

On Apr 4, 2008, at 2:21 AM, minghui1984 wrote:

> Hehe actually that was one of the consideration but our prof wants it
> done by calculation though the light sensor provides a better
> solution since when it is raining the motor would not move.

A combination of the two provides backup in case of a sensor or clock
failure. Heck, you can use the light sensor to time-calibrate your RTC
if you like by using your light sensor array as a sun-dial. :-) You
can detect sunrise and sunset and use that to determine a rough cut on
day-of-year and time-of-day. (Celestial navigation is your friend.)

First, I strongly recommend that you cheat. That is, do your heavy
math calculation on something that is happy doing heavy math
calculation, e.g. your PC. Have it produce a table you then store in
the ooPIC's flash. This will be an hour-angle value for the position
of the sun. You will need to calculate this table for different times
during the year but you will find that around the June and December
solstices, things don't change very much for quite some time (other
than sunrise and sunset times) so you will need fewer rows in your
table around that time of year. Near the equinoxae you will need your
table rows to be closer together in calendar time. All in all you can
probably get away with twenty rows.

(Or are you positioning in both X and Y in order to deal with changes
in declination with the seasons?)

The earth rotates 15 degrees per hour. A positioning error of up to 15
degrees is not going to make a difference as the Cosine of 15 degrees
is .97. So repoint your panel every hour. That makes your table pretty
small, i.e. 20x14 or so. (How many hours in the longest day? 24 if you
are above the arctic/antarctic circles.)

> Servo
> Control was also one of the consideration. But oh well... the
> presentation is in 2 week's time. >.< but definitely much to learn
> about programming a robot. Hopefully i can do much more next time.

Process control is my favorite form of programming as your code
actually does something (and you don't have to deal with someone
else's aborted idea of a UI). There isn't a lot of rocket science
involved and code that does real things can be developed pretty quickly.

>
>
> Minghui
>
>
> --- In oopic@yahoogroups.com, Brian Lloyd <brian-wb6rqn@...> wrote:
>>
>>
>> On Apr 1, 2008, at 4:37 AM, minghui1984 wrote:
>>
>>> Thanks all for the replies. More stuff learnt with every post. I
> just
>>> realised that oopic does not support double or float numbers? hmm
>>> this is because my application deals with controlling a stepper
> motor
>>> to move a solar tracker, not quite the usual applications that ppl
>>> use the oopic for. So i didn't realised when i ordered, how would
> i
>>> store a values from the calculations and calculate inverse. One
> more
>>> problem is i realised that only single step movement is possible
> for
>>> the stepper function. >.<
>>>
>>> Guess i have to make do, the oopic simple interfacing allows me
> to do
>>> the prototype that demostrates my solar tracking. Hmm perhaps i
> would
>>> list it as future improvement.
>>
>> Why not just change from open-loop (time-of-day) to closed loop
>> tracking? When the sun goes down drive your tracker back to its
>> easternmost position. When the sun comes up, use a pair of light
>> sensors separated by a vertical baffle (parallel to the polar axis
> on
>> your tracker) with a light sensor on either side. If the panel is
> not
>> facing the sun, the baffle will shade one sensor or the other. Use
>> that do drive your tracking motor one way or the other until both
>> sensors see the same light level. Now you won't need to know the
> time
>> of day and your tracker will work just fine based on sun position.
>>
>> Here is a bit of a diagram. Use a fixed-width font to view:
>>
>>
>> SSS
>>
>> |
>> |
>> |
>> s | s
>> -------
>> P
>>
>>
>> SSS = sun
>> s = light sensor
>> P = polar axis (coming out of the screen toward you)
>>
>>
>> --
>>
>> Brian Lloyd Granite Bay Montessori
>> brian AT gbmontessori DOT com 9330 Sierra College Blvd.
>> +1.916.367.2131 (voice) Roseville, CA 95661, USA
>>

http://www.gbmontessori.com
>>
>> I fly because it releases my mind from the tyranny of petty
> things . . .
>> — Antoine de Saint-Exupéry
>>
>> PGP key ID: 12095C52A32A1B6C
>> PGP key fingerprint: 3B1D BA11 4913 3254 B6E0 CC09 1209 5C52 A32A
> 1B6C
>>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

--

Brian Lloyd Granite Bay Montessori
brian AT gbmontessori DOT com 9330 Sierra College Blvd.
+1.916.367.2131 (voice) Roseville, CA 95661, USA

http://www.gbmontessori.com

I fly because it releases my mind from the tyranny of petty things . . .
— Antoine de Saint-Exupéry

PGP key ID: 12095C52A32A1B6C
PGP key fingerprint: 3B1D BA11 4913 3254 B6E0 CC09 1209 5C52 A32A 1B6C


------------------------------------

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:

Post a Comment