Anotherpower.com Forum

Project Journals => User Journals => RossW => Topic started by: rossw on March 14, 2013, 03:03:11 am

Title: Tracker Cluster controller.
Post by: rossw on March 14, 2013, 03:03:11 am
Can't leave things alone!

After the success of my previous controller for a number of people (myself included), I came up against one issue that was just plain annoying me. And that is that using one controller for a cluster or field of arrays just isn't working "right".

Trying to make sure all the actuators track at the same rate under all conditions is almost impossible.
Trying to get all the arrays to start and stop at the same point is fiddly and time consuming.
Trying to get the tracking to follow the sun just so is more complex than just linear moves permit.

So, my latest plans for world domination are semi-autonomous controllers.

Each array has a small controller attached to it.
Each array has a single pair of wires (figure-8 flex will do) to connect them all together.
The bus thus made connects to one "control" unit.

In its simplest form, the control unit periodically wakes up, turns on power to the bus, tells all the arrays where the sun is now, and each arrays own smarts (using an inclinometer) positions itself square on to the sun. The controller then shuts the power off the bus ready for the next move.

The electronics for each tracking array look a little daunting, but they're actually fairly simple.
I've built some prototypes - here's one:
(http://general.rossw.net/webcontrol/tracker-bus-pcb-incl.jpg)

I'm only working on it in my "spare" time (haha!), but so far I've got the communications from controller to downrange, the communications back to controller, the supplys and all the trigonometry for working out the angles from the 3-axis accelerometer done.

This afternoon I completed testing of code to send a "Tell me where you're pointing" command, and getting back X/Y angles!

Commands defined and partly coded so far are:
* Address an individual controller or the entire farm.
* GoTo position. (Sun angle during the day, or safe parking during high wind, overnight or for cleaning)
* Request current position (x/y angles)
* Request last actuator current

I'm sure there will be more things. I've only used about half the code space so far so plenty of scope yet.

In the pipeline is code to use PWM to maintain the actuator speed regardless of supply voltage, automatic "limit switch" to set maximum and minimum tilt angles, actuator current limits (in the event it jams or get sticky), "ALARM" mode where an array can send back an "I require service" signal.
Title: Re: Tracker Cluster controller.
Post by: philb on March 14, 2013, 08:47:41 pm
Super neat Ross!
Can't wait for the next post.
Title: Re: Tracker Cluster controller.
Post by: Wolvenar on March 16, 2013, 02:25:17 am
The usual awesome Ross!
Title: Re: Tracker Cluster controller.
Post by: bj on March 16, 2013, 07:41:15 am
    Don't know which amazes me more----the project itself, or how much you can get done, in your
almost non existent spare time.  Impressive.
Title: Re: Tracker Cluster controller.
Post by: ghurd on March 16, 2013, 09:03:03 am
they're actually fairly simple.

Simple is not the first word that came to mind.

I never considered multi array tracking issues.
Very nice Ross.
G-
Title: Re: Tracker Cluster controller.
Post by: rossw on March 27, 2013, 12:02:22 am
Haven't had so much time to work on this, but little bit at a time, half an hour here and there.

Software is just about ready to make its debut. PWM soft-start works great. Software-controlled current limit stops the thing pushing hard enough to damage anything if it gets caught or an actuator sticks. "Virtual Limit Switches" stop it driving past the angles I set etc. Send commands, query status, array angles, actuator drive current etc all working great.

Got a case that may have been made for the board. Bulkhead mounting, so it can just attach directly to the back of the tracker frame.
Here it is without the lid on:
(http://house.albury.net.au/27mar2013/100_5988.JPG)

And from where you'd normally "see" it when its mounted. I'll take another pic when installed.
(http://house.albury.net.au/27mar2013/100_5990.JPG)
Title: Re: Tracker Cluster controller.
Post by: Wolvenar on March 27, 2013, 02:03:23 pm
Are you going to do your balloon trick with this one when it's ready for use?
Or is it not possible to seal up that well?
Title: Re: Tracker Cluster controller.
Post by: rossw on March 27, 2013, 02:29:54 pm
Are you going to do your balloon trick with this one when it's ready for use?
Or is it not possible to seal up that well?

This ones case is not waterproof - it's a "close fit" and water won't run into it, but because of that the balloon won't work.
Upside, because it's designed to mount UNDER the panels, it won't get much exposure to the weather (unlike a bright-spot tracker which has to directly "see" the sky)

I'll drill a small bleed hole and force some cotton thread in it to permit moisture extraction, if it becomes a problem I'll replace it with a waterproof case and do the balloon trick, for sure.
Title: Re: Tracker Cluster controller.
Post by: bj on March 28, 2013, 05:53:16 am
  Sure is nice and tidy Ross.  Doubt that water will be a problem, where you are mounting.
  Of course I've been wrong many, many, times before. :)
Title: Re: Tracker Cluster controller.
Post by: rossw on March 28, 2013, 08:42:24 pm
  Sure is nice and tidy Ross.  Doubt that water will be a problem, where you are mounting.
  Of course I've been wrong many, many, times before. :)

Yeah, "plan for the worst, hope for the best" is a good policy though.

Have had a change in thoughts on recording the actuator current. Original plan was to just keep in in RAM and come back later to read it. However there are some technical issues with that - if anything happens on the bus, there's no way to recover lost data. So since the processor already has 256 bytes of  EEPROM internally, and I'm only using a dozen bytes for configuration information (device ID, calibration points for the 3-axis accelerometer, current limit, virtual limit switches, etc) - so I decided to store the actuator current in memory.

A quick calculation however, showed that if I stored a value every 5 minutes, for 12 hours a day - I'd "burn up" an EEPROM in 2 years (based on the manufacturers 'minimum life' figures). Of course, it might last much longer than that, but thats all I could count on. And frankly - designing something to fail in a mere 2 years wasn't good enough.

After some research, the cycle life is per cell, not for the entire EEPROM. So I've written some wear-levelling code that cycles over 100 bytes. It's a little bit tricky, but it takes the "designed failure" to a minimum of around 100 years if used every 5 minutes, 12 hours a day, every day. I'm happy with that!

Just a couple of tricky last bits to add, and I'm ready to put it in the field and try it!