> The real (interesting) problem for povray is the computation of the
> involute, as a native shape... then maybe some native gear shape, to
> handle more natively than a complex union/intersection, per tooth ?
> (nah, I would reuse my interunion object for that, probably...)
> (or may be a "duplicate teeth" object, where all intersections get
> rotated to a single teeth)
>
> mmmhhh, interesting...

I've calculated the involute curve, so I would imagine just taking the
coordinates for a full tooth, and rotating those with a transform to make all
the teeth, and then make a prism.


> helical gear... yet another beast... yummy (and more silent than the
> basic gears at a small cost of maximal power)

> The real hungry would go for hypoid gears, they are really painful.

IIRC, someone designed a new type of gear that's an even wilder curve.
Trying to look that up, I found:

http://www.popularmechanics.com/science/animals/a9449/the-first-gear-discovered-in-nature-15916433/

:O


> If you have physical access to the gear, the fastest is to use a tailor
> rule (the soft thing the tailor uses to measure) around the full circle,
> and measure a small number of teeth. You might be off by a few unit, but
> it's fast. (but does not work for gear with teeth on the inside,
> including epicyclic gears)

I have hundreds of them.
I looked up reverse engineering of gear geometry, and a simple way is get it wet
with ink and roll it on a paper.   I suppose if I removed one of the teeth or
part of one, that would be a marker for tooth #1....

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:

> IIRC, someone designed a new type of gear that's an even wilder curve.

Aha.  The "Eccentrically Cycloidal Drive".
I believe it was Stephen who brought this to my attention, based on the site:

http://www.otvinta.com/tutorial07.html

Post a reply to this message

On 6/7/2017 12:51 PM, Bald Eagle wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
>
>> IIRC, someone designed a new type of gear that's an even wilder curve.
>
> Aha.  The "Eccentrically Cycloidal Drive".
> I believe it was Stephen who brought this to my attention, based on the site:
>
> http://www.otvinta.com/tutorial07.html
>
>
It hurts my eyes watching it. :)
I wonder how I can use it.
Thanks

-- 

Regards
     Stephen

Post a reply to this message

So, I have a pretty good first approximation.

I'll post some results in the binary images section.

Post a reply to this message

There is also "the abacus":

http://spectrum.ieee.org/automaton/robotics/robotics-hardware/sri-demonstrates-abacus-rotary-transmission

a modern potential improvement over the harmonic wave drive:

https://en.wikipedia.org/wiki/Harmonic_drive

Post a reply to this message

> Well, the basic idea was to see if, using a simple photograph or scan of an
> existing gear, if the number of teeth could be determined automatically and
> accurately.  Just like in the link.

I don't think their link is a very good way to do it, if there are 
artefacts on the photo you could end up with missing teeth or additional 
teeth in the count. It would only be accurate/reliable on super-clean 
photos.

I wonder if you could do some sort of polar->rectangular conversion of 
the image, once the centre is found (so x in the new image represents 
0-360 degrees polar angle, y represents radius at that angle). You can 
then do a fourier transform along x, and the frequency peak in the 
result will correspond to the number of teeth, and be far more immune to 
any artefacts/noise in the image.

This is exactly the technique I use to measure the pitch of regularly 
spaced identical objects in an image, it's extremely robust.

Post a reply to this message

scott <sco### [at] scottcom> wrote:

> You can
> then do a fourier transform along x, and the frequency peak in the
> result will correspond to the number of teeth, and be far more immune to
> any artefacts/noise in the image.

I worked a little bit more on this, and plotted out the radius vs arc-length to
get a triangle wave graph (3600 samples).   Naturally, I thought that the
Fourier transform would be a great way to pluck-out the frequency of the teeth,
I just haven't gotten to that point yet.
I'm glad to see that you actually do this, and know empirically that it's a
reliable and robust method.  That validates spending the time to go that route.
 Thanks!  :)

Based on my graph, there does seem to be some "cruft" at some point on the gear
photo that distorts the data, but it's apparently still clean enough to give me
the correct number of teeth with the way I'm currently doing it, provided I
apply the correct frequency of sampling. (see binary thread)

I was also thinking that there ought to be way to determine a radial sampling
frequency based on the resolution of the image - since any higher than that
wouldn't gain me anything.

Until I work any of that out, I might just think about pre-scanning the
perimeter, estimating the tooth number and average size of a tooth, and then
filtering out any noise that disrupts my counting algorithm by ignoring any
change that's less than a certain fraction of a tooth height.

Post a reply to this message

>> You can
>> then do a fourier transform along x, and the frequency peak in the
>> result will correspond to the number of teeth, and be far more immune to
>> any artefacts/noise in the image.
> 
> I worked a little bit more on this, and plotted out the radius vs arc-length to
> get a triangle wave graph (3600 samples).   Naturally, I thought that the
> Fourier transform would be a great way to pluck-out the frequency of the teeth,
> I just haven't gotten to that point yet.
> I'm glad to see that you actually do this, and know empirically that it's a
> reliable and robust method.  That validates spending the time to go that route.
>   Thanks!  :)
> 
> Based on my graph, there does seem to be some "cruft" at some point on the gear
> photo that distorts the data, but it's apparently still clean enough to give me
> the correct number of teeth with the way I'm currently doing it, provided I
> apply the correct frequency of sampling. (see binary thread)
> 
> I was also thinking that there ought to be way to determine a radial sampling
> frequency based on the resolution of the image - since any higher than that
> wouldn't gain me anything.
> 
> Until I work any of that out, I might just think about pre-scanning the
> perimeter, estimating the tooth number and average size of a tooth, and then
> filtering out any noise that disrupts my counting algorithm by ignoring any
> change that's less than a certain fraction of a tooth height.

Another thing I did, which allows you to get a much more accurate value 
of wavelength/frequency than Fourier allows, is to use some form of 
auto-correlation. It might work out quite well here... I do this step 
after Fourier has given me a rough idea of the spacing, but you might be 
able to just skip the Fourier step and do this...

You find the centre point of the gear. Then create a 2nd copy of the 
image rotated by some angle A about this centre point. You then do a 
difference of all the pixels in the original and rotated version and sum 
up the errors (maybe ignore the centre part of the gear).

As you increase angle A from zero you will get a different total error, 
the angle that gives the minimum error will be your tooth angle. You can 
use whatever algorithm you want to search for the A with the minimum error.

Post a reply to this message

scott <sco### [at] scottcom> wrote:

> You find the centre point of the gear.
That's something I still need to improve - I'm working with only the roughest
estimate at the moment.
I think the usual method of using where 2 angle bisectors intersect to find the
center of a circle ought to straightforward enough to implement.

> Then create a 2nd copy of the
> image rotated by some angle A about this centre point. You then do a
> difference of all the pixels in the original and rotated version

A difference of all the pixels...  a difference of ---  the rgb/gray values?
The vector length from the center of the circle?
Part of the challenge with this is differentiating "picture" and "object" and
separating and extracting one from the other for analysis.

> and sum
> up the errors (maybe ignore the centre part of the gear).

Sum up the differences in the above step to get a measure of the absolute change
as a function of the angle.


> As you increase angle A from zero you will get a different total error,
> the angle that gives the minimum error will be your tooth angle. You can
> use whatever algorithm you want to search for the A with the minimum error.

Or, I suppose the maximum would yield essentially the same result, if I
correctly understand how this all works.


With regard to the Fourier transform and its inverse - what are you using to
implement that?  Is it part of a proprietary software package?  A C library?  I
think I've been able to get the 1D version working fairly well, but I haven't
been able to spend enough uninterrupted time with the 2D variation to match up
the output to what I see in online examples.

Thanks as always for your suggestions and guidance   :)

Post a reply to this message

> A difference of all the pixels...  a difference of ---  the rgb/gray values?

Yes, if you have a colour image then I'd probably do the pythagorean 
distance between the two RGB values. It probably doesn't matter too much.

>> As you increase angle A from zero you will get a different total error,
>> the angle that gives the minimum error will be your tooth angle. You can
>> use whatever algorithm you want to search for the A with the minimum error.
> 
> Or, I suppose the maximum would yield essentially the same result, if I
> correctly understand how this all works.

When you've found the correct angular spacing, the rotated image should 
have all the teeth lining up with the original image, so the difference 
between the two images (in terms of summing up the differences between 
every pixel) should be very small. As you rotate the 2nd image so the 
teeth are not quite lined up, you'll get bigger errors where there is 
"gear" in one image and "background" in the other image.

The maximum total error might give you exactly half the angular spacing 
of the teeth, as this would probably be where the "tooth" in the rotated 
image exactly lined up with the "gap" in the original.

> With regard to the Fourier transform and its inverse - what are you using to
> implement that?  Is it part of a proprietary software package?  A C library?  I
> think I've been able to get the 1D version working fairly well, but I haven't
> been able to spend enough uninterrupted time with the 2D variation to match up
> the output to what I see in online examples.

All of my stuff is in C#. As for the FFT I just found a library from 
Google that seemed to work well. This is the one:

https://gerrybeauregard.wordpress.com/2011/04/01/an-fft-in-c/

Post a reply to this message