Im trying to get my head around a hypotetical solution on how to gather precise rotational data (speed/distance) for a vehicle application.
The disk im concidering using is a standard bicycle disk brake rotor, with a backswept pattern of 3 cooling-holes that repeats about 20 times around the brake surface of the disk.
The basic idea is to mount a IR diode on one side of the disk, then use a sensor on the other side, assembled in a box behind the brake caliper, to have a signal high when a cooling hole lines up.
Since the cooling holes are drilled in a "spiral", i can easily use 3 sensors, one for each "track" of holes to sort out the forward/reverse direction.
So if the sensor signal order is 1-2-3, its rotating forwards, but a 3-2-1 means a reverse direction.
I know i could use hall sensors as is normal on vehicle spedometers, but i want a greater resolution without the rotational weight.
I figure this should be doable, but is it a good idea?
If not, how come?
Is there a easier/better way to solve the initial "problem" and still meeting the resolution design requirements?
I don't see any serious issues. As you have three rows of holes indeed it's possible to determine direction from the order. With just two rows that'd be rather tricky.
The easier way to accomplish the same would of course be to get a quadrature encoder. Those things are designed to do exactly what you try to do.
That should work well. Any pattern of holes works, and you need just two sensors, one offset from the other on a single track, to determine both direction of rotation and speed. One of many tutorials.
Optical systems only work reliably in a clean environment which is why you rarely see them on vehicles.
If weight is an issue then embed some magnets in a sheet of carbon fibre and use a hall sensor.
Actually the holes are principally to increase grip in the wet, as bike brakes are open to the elements.
Using them as a handy quadrature encoder for free is a neat idea, actual design of the sensor to
survive the elements and road-spray is probably tricky.
Two sensors are enough for direction, but I can see having three might be useful purely for robustness
if the pickup unit gets dirty - you would detect when one of the sensors drops out, indicate its time for
cleaning, but still have two sensors for speed/direction purposes?
Thanks everybody for your inputs, its very educational to vent an idea and have others finding the flaws that i didn't realize myself.
I didn't consider brake debris so i´ll move the planned sensor "box" to the front of the brake caliper.
After considering quad encoder IC´s, i'm starting to think that the signal input is so time-dependent that im practically forced to use commercially available encoder wheels and sensors...
I also have yet to find a 3-channel IC encoder..
Now, i ditched the idea of hall sensors since it would require a lot of rotating magnets, but are you guys suggesting that it would detect the disk rotor steel without any rotating magnets?
Should/could i perhaps attach a magnet on the brake caliper and detect whats leaking thru the holes?
I would prefer not having to modify the brake rotor, its my main mode of stopping and i'm not risking road safety on some project goals..
If the holes aren't good enough, i´ll settle for counting the spokes of the disk rotor, about 8 or 12 in total.
I figure that with properly placed sensors, i could double or triple the resolution and then its close enough for me to call it quits.
...Oh, and to answer a comment; if i wanted "easy", i wouldn't learn programming, that's for sure..
I use my current project as a learning platform, something that keeps the motivation up when things are hard to crack, so i embrace the challenge..
dougp:
Just thinkin' out loud here. If all you want is forward speed why are three encoder channels needed?
A single sensor, of whatever type, could provide a signal the Arduino could process into a speed reading.
Yes, thats how im doing it now.
However, i dont have any idea if the magnet is bouncing past the sensor (vehicle stopped, but rocking forward/backwards) or if the wheel is actually rotating full revolutions and if so, in what direction.
If it were easy it would simply not be rewarding, so why not build stuff overly complicated? im learning tons in the process, and having (mostly) fun along the way..
And if you really need a actual reason, i dont want to mess up my trip data while reversing.
For the cadence sensors (bike pedals rpm), it would certainly be neat to only power the ebike-motor when the pedals rotate forward.
As i understand things, 2 sensors are needed to detect direction, but only if there is a encoder wheel properly designed for the task.
A 3rd sensor will make it easier to detect direction, since the disk rotor holes arent drilled with rotational encoding in mind.
It would also add the possibility to error check and redundancy, in case a sensor would fail.
You should of course ADD distance you travel while reversing to your total trip data. not deduct it. It is distance travelled.
So for that reason you don't need to know the direction.
For the "rocking back and forth" part - here you can't tell whether you've moved a fraction of a rotation or almost two complete rotations. It can be anywhere between those extremes with a single measuring point. You should also ask yourself, does this really happen so much as to significantly alter the data?
