Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - ben

Pages: [1] 2
1
Quote
>> why not move the motors when they are due to be moved (allowing some minimal threshold).
Now that I think of it, you can already do this in the program by turning the "updateEvery" value down to 1 second. This probably needs to be tested more though because I'm not sure if having small differences between the previous and present calculated sun's position leads to errors.

Good idea. When I get my system up and going, I will probably work on this.

i would probably calculate the suns position every 30-sec or-so, and every 1-sec or-so drive the motors the required number of pulses (ie 2 for motor-A and 0.333 for motor-B as (in the above example))

2
here is a crazy idea:

track the moon at nighttime

i would enjoy the moonlight shining into our windows, when we have a full-moon and clear-sky. :)

3
Add simultaneous movement to the stepper motors instead of having them take turns.

i would like to see this, but not because it looks cooler, but for better accuracy.

DISCLAIMER: i have not got a working system yet, but I do understand electronics and programming.

firstly, I thought the hardware was incapable of real simultaneous movement
-> it moves motor-A, then moves motor-B, then rests, then repeats every 30-sec -or-so

i suggest modifying the algorithm to implement the following:

instead of waiting 30-sec -or-so between movement of motor-A then motor-B,
why not move the motors when they are due to be moved (allowing some minimal threshold).

by this, to describe what i mean, lets consider for example:
that after each 30-sec -or-so, motor-A needs to move 60 pulses, and motor-B needs to move 10 pulses,
then the algorithm could calculate and implement:
- motor-A is moved 2 pulses every second (resulting in the same 60 pulses in 30-sec), and
- motor-B is moved 1 pulse every 3 seconds (resulting in the same 10 pulses in 30-sec).
Get it?

From an observer, due to the very small movements, the machine would not seem to move at all, but would very slowly move and keep aligned to target better than the existing algorithm, in my opinion.

4
Heliostat Projects / Re: functional diagram of Sun Harvester Shield V2
« on: October 08, 2015, 05:06:35 AM »
Hi Gabriel,

Thanks for your feedback.
Yes I will modify based on your comments made via email.

Can you please advise what needs to go in the title-block?
ie the copyright info...,
And do you want anything more than what is in the titleblock?

Ben.

5
Heliostat Projects / Re: functional diagram of Sun Harvester Shield V2
« on: October 08, 2015, 05:01:55 AM »
Attached below is Version 1 of the diagram.

- is incomplete
- needs LED shown
- needs D13,D14,D15 connected

6
Heliostat Projects / Re: Drift in reflection
« on: September 26, 2015, 03:06:06 AM »
Hi Nirav,

Do you have confidence in being able to tell your heliostat to move to a certain position, and know with confidence that the heliostat did infact move to the desired position?

The test I would perform is as follows:
If you position a laser pointer so that it points onto the center of the heliostat mirror, and the reflected beam comes straight back into the laser pointer, we call this position (0,0). Leave the laser pointer in this fixed position.
Now, tell your heliostat to move, say, 10 degrees, in either azimuth or elevation.
You should expect the reflected laser beam to have moved double this angle, namely 20 degrees.
Using trigonometry, you should be able to confirm if your mirror is positioning itself correctly.

Then, move nirror to 45 degrees, and see of laser reflects at 90 degrees.
Do this in both the positive and negative directions, and in both the azimuth and elevation axis.

Thats what I think is important to do first.
Regards,
Ben,

7
Heliostat Projects / Re: mechanics, a-frame on lazy-suzan
« on: September 26, 2015, 02:49:41 AM »
Below is my design for the base of the heliostat. This performs Azimuth movement.

Basically two pieces of wood, seperated by rollers.
- the RoundMountBoard and SquareBaseBoard are laminated smooth both sides, 12mm thick,
- the lowerPulley is made from the same benchtop, to be made perfectly circular.
- support rollers and lasySusan support the weight.
- 6x or 8x support rollers, placed furtherest distance from center of rotation,
- lasy suzan supporting weight at the center

A Lasy Susan is basically two steel rings, seperated by ball or roller bearings.
Pictures are shown below.
These are either sourced from a tabletop lazysusan, or swivel stools.

The final height of the base should only be 50mm or so.

Although I could attain 360 degree rotation, I will probably fix (in two places) a length of belt to the lower pulley, and have a stepper motor and gear assembly located on the square base board.

8
General Discussion / Re: login details for shop store purchase
« on: September 15, 2015, 02:21:41 PM »
Hi,

Yes, that made it clear and simple.
I created an account for the store.

Thanks,
Ben,

9
General Discussion / login details for shop store purchase
« on: September 13, 2015, 06:30:21 AM »
Hi Gabriel,

I want to make a purchase, at the store, and need to login.

When I use my login from the forum, it says user unknown.

Do we need to create a unique login just for the store?
Or can we use our forum login as a common login to the forum and store?

Thanks,
Ben,

10
Heliostat Projects / Re: worm-drive vs linear-actuator vs belted-pulley
« on: September 13, 2015, 06:20:48 AM »
ive not built one before, so maybe shouting my mouth-off without experience, but...

my preference is the belted-pulley system,
PROs
- it is linear, ie the ratio of movement from input to output is linear (same with worm-drive)
- it is simple
CONs:
- holding torque relies on the strength of the belt, which is not as strong as the metal teeth of worm and actuator systems

11
Heliostat Projects / Re: worm-drive vs linear-actuator vs belted-pulley
« on: September 13, 2015, 06:15:42 AM »
i think with whatever of the three types of drives (worm/linear/pulley), to get precision and minimise backlash the intersection of mechanical components needs to be as far away from the axis of rotation as possible.

I say that for angular precision and to reduce the effects of backlash:
- the worm-gear needs to be as large as possible,
- the linear actuator needs to be as far away as possible from the axis or rotation,
- the pulley ratio needs to be maximised, and possibly distance apart (?) needs to be maximised

Can someone please start a thread on linear actuators? How should they be designed>?
- does the nut on the thread move, or does the thread move within the fixed nut?

12
Heliostat Projects / Re: worm-drive vs linear-actuator vs belted-pulley
« on: September 13, 2015, 06:02:38 AM »
i have never used a worm-drive, but i do know what they are.
attached is an example for our reference.

i think that if the output of the worm-drive (the worm gear) is used directly as the rotational axis, then backlash (slop in the gears) would cause problems. especially if the worm-gear had a small diameter, like 100mm.

imagine if the worm-gear was 1000mm, using the same worm, the same slack in meshed teeth exists, but as this backlash is now farther away from the center of rotation of output worm-gear, the amount of angular movement/lash would be considerable less using a bigger output gear.

How big are the worm gears that you use, and do you use the output worm-gear to drive directly the axis of rotation?

13
Heliostat Projects / Re: mechanics, a-frame on lazy-suzan
« on: September 13, 2015, 05:42:48 AM »
Hi Gabriel,

Yes I have a level surface, and understand that the heliostat does need to know where level is, IE its no good with the azimuth axis of rotation not being anything but vertical.

thanks for your calculations regards the stepper motors. and for confirmation that a 10:1 ratio will achieve decent resolution.

i am not fixed on using the belt-pulley design with 10:1 ratio, and may increase this to 25:1 because i think the pulley/belt would then have larger holding torque, as well as greater resolution.

The design places the mirror centrally on both the axis, this is a design consideration.
This should avoid the error caused by mirror not being placed on the rotational axis as discussed in this thread.

The mirror is also supported the maximum distance away from the center, this should give less wobble in the wind.

I also want to be able to make a single design that can accommodate different length mirrors, simply needing to use different lengths of wood along the bottom.


14
Heliostat Projects / Re: functional diagram of Sun Harvester Shield V2
« on: September 13, 2015, 05:21:56 AM »
Hi Gabriel,

Thanks for that link above, it does take me to a PDF showing a layout similar to what im after.

I notice that the PDF shows separate driver boards, whereas now you supply a single driver board that controls both AL and AZ steppers. In this regard, I think an updated diagram would be good.

If you dont mind, I could post a diagram that I consider more helpful (at least to me), and could you please verify it for correctness?

Ben,.

15
Heliostat Projects / Re: mirror not located on rotational axis
« on: September 13, 2015, 05:06:22 AM »
oops, the CSV didnt save the formulas. I will redo later, unless someone can verify the ODS or XLS.
dare you... ;)

From the image, to me it seems the distance-to-target does not come into the calculation, because the reflected rays from the axis-mirror and offset-mirror are parallel,. Because they are parallel, the distance-of-target does not amplify the error.

This setup places the mirrors at both the same angle of rotation (about themself).
what moves is, the offset-mirror not only rotates about itself, but also about the axis-of-rotation (0,0 in the diagram).
or another way to put it , is that it rotates and translates

Imagine a rotation-angle of 45deg. the reflected rays would be straight up at 90 deg.
The center of the reflected ray from the axis-mirror would be at x=0.
The center of the reflected ray from the offset-mirror would be at "cos(45)xOFFSET"
= 0.707 x offsetDistance.

Does this seem correct?
Ben,

Pages: [1] 2