My daughter & I just got finished building a little robot car partly with the help of this forum, thanks! It was a lot of fun and we learned a lot! We're ready to start planning our next build full of upgrades. One upgrade is use of a variation of these very handy gearmotors we like to use. They have an integrated planetary like the others but also a bowtie encoding feature on the rear of the motor. Clearly it's a DIY encoding opportunity rather than a complete hall sensor or other common solution. Anyway, so while I do have a tiny hall encoder from anther similar motor it would be a hassle to make it work since it has a different shaft diameter and is overall a bit larger.
So the small size of this example is going to make it a little tricky to get some sensor in there. I was thinking the simplest would probably be use of a photoresistor and either and LED on one side and photo resistor opposite, or maybe just use it reflectively and ambient light. If I could find one small enough I could use an IR pair in similar fashion. A photointerruptor I guess would be optimal but I don't think I can get them that small. I've even seen a microphone and shred of paper used as a tachometer before, so I'm just trying to plan this out before we get started. Not sure how forgiving the microprocessor will be in interpreting a signal and ending up with useful feedback. Thanks in advance for any suggestions!
It's pretty straightforward. You can take the signal as an interrupt and get the time difference between successive transitions to get motor speed, or just count them to know how far it's travelled.
My question is less about the code (for now) and more about the methodology. I'd guess that theres a reason that hall effect sensors are most commonly used despite them not being the cheapest option. Maybe I'm wrong but figured I'd ask before I start going down a path. The microphone example I'd imagine to be that with the most "noise" in terms of clear reference signal peaks.
What came with the bowtie? I'm sure they didn't add an extra part for no purpose.
Here's a photointerrupter implementation: PIC project DC motor like crystal clockwork!
Nothing came with the bowtie. I'd guess they were surplus from some product that had integrated contacts and some sensor, probably a custom photointerrupter. The contacts are also a bit unusual in that they are little side mounted leaf springs so further evidence of some custom implementation. That said, they are nice and cheap, and output a nice balance of torque and efficiency with that teeny planetary on the end. The output is a .5mod gear also so we could very easily mount to some other ratio if desired. The 1st gen robot we did works pretty well but any small mechanical resistance can throw off the balance between motors & result in curved routes for the robot.
Maybe it was a mechanical connection to a ventilation fan or something. Could you add a bigger encoder disk? You might be able to glue a disk onto the bowtie and experiment with cutting or coloring it with an encoder pattern. The setup in the link above hot-glued a salvaged detector and disk onto the motor:
Do you think the bowtie wouldn't be appropriate to track? I didn't think resolution would be an issue in an application like this especially since it's geared way down anyway. If anything I'd expect the opposite problem where slots are too fine to register. I do have a laser printer and clear transparency film if we need something custom. Doing that wouldn't be unreasonable but then we're back to the sensor question. I did look into photo interruptors but anything Ive found off the shelf is too big to fit in the space I have.
If it's too small to get anything in there, then yeah, you can't use ti for tracking. If you thik it could be used, you might be able to cut awkward bits off a photointerrupter -- they're mostly plastic wrapped around the devices for convenient mounting. You might even be able to break it into two pieces.
If the wheels are slipping to give you curved paths, then feedback from the motor won't solve it. If you've got good traction but the motor speed is load/voltage dependent then motor feedback will help. If you've got another gear in the drive chain, you could do the encoding on that.
Well one thought I had there was: if I was just using a photo sensor with a white background on the motor side then I'd have infinite space behind the motor for whatever (but in reality just a light sensor). I guess it comes back to my original question of how clear the signal need to be in order to be useful. Similarly, if it was just bumping a microphone, or even just passing by it closely enough to hear a distinction, I could certainly fit that in there. In short, I can certainly fit things in there (plenty of room for SMD components, for example) but its just a question of what I can reliably get a useful signal from.
re: photointerruptor: Yes, as I understand them it's just an ir LED & ir detector pair, so I could make my own pretty easily I think. I was also considering trying a right angle reflector for space considerations. I was a bit surprised that ir led/detectors in SMD form factor are evidently not common.
re: wheels- it's not that they're slipping, but rather that the whole scheme depends on them being manufactured and assembled with identical specifications (and they ARE very close) but then also the 3d printed wheels (which physically touch the motor body for support) need to also have exactly the same friction.. and then if some random dog hair gets in there all bets are off. They're not slipping on the ground, particularly, and we can adjust the speed so that they turn quite slowly.
I was thinking that if you have to correct for these inescapable differences, the encoder might not help you as much as something like the magnetic field sensor in, for example, a 6DOF IMU. The encoder gives you feedback on the input to the scheme before the dog hairs, etc.. You could check and compute the heading or heading change you want to be doing and correct the relative speeds on the fly.
Well you're right- an IMU would probably be the best solution, but that's uncharted territory for now. We'll hopefully not get too discouraged in coding and get to that soon, but if I understand encoders correctly that would essentially make these servo motors and if we have full control over absolute position in spite of whatever load they encounter, much like you would a stepper (ignoring overloaded steps missed). Anyway, I don't really want my solution here to always be an IMU, part of my motivation is to learn more about encoding.
The reason Hall-Effect sensors became popular is that LEDs/photodetectors get covered with dirt in some environments and Hall sensors are more rugged. Also for some applications (e.g., counting gear teeth), they're a lower cost solution than, e.g., adding an optical encoder.
1 Like
Almost certainly not a photo-resistor - a photo-transistor or diode is the correct choice. Photo resistors can be very very slow to respond (they vary a lot depending on which technology is used though). Most photo-resistors are huge too, which won't help here.
I think those are the motors with harmonic gear train, not planetary?
1 Like
Thanks for the tip! Now I wonder what the smallest (conveniently available) form factor is for a phototransistor.
edit: These look like a good candidate!
It was surprising to me when I looked into photoresistors that 99.9% of the ones I found were 5mm. I swear my introductory arduino kit included some much smaller and differently shaped ones. I should have hung onto those more tightly!
Speaking of rare, I'd love if those motors were harmonic gear train, that'd be a real treasure, but alas they are just micro planetary. Still quite handy though. My only gripe is when I directly mount wheels to them (& use the motor shell as an axle) there's not an easy way to secure them. My best solution is pulling apart the gearbox and then drilling and tapping the sun gear with an 0-80 screw. Not something you'd want to try without a lathe and tweezers. That said the end result is pretty compact, robust, and appropriate for a tiny 1 battery robot.
So I have and am using these photodiodes now (BPW34- linked above). I'm using 3mm red led captured within a little cover I made such that only a thin red beam of light is directed to the detector area of the photodiode, and is blocked effectively as the bow tie spins.
That's the arrangement for now. Now I'm getting into the coding and learning about interrupts. For the moment I'm using an arduino Nano- as I understand it only digital pins 2 & 3 allow for interrupts which is (maybe?) the only convenient way to use an encoder. I have some code that will read the value of this phototransistor from an analog pin (A0), and I can see in serial monitor that this value changes as the motor spins. I can plot this as well and recognize a consistent pattern that will vary with RPM. It's not a clean signal but at least for me its a good start.
So I guess my next question is can I get from here to a point where I can control the position of this motor with the setup I have or do I need to change from nano? I have some other controllers such as ESP32, ESP32-CAM, ESP8266, Seeeduino XIAO, and arduino Uno readily available but I was hoping to keep this quite small.
Most of the tutorial examples I have seen so far use a ready made hall effect encoder and not a DIY optical encoder. The end goal with this will again be a new little robot guy but the short term goal is to learn how to get some of these hardware choices to cooperate and get a handle on how interrupts/encoders work with DC motors.
Interrupts are the traditional solution for this. You're probably going to need to condition the signal with some external electronics to make sure you're getting a digital one and zero. Try just digitalReading the A0 pin to start with and see what you get.
2 Likes
oh! I can just digitalRead an analog pin? great! ...the more you know..
What is the range of values? If you can tune it to reliably covers the "Input low voltage" and "Input high voltage" of your Nano, maybe <100 and >716 >614 on your ADC (0.1VCC to 0.6VCC per the datasheet) when it's blocked or not, then you could watch for edges with attachInterrupt() - Arduino Reference
Well, I have a lot of tuning yet to do. For now it's just being positioned by helping hands on the bench the range is only around 30 and all less than 1v the BPW34 doesn't produce much power. Is there anything preventing interrupts on an analog pin (on other microcontrollers?) or are interupts only viable for digital?
Take a look at the schematic and surrounding text on PIC project DC motor like crystal clockwork! you should be able to bias it like a pullup on a button.
Interrupts need a clearly defined transition, an analog threshold is prone to noise/bouncing problems.
1 Like