Hehe actually that was one of the consideration but our prof wants it=20
done by calculation though the light sensor provides a better=20
solution since when it is raining the motor would not move. Servo=20
Control was also one of the consideration. But oh well... the=20
presentation is in 2 week's time. >.< but definitely much to learn=20
about programming a robot. Hopefully i can do much more next time.

Minghui
--- In o...@yahoogroups.com, Brian Lloyd wrote:
>
>=20
> On Apr 1, 2008, at 4:37 AM, minghui1984 wrote:
>=20
> > Thanks all for the replies. More stuff learnt with every post. I=20
just
> > realised that oopic does not support double or float numbers? hmm
> > this is because my application deals with controlling a stepper=20
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=20
i
> > store a values from the calculations and calculate inverse. One=20
more
> > problem is i realised that only single step movement is possible=20
for
> > the stepper function. >.<
> >
> > Guess i have to make do, the oopic simple interfacing allows me=20
to do
> > the prototype that demostrates my solar tracking. Hmm perhaps i=20
would
> > list it as future improvement.
>=20
> Why not just change from open-loop (time-of-day) to closed loop=20=20
> tracking? When the sun goes down drive your tracker back to its=20=20
> easternmost position. When the sun comes up, use a pair of light=20=20
> sensors separated by a vertical baffle (parallel to the polar axis=20
on=20=20
> your tracker) with a light sensor on either side. If the panel is=20
not=20=20
> facing the sun, the baffle will shade one sensor or the other. Use=20=20
> that do drive your tracking motor one way or the other until both=20=20
> sensors see the same light level. Now you won't need to know the=20
time=20=20
> of day and your tracker will work just fine based on sun position.
>=20
> Here is a bit of a diagram. Use a fixed-width font to view:
>=20
>=20
> SSS
>=20
> |
> |
> |
> s | s
> -------
> P
>=20
>=20
> SSS =3D sun
> s =3D light sensor
> P =3D polar axis (coming out of the screen toward you)
>=20
>=20
> --
>=20
> 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
>=20
> I fly because it releases my mind from the tyranny of petty=20
things . . .
> =97 Antoine de Saint-Exup=E9ry
>=20
> PGP key ID: 12095C52A32A1B6C
> PGP key fingerprint: 3B1D BA11 4913 3254 B6E0 CC09 1209 5C52 A32A=20
1B6C
>

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



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

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=20=20
failure. Heck, you can use the light sensor to time-calibrate your RTC=20=20
if you like by using your light sensor array as a sun-dial. :-) You=20=20
can detect sunrise and sunset and use that to determine a rough cut on=20=20
day-of-year and time-of-day. (Celestial navigation is your friend.)

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

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

The earth rotates 15 degrees per hour. A positioning error of up to 15=20=20
degrees is not going to make a difference as the Cosine of 15 degrees=20=20
is .97. So repoint your panel every hour. That makes your table pretty=20=20
small, i.e. 20x14 or so. (How many hours in the longest day? 24 if you=20=20
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=20=20
actually does something (and you don't have to deal with someone=20=20
else's aborted idea of a UI). There isn't a lot of rocket science=20=20
involved and code that does real things can be developed pretty quickly.

> Minghui
> --- In o...@yahoogroups.com, Brian Lloyd 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 =3D sun
>> s =3D light sensor
>> P =3D 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 . . .
>> =97 Antoine de Saint-Exup=E9ry
>>
>> PGP key ID: 12095C52A32A1B6C
>> PGP key fingerprint: 3B1D BA11 4913 3254 B6E0 CC09 1209 5C52 A32A
> 1B6C
>> ------------------------------------



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

Wikipedia has a couple of equations for the declination of the Sun
http://en.wikipedia.org/wiki/Declination

You also need the Greenwich Hour Angle

There is a pretty decent explanation here:
http://answers.google.com/answers/threadview?id=782886

Unless you use a coprocessor, you can't do the calculation with the
OOPic. A table lookup is good but, with a coprocessor, calculation
shouldn't take too long.

Richard

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



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

Hei Brian,=20

Thanks for the advice. That was what i was thinking. Generating the=20
values beforehand. Hehe. Anyway my table is going to be huge. As our=20
project involves a concentrator and a MJC so the light rays kinda=20
need to be perpendicular to the concentrator for maximum efficency.=20
So would have to update regularly during the period from 11-1pm where=20
the sun shifts alot.

What a huge project that my prof assigned to my group >.<

Minghui

--- In o...@yahoogroups.com, Brian Lloyd wrote:
>
>=20
> On Apr 4, 2008, at 2:21 AM, minghui1984 wrote:
>=20
> > Hehe actually that was one of the consideration but our prof=20
wants it
> > done by calculation though the light sensor provides a better
> > solution since when it is raining the motor would not move.
>=20
> A combination of the two provides backup in case of a sensor or=20
clock=20=20
> failure. Heck, you can use the light sensor to time-calibrate your=20
RTC=20=20
> if you like by using your light sensor array as a sun-dial. :-)=20
You=20=20
> can detect sunrise and sunset and use that to determine a rough cut=20
on=20=20
> day-of-year and time-of-day. (Celestial navigation is your friend.)
>=20
> First, I strongly recommend that you cheat. That is, do your heavy=20=20
> math calculation on something that is happy doing heavy math=20=20
> calculation, e.g. your PC. Have it produce a table you then store=20
in=20=20
> the ooPIC's flash. This will be an hour-angle value for the=20
position=20=20
> of the sun. You will need to calculate this table for different=20
times=20=20
> during the year but you will find that around the June and=20
December=20=20
> solstices, things don't change very much for quite some time=20
(other=20=20
> than sunrise and sunset times) so you will need fewer rows in your=20=20
> table around that time of year. Near the equinoxae you will need=20
your=20=20
> table rows to be closer together in calendar time. All in all you=20
can=20=20
> probably get away with twenty rows.
>=20
> (Or are you positioning in both X and Y in order to deal with=20
changes=20=20
> in declination with the seasons?)
>=20
> The earth rotates 15 degrees per hour. A positioning error of up to=20
15=20=20
> degrees is not going to make a difference as the Cosine of 15=20
degrees=20=20
> is .97. So repoint your panel every hour. That makes your table=20
pretty=20=20
> small, i.e. 20x14 or so. (How many hours in the longest day? 24 if=20
you=20=20
> are above the arctic/antarctic circles.)
>=20
> > 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.
>=20
> Process control is my favorite form of programming as your code=20=20
> actually does something (and you don't have to deal with someone=20=20
> else's aborted idea of a UI). There isn't a lot of rocket science=20=20
> involved and code that does real things can be developed pretty=20
quickly.
>=20
> >
> >
> > Minghui
> >
> >
> > --- In o...@yahoogroups.com, Brian Lloyd 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?=20
hmm
> >>> this is because my application deals with controlling a stepper
> > motor
> >>> to move a solar tracker, not quite the usual applications that=20
ppl
> >>> use the oopic for. So i didn't realised when i ordered, how=20
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=20
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.=20
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=20
position.
> >>
> >> Here is a bit of a diagram. Use a fixed-width font to view:
> >>
> >>
> >> SSS
> >>
> >> |
> >> |
> >> |
> >> s | s
> >> -------
> >> P
> >>
> >>
> >> SSS =3D sun
> >> s =3D light sensor
> >> P =3D 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 . . .
> >> =97 Antoine de Saint-Exup=E9ry
> >>
> >> PGP key ID: 12095C52A32A1B6C
> >> PGP key fingerprint: 3B1D BA11 4913 3254 B6E0 CC09 1209 5C52=20
A32A
> > 1B6C
> >>
> >
> >
> >
> > ------------------------------------
> >
> >



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

I guess i would have to generate the data beforehand but the
calculation part has already been done. didn't know that there was a
limit to what the PIC could do. >.< Well regarding the coprocessor
could be a bit tricky as i have absolutely no idea how to link the
coprocessor with ooPIC. but thats a good suggestion which i can do for
future improvements.

Minghui

--- In o...@yahoogroups.com, "rtstofer" wrote:
>
> Wikipedia has a couple of equations for the declination of the Sun
> http://en.wikipedia.org/wiki/Declination
>
> You also need the Greenwich Hour Angle
>
> There is a pretty decent explanation here:
> http://answers.google.com/answers/threadview?id=782886
>
> Unless you use a coprocessor, you can't do the calculation with the
> OOPic. A table lookup is good but, with a coprocessor, calculation
> shouldn't take too long.
>
> Richard
>

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



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )