A little background... I started a new job a few months back where we set up conveyor systems and robots, the engineers then take over to program and troubleshoot, next the customers come in and watch it run, and then we get to take it all apart and put it on a truck. It's not exactly the kind of work I wanted to find, but I don't have the experience to do what I want or the education to at least get a foot hold. There is potential though if I can prove useful (which I think I'm doing rather well so far!!) I thought it would be neat to create a miniature system to kind of demonstrate a little skill, and just for a fun challenge. I want to be able to model the robot so the motors are in the correct locations.

I have a pretty good idea how to go about two axis on the tooling end so far and keep those motors in their normal locations thanks to a YouTube video. I had something else in mind at first, but found a video of their joint. I have a few ideas for the base rotation too (that is about the easiest part of the project).

The real question is how do the main arm up and down, and the first pivot motors and gearing work? It seems they would have some planetary system by the orientation of the motors, but I am unsure how they hold their position then without any power? I thought about a brake system, but that seems like it could have reliability issues in both my model and real word applications. I did find something that seems to show two planetary systems back to back, but it still doesn't make total sense.

A worm gear set would be the easiest to work out, print, and have built in braking. The problem is I would either have to move the motors or make some sort of gear train to transfer the motion a few different directions between the motor and the worm.

I have some flat aluminum that I will probably use to build a little crane for R&D so I can concentrate on the internals. The more I think about it the easier it becomes... a couple bevel gears and shafts to turn the motor output to the right plane to run a worm setup.

Any ideas?

 

Just basic 3 axis point to point motion is quite common, it gets quite a bit more complicated when venturing into robotics as the axis/arms typically use articulated joints.
So the mechanics are quite complicated also.
They generally are held in position under power by using some kind of encoder feedback.
I would not tackle this without anything less than the likes of a multi-axis CNC card such as Galil Motion , these sit in a PC slot.

 

I checked out the Galil Motion and while they are interesting I'm thinking more along the lines of simple stepper motors run by a couple PIC16F1504's that I have laying around. The whole thing is going to be 3D printed in the end and will probably just stack dice and other small objects.

 

I was referring to this for the tooling end. I probably won't be able to totally replicate it, but I'll get somewhere close.

 

I was referring to this for the tooling end. I probably won't be able to totally replicate it, but I'll get somewhere close.

That is an articulated joint, not an easy task to implement.

 

Many model robot arms use a planetary gearbox and a stepper motor which will automatically brake when not in motion. The downside is that if you overload the motor by trying to move too fast for the load you loose position tracking. The alternate approach is a gearbox with a DC brushed or brushless motor and an output shaft encoder which always knows where it is, but can be much more expensive.

You should learn about reverse kinematics, which works out the optimum motion profile for each joint, given the joint capabilities, the end-effector's (ie the gripper's) desired location/orientation and its current position/orientation.

 

The alternate approach is a gearbox with a DC brushed or brushless motor and an output shaft encoder which always knows where it is, but can be much more expensive.

You should learn about reverse kinematics

I am considering brushed motors with like a mouse encoder printed into the end of the worm gear. I could print an assembly to house a LED and photoresistor to sense the windows. Add in a way to detect a home position for each movement and I should be able to detect / calculate position. I was thinking the steppers would be easier to control the speeds more accurately. My tinkerings with brushed motors and PWM have yielded inconsistent speeds depending on the motor load. Just more programming in the long run I guess...

I will look into kinematics. Sounds interesting

 

I am considering brushed motors with like a mouse encoder printed into the end of the worm gear.

You will need a much higher resolution that that IMO, ~ 2000p/rev
Also with DC motors, it has to be PID control for any accuracy.

 

You will need a much higher resolution that that IMO, ~ 2000p/rev
Also with DC motors, it has to be PID control for any accuracy.

I can always add gearing between the worm and encoder wheel to speed it up. Since I will be designing and producing all the parts myself it won't be much to break it in to tiny steps or make gear ratios to step down / step up the various parts.

My controller vision so far:
An ESP32 as the system CPU / controller connected to a single PIC16F1504 for each motor / encoder combination. There are five planned at the moment.

For each movement:
1) The ESP would send a message to each PIC defining speed and length parameters for the next move.
2) The ESP would then drive a pin high that is connected to each PIC as a start signal.
3) Each PIC would complete it's movement then drive a pin on the ESP32 to signal it's move is complete.
4) Once all the PICs have signaled they are done the ESP would then drive the start signal pin low and return to step 1.

Obviously I will have to set a timer so that if a PIC doesn't signal that it completed it's respective move then it will fault and wait for user input.

If I break each movement into a series of short moves with enough encoder resolution then it would appear to be a fluid move and end up right where it is supposed to at a speed that doesn't appear too slow.

I did some measuring of parts and found I may have overly complicated my original idea. It won't be hard to hide the motors in the lower part and make it look right.

I think it's just a matter of math at this point.

 

I can always add gearing between the worm and encoder wheel to speed it up.

Bad idea, amplifies backlash in system. Encoders should be as near to joint as possible and highest resolution possible. Consider distance from elbow joint to gripper, say 200mm. A 1deg movement at joint = 3.5mm at gripper... to position gripper to, say, 0.25mm you need ~0.05deg resolution, thats 7200ppr

 

Bad idea, amplifies backlash in system. Encoders should be as near to joint as possible and highest resolution possible. Consider distance from elbow joint to gripper, say 200mm. A 1deg movement at joint = 3.5mm at gripper... to position gripper to, say, 0.25mm you need ~0.05deg resolution, thats 7200ppr

I never considered that. That also really throws a huge wrench in the idea!! I could to some extent design around backlash. It's gong to be hard to print an encoder wheel with enough granularity to work at the joint without making it like 12 inch diameter or so. Way bigger than I planned.

There's always the possibility of getting it close, then creating some sort of tooling sensors for final positioning.

 

Robot motors are three phase steppers with an integral brake in them. Power to release so when you shut down the robot the planetary is locked in place. And the resolution on those encoders is 2.4 billion ppr and are absolute encoders with battery backup to retain position. Backlash can be controlled with a harmonic gear, but to impliment that on a small scale is difficult. I know for sure J1 - j3 are planetaries. I havent pulled the shoulder and wrist apart on a Fanuc yet. I know motoman uses timing belts and harmonic gears for their shoulders and wrists.

 

J1 - j3 are planetaries.

That is what I suspected, but the motor brake didn't sound right in my head. I guess with the right gear ratios it wouldn't take much to clamp it in place.

The 2.4 billion ppr is going to be a tough one. I didn't consider at first the arc differences between the arm retracted and extended... it's going to take a little more than I originally thought.

 

It's gong to be hard to print an encoder wheel with enough granularity to work at the joint without making it like 12 inch diameter or so. Way bigger than I planned.

You need an optical grating. By way of example, consider the cheap digital calipers, good for 0.01mm, that's 100ppmm. At that same resolution the encoder disk would be approx 72mm circumference or <25mm dia. A good quality inkjet can print @ 1200dpi. Assuming you need at least 2 dots to make a black line that's 600dpi or 0.04mm resolution. So, theoretically, you could print, on clear film, a suitable encoder disc about 100mm dia. Or you print it bigger and find a local camera club who can photo-reduce it and print on, say, a 50mm dia glass disc.

 

Sorry, yes, these are optical encoders on the robot servos. Yeah the gearing is really high so the 3000rpm of the motor is down to a reasonably slow arm movement so a little braking on the motor itself holds a LOT of weight on the arm.

 

You might find this YouTube channel useful. Levi Jansen concentrates on robotics and especially actuators which he models and 3D prints. He gives good explanations of the different types, and rigorous testing.

Here’s an example video:

 

Commercial robots generally use battery retained encoder positioning, this is the reason you are not required to 'Zero' the unit at power up, as is typically done with CNC machinery etc.

 

Commercial robots generally use battery retained encoder positioning, this is the reason you are not required to 'Zero' the unit at power up, as is typically done with CNC machinery etc.

Or they use 'absolute encoders' so know their exact position at all times.

 

Traditionally absolute encoders have always used batteries for many decades, they are used in place of incremental versions that require 'zeroing' at each power up.
The last few years, some absolute encoders have appeared that do not require a battery back up.

 

Ya'akov I actually stumbled across that particular video this morning before work (I woke up extra early for some reason). I plan on checking more into things later on. Maybe I can get some ideas.