Solar Tracking Object
Prophead100
Posts: 192
Folks,
The forums have a lot of good discussion on solar tracking, particularly with sensors and even some mechanical timing set ups. There is even some basic-stamp code on tracking going back a ways but I did not see a propeller object or methods.
So, I put together an object (see attached) that I am testing out. Its not very compact and has a fair amount of documentation for refinement purposes. My goal is a fairly simple two axis tracking code with almanac data adequate (low precision +/- a degree or so) for aiming flat panels at the sun or using the inverse angles for a mobile sun dial. I am not using a single axis because the mounting for the applications I am interested may change in alignment and tilt so coordinates relative to the horizon and north are best although I may use sensors for refinement.
If anyone has a better object, other examples, helpful suggestions or critique of the code, I would love to hear it.
Thanks
Prophead100
The forums have a lot of good discussion on solar tracking, particularly with sensors and even some mechanical timing set ups. There is even some basic-stamp code on tracking going back a ways but I did not see a propeller object or methods.
So, I put together an object (see attached) that I am testing out. Its not very compact and has a fair amount of documentation for refinement purposes. My goal is a fairly simple two axis tracking code with almanac data adequate (low precision +/- a degree or so) for aiming flat panels at the sun or using the inverse angles for a mobile sun dial. I am not using a single axis because the mounting for the applications I am interested may change in alignment and tilt so coordinates relative to the horizon and north are best although I may use sensors for refinement.
If anyone has a better object, other examples, helpful suggestions or critique of the code, I would love to hear it.
Thanks
Prophead100
zip
96K
Comments
Very nice object.
Slight problem, SolarDemo4 errors when looking for "Solar2.3.spin". I changed it to "Solar2.4.spin", which was in the .ZIP, and it worked fine, (I assume)
And a nit pick:
Convention says that longitude West of the prime meridian is negative, and East is positive.
Nit pick off.
Is there a way to directly send commands to the object?
Say, sending time setting commands from the terminal?
I just saw another minor detail, apparently there is a divide by zero error or something similar as the ALTitude passes through zero. The display goes to a large interger value instead of the well behaved value of "00.00". Not a big deal.
Duane
I will look at changing the +/- convention on the final version. I had kept it as is for now because it matched the equations directly in the sources I used. Once I get the "bugs" out I will also look more at the user interface issues as well. I updated the zip file with version that have the 2.4 reference fix. (That's what happens when you run too many programs at once I suppose) I also included another rough demo I am working on that runs a couple servos and an LCD as well but, of course, the solar object is what I am really focused on.
-Prophead100
There seams to be a technical problem that occurs between 23:59 and 1:00.
Apparently, after midnight the time advances to 12:00 for one hour. Then at 1:00 it goes back to normal again.
I assume this period should start with 00:01 instead of 12:01. So this period is 12 hours ahead.
The math part is working correctly though.
Is there anyway to do the calculations with seconds resolution?
Thanks!
Duane
I will look into the 23:59 glitch. I believe the clock itself is correct but I didn't do the interface correctly where I am reading the time from the calculator which gets it from the clock, And yes, that's a good idea on the seconds. It should be easy to add and would help on putting finer resolution in the output.
-Prophead100
The 23:59 glitch turns out to be due to the fact that the solar equations are on a 24 hour solar clock where numbers representing up to 23:59 can be used which are ahead or behind the real time clock while the real time clock is on a 12 hour clock with AM/PM flags. There is also a little quirk with the demo where it is rounding clock time when estimating the solar time. The other important things this highlighted was the some of the equations indicate the angle may be off outside of day light hours. Drat! there goes the ability to point the neutrino detector at the night during the night... However, with a little code in the object to eliminate the 0 minutes and 60 seconds conditions in the demo code it should better now. ( I updated the zip file with the fixes).
The divide by zero error seems to be a special case as one approaches the horizon. I am still looking into the object to see if there is a simple fix that would confuse any other code. The other option is to filter out extreme "near zero" events in the demo.
To partially address the thought of an easier interface a couple methods were added to the object to be able to get the sun's altitude and azimuth directly from the time, date and geographic location without interim steps in the main program or top object. This may lead to more options later to run this in another cog independently updating variables.
-Prophead
While experimenting I noticed Hour Angle and DEClination were calculated which are useful for driving Polar Axis tracking mounts.
I am learning how to run a DS1307 clock for a master clock source.
Although, I'm not sure there is an advantage doing this other than the battery, or super cap, backup power.
Further, I am trying to do an angle bisecting calculation using the "Spherical law of cosines" to operate heliostats and parabolic troughs.
Thanks!
Duane
It could also allow you to save power in a battery application. You can largely power down the propeller overnight or between times when you need the calculations or movement control. The trick is that you stop objects to shut down cogs then slow the chip-clock speed while you wait for a pin input or a timer. It can cut power usage by 90+ percent when not needed.
In the attached code I wrote for a recent project you can see how the program handles a request to "hibernate" and shuts down 6 cogs and slows the clock then wakes up, speeds up the clock, restarts the objects and gets busy with video, serial output, counters and other time sensitive and power hungry tasks.
The spherical law of cosines sounds like a good challenge. Would it help where your heliostat or parabolic trough has variable geometry?
I assume what you mean by "variable geometry" is the geometry between the sun, mirror, and receiver constantly change throughout the day as in heliostats.
As opposed to the direct trackers which have fixed geometry.
The "spherical law of cosines", see:
Spherical_law_of_cosines
and the related "Law of haversines", see:
Law_of_haversines
are used to compute navigational angular bearing and distance on the earth or a sphere.
Another navigational need is the midpoint. See:
latlong.html
Heliostats aim their mirrors normal to the midpoint between the sun and a target or receiver, (where you want the light to go).
You might ask, why not just simply average the azimuth and altitude angles to find the midpoint. Well you could if the sun and receiver were close to each other and you can tolerate the errors. The spherical math methods have no error for any orientations.
Anyway, making an added function to the math library for these procedures would be quite useful for many applications
That QB45 program I sent you uses these function for heliostat calculations, download:
SolPos1.zip
I looked for general navigation objects in the OBEX but didn't find anything, but maybe I didn't recognize what I was looking for.
Duane
Is this the basic code section you are referencing?
' ALTmir
dlong = ABS(AZrec - AZsun)
Bx = COS(ALTsun) * COS(dlong)
By = COS(ALTsun) * SIN(dlong)
ALTmir = FNatn2(SIN(ALTrec) + SIN(ALTsun), SQR((COS(ALTrec)+Bx)^2+ By^2))
' AZmir is indeterminate when
' receiver & sun are close to antipodal
AZmir = FNatn2(By, COS(ALTrec) + Bx)
' fix polarity
IF AZrec > AZsun THEN AZmir = AZrec - AZmir
IF AZrec < AZsun THEN AZmir = AZrec + AZmir
'???IF By = 0 AND (COS(ALTrec) + Bx) = 0 THEN AZmir = AZrec + HPI
IF By = 0 AND (COS(ALTrec) + Bx) = 0 THEN AZmir = AZrec + HPI : SOUND 400 , 9
'????
IF AZrec = AZsun THEN AZmir = AZrec : : SOUND 600 , 9
' normalize to between 0 & 360 degrees
IF AZmir >= TPI THEN AZmir = AZmir - TPI
IF AZmir < 0 THEN AZmir = AZmir + TPI
However, I suspect these are based on rectilinear math rather than spherical math. I once wrote a Lotus 123 spreadsheet based on rectilinear coordinates. It did work but was quite crude.
But I don't really know.
I know that the math guys always us the spherical math methods.
Yes, that code is the core calculation for the more conventional "Vertical Axis" heliostat mount. Like what was used at Solar II.
I researched how to do this on several websites. A primary site was from "Movable Type Scripts" which has several applets to help visualize and test the codes. I pretty much copied these equations especially the ones relating to the "Midpoint".
All the "IF" statements fix things where the "computer" trig functions don't behave nicely. If this was done with a "Calculator" the IFs wouldn't be needed.
The next section does the same thing for "Receiver Axis" heliostat mounts where the main axis is aimed directly at the receiver and the mirror is tilted on that axis.
With the calculated values one can operate other more unusual tracking mounts such as "Compound Linear Fresnel Reflectors", CLFR, and Arc Heliostats as well as arbitrarily oriented mounts.
Did you get the QB45 SolPos1.bas program running? There are several operational modes.
1. Pure manual operation.
2. Auto mode running in real time
3. Table generation mode.
The Config file SolPos1.cfg sets thing up.
I can't thank you enough for coding this stuff
Duane
For a long time I have wanted to build a Solar Tracker.
Finally, I have designed a nice 2-axis unit. All done in Autodesk Inventor Pro 10.
Some parts already been made. To complete the unit I will definitely need another month, no less.
Are you have mechanical part of your project already made?
My big problem is: I am Mechanical Engineer... And my ability to design elestronic part of the project is very, very limited! Since I have to learn programming from zero. (Forget about putting it all togeher in electrical enclosure)
Do you have a suggestion?
I was looking for a helping hand for q while now. Spoke with several Electrical Engineers, they are not interested. Althought they liked the idea....
p.s. I started to learn & design some code in PBASIC, but it will probably take me a year before something workable will come out if ever...
On the electronics side, take a look at the The Parallax "Propeller Education " kit for learning how to hook up the prop to your hardware (stepper motors I assume). For actual design you may be able to use a modified protoboard or want to take a look at Diptrace for designing a board after you prototype something.
For electronic part of the project.
That could possibly be me.
I have extensive experience with solar tracking.
I am a complete newbie at spin though.
Email me directly at
redrok@redrok.com
(651)426-4766
Duane
i am very interested in this project as well i have did lots of research in my masters and doctoral program regarding solar harvesting is there a model to go along with the code to allow me to build a moch of the device ?
I am building a 2-axis Solar Tracker.
You can see a 3D picture above.
The actual building of the unit just started. It will take (as I see it now) month or two.
Only bi-polar steppers are installed in design. From AutoMationDirect.
Mechatronics for the project is not ready at all. Only talks, ideas at the moment.
When you talking "model to go along" what do you mean? A "bare bone" program or Mechanical Unit?
p.s. I am Mechanical Engineer and now learning programming and whatever goes along with this progect.
At present I think Prophead100 is providing core codes that generate the 4 basic parameters needed to drive the 2 basic "Direct" solar tracking mounts.
1. "Vertical Axis" tracking mount that moves in "AZimuth and ALTitude.
2. "Polar Axis" tracking mount that moves in Hour Angle and DEClination.
I assume, at this time, the user of these codes needs to write their own drivers for the type of motors their using. Of course, 5 wire stepper motors are the easiest to use and the Propeller is a nice platform to use.
There is another guy doing similar things with the Arduino. See:
Cerebral Meltdown
You might want to take a look.
Duane
Thanks for the note on the Arduino project. It is an interesting approach. I think the advantage of the propeller will be the ability to provide real time diagnostics and I/O for multiple panels without interupting the operations or adding power consumption when not needed. Not critical but quite useful when diagnosing problems or helping a client. In any event, I like the open source approach they use...
I am working on vector trig algorithms for the heliostat surface azimuth and altitude. As a side benefit it provides the incident angle of reflection for consideration in the refraction aspects of the reflecting surface materials. It employs accurate vector math that uses the law of cosines which is much better than averaging as you note.
It should be fairly accurate at typical ranges of hundreds of feet recognizing the deviations go up as a power of the distance so closer is much more accurate. Beyond that we'd have to go with the long distance laser pointing accuracy of some spherical equations which don't really add too much in short distances. As you get into the 1000's of feet then elevation loss and to a lesser degree atmospheric refraction become very measurable factors. From mountain to mountain you may need to drop a couple feet but barn to tower should be in small fractions of an inch which can be accounted for in field measurements. We can compensate for that to an extent but at that point, humidity and air pressure start to affect the 10%attributed to refraction and the azimuth would also need more refining as well. My guess is that the slightest variation in the reflector would begin to disperse the non-parallel light as well. Maybe, Ill add a basic compensation method just incase someone wants to be able annoy their neighbor across the river.
This trick will be to test the code. My test servo based test rig can probably get a sense if the code is correct but won't be accurate enough to begin the differentiate between hardware, electronics and software errors to the extent we can provide specific tolerances. Perhaps, that can come later as others are building the hardware or tweating code...
Yes, the "Law of Cosines" or the "Haversine" methods are exact except for the float arithmetic errors. In my research some prefer the haversine method for short range navigation but we are not concerned with both angle and distance. We are concerned only with bisecting angle of which the law of cosines does better, a bit simpler to boot.
I have to say, It doesn't really make much difference for heliostat accuracy requirements between medium and long distances..
OK, a bit of definitions are in order.
The sun subtends about 1/2 degree of arc, +- the time of year.
So, a tiny flat mirror would reflect an image of the sun also with 1/2 degree of arc. As a rule of thumb the image diameter is about 1% of the reflected distance. I.e. 1 foot at 100 foot distance.
Actual mirrors have a real dimension. The reflected image consists of an area the same size as the mirror, equivalent to the umbra, at full brightness. Plus a fading brightness around the edge, equivalent to the penumbra, of about 1/4 degree.
1. A "Short" distance is where the penumbra is much smaller than the umbra so the image is essentially the same size as the mirror.
2. A "Medium" distance is where the penumbra plus the umbra is about the twice the size as the mirror. At a distance about 100 times the mirror diameter.
3. A "Long" distance is where the image is mostly only the penumbra. Much further than 100 times the mirror diameter.
The deal is that at long distances the image diameter gets larger linearly with distance and the brightness goes down with the inverse square of the distance.
Anyway, what I'm saying is that beyond medium distances the tracking requirements don't increase and less than medium the accuracy requirements are diminished.
The best way to test true calculation accuracy is to compare your output with a much more accurate codes based on those from the "Astronomical Almanac". the only thing better is from JPL. We have a very good example from Stephen Moshier. See my link here:
AA-56.zip
This is an astronomy program that outputs data for the sun with arc seconds accuracy.
Duane
On heliostat code, I am slowly making progress. The sticky part right now is dealing with quadrants and identifying when the parameters are out of range for the formulas. Having the target at various heights south of the reflector within 50 degrees of south and reflecting solar azimuths between 75 and 285 seems quite doable.
I discussed with Duane my SolarTracker hardware design at great length.
He did pointed me in the right direction.
At this moment I will finish the linear inits as is. But later they will have to be changed, to make rotation at constant angular speed.
Both axes will have to be redesigned. Not a big deal. Just time. As always. Well, money too...
My learning had moved from dead end this weekend.
I have developed a code (see below) and laugh... It does what I wanted acomplish this weekend.
It turns on the red & green LED depending which photoresistor is getting more light.
In the future LED's to be replaced with steppers to rotate them CW or CCW accordingly.
I will probably never get to your level or Duane's, but hay(!) I had a lot of fun this wekend.
Comments on the code below welcome!
' POT.BS1 ' This program demonstrates the use of the POT command. Connect one side ' of a 10K potiometer to P0. To the other side of the potentiomenter ' connect a 0.1 uF capacitor, and then connect the second side of the ' capacitor to Vss (ground). Before running demo program, use the ' Run | POT Scaling dialog to determine the best Scale factor. ' The above used as template to start the development. ' The code below is edited from original. ' {$STAMP BS1} ' {$PBASIC 1.0} SYMBOL PotPin0 = 0 ' 10K pot connected to P0 SYMBOL Scale0 = 50 ' scale value for test circuit SYMBOL PotPin1 = 1 SYMBOL Scale1 = 50 SYMBOL level0 = B2 ' storage of pot "level1" SYMBOL level1 = B3 ' storage of pot "level2" Main: LOW 7 LOW 6 'Left photoresistor check POT PotPin0, Scale0, level0 ' read pot level DEBUG "Level0 = ", #level0, CR ' display 'Right photoresistor check POT PotPin1, Scale1, level1 ' read pot level DEBUG "Level1 = ", #level1, CR ' display PAUSE 2000 DEBUG CLS Compator: IF B2>B3 THEN lightb3 lightb2: HIGH 7 PAUSE 500 GOTO Main IF B2<B3 THEN Repeate lightb3: HIGH 6 PAUSE 500 Repeate: ' short delay GOTO Main ' repeat foreverGreat to see you are jumping right in. That's the best way to really learn how things work and the Basic Stamp is a great platform that I have used many times. Fortunately, the Basic Stamp and Propeller are very forgiving. I have accidentally exceeded the limits many times, including this weekend and definitely appreciate the engineering they did to help the controller survive. The Stamp can easily run your hardware and there is a lot of good background on circuits and code. You can always upgrade to the Propeller and its expanded abilities later. When your ready to design your system you can find some good resources for the Stamp or Propeller such as the "Micro-Controller Application Cookbook " by Matt Gillibrand.
In terms of your code, take a look at Chapter 5 of the "What is a Microcontroller." (http://www.parallax.com/go/WAM) It has a great example of how to use a command called "RCTime" to measure the rotation of the potentiometer via the resistance and the time it takes to charge or discharge the capacitor. It sounds tricky but they explain it pretty well in the workbook that you can download.
-Prophead100
RCTIME is from BS2 version
BS1 has POT command and it is very similar in function if not the same. This is what I used. I will post pictures of my creation hopefully today.
BS1.... ...I learn something new each day. Thanks
If you decide to start experimenting with the Prop then you can also start to use a pair of pins in a not too disimilar configuration as "Sigma Delta" analog-to-digital converter... Its a slick concept that uses the concept of a voltage crossing the on/off threshold as a trigger to determine voltage of the input. Its hard to explain but very useful.
Set-up:
1. 12x4 PV panel
1. Miniature DC electric motor from Radio Shack experimental kit
Experiment# 1
Voltage from PV panel, no load attached 22.6v
Voltage when connected to DC motor and aligned normal to the sun .6v.
DC motor runs at full speed.
Experiment# 2
Voltage from PV panel, no load attached 22.6v
Voltage when connected to DC motor and aligned at ~35 degress from normal to the sun .3v.
DC motor runs at stalling speed. I can surely notice that it runs at least 1/2 rpm from when PV is directed normal to the sun.
This experiment is made to discuss the issue of importance of aligning PV panels normal to Sun at all times.
It is obvius that is important not to allow misalignment of more then 10 degrees from normal.
Within 10 degrees it is looks like misalignment have little or no effect.
After 40-45 misalignment from normal PV panel surely losing about 60% of available power under current sun condition.
I would like to discuss with the "crew" the importance of adding a second axle when building a Solar Tracker.
It is obvius to me that collecting all vailable power from the Sun is important to make a cost effective Solar Trackers. To my opinion a working two axle mechanism will cost no less then $1000.00 (mechanism only). Losing 10% of energy seems very costly to me. This systems must run year after year and any loss will accumulate to a large number of KW.
The propeller and solar object should help you with either approach. It can give declination and hour angle for the single axis approach or altitude & azimuth for the two axis approach. Regardless of which approach you use, the other factor to consider based upon the hardware is how often you move the panel. This "slew" rate can be be either continuous or only move periodically (when the angle is too big and power is being lost). You can estimate the slew rate per minute for each axis by calculating the angle of the sun a minute apart and subtracting the two. Basically, you are balancing the cost of moving the panel verses the value of the power gained. This is where a micro-controller can really pay for itself. If you develop the cost curves for your specific equipment then the propeller could help optimize this savings by moving differently depending on the season and weather (e.g. cloudy days) and power status. For example, it may not be worth moving the panel on a dark cloudy morning but bright sun later in the day could justify moving the panel. At that point you may also want to look into how to the concepts used for pyrheliometers, pyranometers and irradiance meters to monitor the strength of the sun. The TAOS TSL235 and TSLR237 light to frequency sensors and AD592 temperature sensor that Parallax carries could be used to develop a basic monitoring system that can inform the systems on the benefit of moving or staying put.
Thanks for your help!
I am going forward with mechanism, all large parts have been already made.
This week I am planning to order McMaster components and start on linear drives. Sprockets & belts already delivered.
It is looks to me, and your post proves this idea, that it is better to divide the moving "sector" by 10 or better 5 degrees sectors and simply move panel by time. Placing microprocessor in sleep mode b-n moves.
Each position can be identified (using absolute encoder as A1, A2, A3.... B1, B2... Means tracking starts in the morning at A1 and stops at let's say C3.
For example the tracking view can be divided (160degree / 10degree = 16 positions. Means I will have to start at position 1 and finish the day at position 16. My processor will start only 17 times a day.
At the end of the day panel need to be moved to positon "1".
As for power for the alignment mechanism, a separate small PV (installed along with main panels) panel needed to charge motorcycle battery during the day. Emergency power supply could be necessary, in case of several cloudy days.
This is one of the bigger chestnuts in choosing an approach - but even here, there are more than two choices.
The issue is not only one of pure mechanics-cost, but also wind loading and maintenance, as well as deployment constraints.
Add to this, the fact that PV prices are still falling, but engineering prices (labour) is rising.
The largest area, simplest mechanics, Solar trackers, have a long common horizontal axle.
Then you have tilted axis units, but they can still use a robust/reliable axle design.
The tilt can largely be install-fixed as you can favour winter-optimal angles, as most users prefer a better average, than a summer peak.
Full freedom two-axis trackers are mandatory for heliostat systems, and the errors allowed are much smaller, but it is harder to imagine a Solar PV problem, that has full 2 axis as the solution ?
I could see a place for a Louvered PV tracker, but even there you trade off a (say) 50% saving in PV area, for a lower peak, but wider skirts in your power profiles, and (much) higher install and maintenance costs.