Servo controller handing off servo control to the user

Hello!

I’m hoping to find out if it is possible to achieve a solution for my project’s problem.

My project is an animatronic coin operated game. What I need to accomplish is the following:

When power is supplied to the Arduino, two servos, Servo X and Servo Y, go to the 45º position. The user has two hand wheels with which to drive Servo X and Y, but they are not activated before the user inserts a coin (i.e., the user cannot drive the servos yet). Once the user inserts a coin, the coin passes an IR break beam sensor that then triggers the Ardiuno to activate the hand wheels ability to drive Servo X and Y. The user has 30 seconds to turn the hand wheels and drive the servos. After 30 seconds, the Arduino disengages the hand wheels and takes back control of Servo X and Y to reset them back to 45º. Then, the game is ready for another coin.

IMPORTANT NOTE: The hand wheels must be able to continuously turn, but only be able to drive Servo X and Y 90º. So, Servo X starts at 45º and Hand Wheel X is rotated clockwise past 90º, driving Servo X until it maxes out at at -45º. When Hand Wheel X begins rotating counterclockwise, Servo X responds immediately and rotates until it maxes out at 45º.

My assumption is that this can be accomplished with some crafty programming and by connecting the hand wheels to two analog feedback servos that in turn control the position of Servo X and Y.

Here are the types of servos I assume can use to drive the servos: Analog Feedback Servo : ID 1404 : $14.95 : Adafruit Industries, Unique & fun DIY electronics and kits

Am I on the right track? Does anyone have any suggestions?

Thanks!
Nick

Sound about right. Couple of counter questions.

What do you mean by "The hand wheels must be able to continuously turn"? Do you mean freely? Or do you mean wheels that can spin infinite number of circles (counter) clock wise?

Using an "analog feedback servo" is only good for having a wheel that can only spin 180 degree and mechanically locks at the end of travel. Advantage is that you can control that servo to set it back to 45 degree at the start as well to match the X and Y servo.

Also note, the Arduino is NOT able to power servo's. It can control them fine, but you need an external 5V power source.

Rotary encoders would be a good choice for the hand wheels.

The hand wheels should be encoders. Unlimited rotation and nearly unlimited endurance.

The Arduino never gives up control of the servos. It just ignores inputs from the handwheels at certain times.

jremington: Rotary encoders would be a good choice for the hand wheels.

Uhm, yeah. That I had in mind when writing my reply but turns out I forgot to mention it. Dohhhhh! :o

Ah! Thanks for the feedback everyone.

Rotary encoders look to be the right solution.

To make sure I'm being clear: The hand wheels will be free to spin infinitely in either direction at any point in time (regardless if the machine is on or off, regardless of the positions of the Servo X and Y). This is because kids and parents will spin them for fun even when the machine isn't in play and will try to force them beyond a mechanical stop. So, I'd like the connect the hand wheels to rotary encoders as suggested such that the Arduino can be programmed to recognize or ignore their rotation when needed.

Is it possible to program the Arduino to use information from the rotary encoders in the following ways?

  • Gear down the hand wheel rotation's effect on the servos? For example, every 5 steps of rotation from the rotary encoder causes the servo to rotate 1 step?

  • The Arduino ignores the rotary encoders in all cases except during a specified 30 seconds of game play?

  • The rotary encoder spins infinitely, however the servos only rotate to the maximum positions?

  • After the rotary encoder rotates beyond the servo's maximum position, rotating the rotary encoder in the opposite direction immediately begins rotating the servo in the opposite direction?

  • When the Arduino recognizes the rotary encoder, its current rotational position doesn't force the servos to jump. Rather, the rotary encoder's position only matter such that the Arduino counts how many steps it rotates in a given direction and moves the servo accordingly?

First find an encoder with 82 pulses or more per revolution.

One “encoder click” can be translated to any desired amount of servo shaft rotation. I would start with one degree per click and go from there.

But one click per degree or 360 (or 180 even) pulses per rotation may be quite hard to find. The normal hobby/China ones are 20 indents/20 pulses type.

Why should the resolution of the hand wheels matter?

Good question!

The hand wheels drive an arm inside the machine and users always spin the hand wheels as fast as they can, which throws the arm so fast that the weight of it damages the hinge. Also, another advantage is that more resolution means they can aim the arm better.

I think it would help if you gave us some more details on the mechanical setup, which to me is totally unclear.

What are the hand wheels and arm(s) doing now?

What will the servos be doing?

Absolutely.

I've designed a fabricated a working mechanical Zoltar Speaks machine. However, the mechanics are too expensive to fabricate and too costly and time consuming to repair if damaged. So, I'd like to redesign the system to be electronic and use servos to drive the coin ramp.

The game begins idle. The hand wheels start disengaged and cannot control the ramp. The ramp is in home position such that it is ready to receive a coin in a straight line from the coin acceptor. Once the coin roll onto the ramp, it is held in place by a servo arm. The coin passes an IR break beam sensor that triggers a motor that engages the hand wheels, allowing them to now move the ramp—it also moves the ramp into view. Now, the user has 30 seconds to move the ramp by rotating two hand wheels. When happy with the position, the user presses the red button to release the coin into Zoltar's mouth. At the end of game play, the motor then disengages the hand wheels once more and moves the ramp back to home position.

Hopefully, I can program an Arduino to recognize two rotary encoders to achieve a similar experience.

Here's a demo video of the machine I made for my client.

https://www.youtube.com/watch?v=Q1mTX6bRW30

Wow, what a cool machine!

That would be entirely doable using simple encoders for the hand wheels. The trick will be to get a good ratio of hand wheel rotation to coin arm movement, and that can all be done by the Arduino by scaling. However, it will take some experimentation.

I would start with the standard 24 clicks/revolution encoders I linked in reply #2 (or maybe sturdier ones). Learn to read those out and translate clicks to servo motions. Plenty of Arduino encoder and servo examples on this forum and elsewhere on line.

NickMathis: The hand wheels drive an arm inside the machine and users always spin the hand wheels as fast as they can, which throws the arm so fast that the weight of it damages the hinge. Also, another advantage is that more resolution means they can aim the arm better.

Having fewer pulses per rotation for the hand wheel doesn't need to affect the resolution. You can just trade speed for resolution. If you make every pulse 3 degree (aka, the resolution) the user needs to spin the hand wheels 3 full turns for 180 degree of servo motion. So you kind of create an electronic transmission :P If that's fast enough is up to you ;)

Also, I think I would look for dent-less rotary encoders. I think that would make for a better user experience. And you can also try to make the encoders yourself! The principle isn't that hard and pretty easy to do with two break beam detectors and an encoder disk.