Robot Motor Absolute Position Encoding Issue

[max_imagination]

Hi Forum,

Your help would be greatly appreciated here on selecting a more reliable method of detecting the approximate or exact position of a motor shaft for a hexapedal (6-legged) robot based on the current hardware and setup I have at my disposal. My robot is supposed to walk similar to this one I'm working on mimicking: https://www.youtube.com/watch?v=ISznqY3kESI&t=10s

The end goal is to make the robot move in a tripodal gait (3-leg walking pattern) to maintain both balance and movement. A slow walking phase and fast retraction phase must be implemented to allow for the robot to walk with 3 legs always making ground contact and the other 3 retracting quickly to make the next step. 3 motorized legs within each set must stay synchronized with one another to maintain the correct walking gait without the robot falling over.

I am currently left with using only one slotted IR sensor per micro metal geared DC motor to detect the position of a motor's shaft via a 3D printed positioning cup (disk) with 24 slots around it, coupling around the sensor and motor head.

This is one of the 6 C-shaped legs with its slotted positioning cup firmly mounted to its motor's shaft and IR sensor peeking in to detect the position:

Adding additional sensors to this arrangement is not an option for me now as my ESP32 is out of available pins and this is the way I have already designed my robot. However, I am willing to re-3D print the shaft positioning cups with whichever number of slots that are needed to make this position detection arrangement work.

I was referred to the solution of using these 24-notch positioning cups as the sensor could count the exact number of notches that pass through a given point to determine absolute position of a leg (a.k.a. motor shaft), but this doesn't account for if the motor is bumped backwards which offsets the amount of notches counted.

If I am on track with the right position detection method, maybe it's the coding that's troubling me as I am a newbie Arduino programmer here.

However, if my 24-notch positioning cups are not the most optimal approach. Would you please suggest the number, spacing, and layout of the ideal positioning cup each motor should have with its current hardware to ensure its position is well-detected for synchronization of one motor to another? Or is there a smarter alternative solution with my current setup?

I need some reassurance on whether I'm on the right track with my motor positioning method or if I should use another.

Thanks in advance,

Max

[DaveX]

Any number of slots with a one-sensor photo interrupter can only get you a relative position based off of a count of pulses, and no direction information. You'd have to get direction and homing information elsewhere.

24 slots will get you 48 events (in 360°?), so you get maybe 7.5° resolution (but with some asymmetry between the rising and falling edge events as the beam interacts with the slots)

Maybe considering trading the system for a I2C absolute magnetic sensor might be worthwhile? You might be able to trade 6 optointerrupter pins for 2 I2C pins plus 3 for a I2C multiplexer for a net gain of 1 pin and higher resolution absolute positioning.

[max_imagination]

Thanks for your response, Dave.

I get what you mean by the difficulty in detecting the rotation direction during counting the notches to find the exact position of each motor shaft.

What if something as simple as one unique little switch per motor was added as an extra sensor that has a tiny flap which moves facing the direction of rotation, ticking across each moving notch? So, when a motor changes its rotation direction, the motor's positioning cup with it's notches flicks this little switch the other way, toggling an IO pin to a different state? Could something like this work along with more code changes to respond to the new signals?

With these implemented, I can probably find an IO extender or tap into the remaining ESP32 chip pads that haven't been broken out as pins yet.

Best,

Max

[DaveX]

That might work. But if you are adding an IO switch per motor, consider that most encoders use two optical sensors--one positioned out of phase with the other, so they get a quadrature signal with direction and relative position.

Mouser sensors/optical-sensors number of channels=2 search