Close
0%
0%

Arcus-3D-P1 - Pick and Place for 3D printers

Open source, mostly 3D printable, lightweight pick and place head for a standard groove mount

Similar projects worth following
Part rotation and bottom looking vision using two 9g digital hobby servos.

Bottom vision is currently implemented by using the top vision and a flying set of mirrors.

At 59 grams including the camera and mirrors, it weighs about the same as an E3D v6 hotend.

Standard groove mount, so you can just replace your hotend.

Overview

A pair of 9g digital hobby servos are utilized for part rotation and swinging a set of mirrors in front of the top vision to allow it to also provide the bottom vision.

360 degrees of part rotation is implemented, has an accuracy of about 1.6 degrees, and a best case rotation speed of 0.13sec/90 degrees.

The mirrors should be able to extend or retract in 0.19sec.

Full rotation and clearance for parts up to 21.5x21.5x12mm is implemented. 

The current design including the camera weighs 59 grams which is lighter than an assembled E3D v6, and the goal is to allow this to fit in its place.

This should allow adapting any existing 3D printer with decent accuracy, Z axis speed, and a stable build platform for small scale pick and place.

Other parallel projects are addressing some of the remaining requirements such as an inexpensive vacuum source, 3D printable bump tape feeder, 3D printable drag feeder and 3-way valve.

Caveats

It should be noted that the cheap, knock-off version servos will not work here for part rotation.  The measured accuracy of the knock-offs was almost 5x worse and they had significant backlash as well. This almost killed the project before it started as that was my original servo for testing.  

However, I was pleasantly surprised when I tried some still relatively inexpensive, but genuine manufacturer servos.  In this case, they were Tower Pro.  They exhibited basically zero backlash (as the potentiometer is tightly coupled to the output shaft), and accuracy within 1 degree for most of the scale.  As I'm using a 2:1 drive, that puts the overall accuracy at about 2 degrees.

There would need to be compensation for linearity if I used these for absolute positioning and temperature/timing issues could cause drift, but the nature of this task is relative if approached correctly.  You pick up a part, rotate, check the positioning, and then rotate it relative to the previous position.  This pattern will inherently correct for drift related errors.  They should perform that task just about as well as the common Nema 8 stepper solution.

Another caveat is that if the requested motion is less than 2 degrees, the servo sometimes doesn't move at all.  So I'm anticipating needing to code a minimum move size which backs off and then rotates to the target to compensate.

Lastly, a flying bottom looking camera doing vision during moves requires special sauce to work in OpenPnP.  It does have a defined path for implementation though.

A couple of these things may require modifications to OpenPnP to work, but I think the result will be worth it.

  • Think outside the cylinder.

    Daren Schwenkea day ago 0 comments

    The modifications cleared the end effector, but now would have intersected with the cables at the back of the build area.  Bah.

    The new solution now squashes the part light ring down from a circle to an ellipse.  

    I've been stuck in thinking it could only be a cylinder from the 'light intensity falls off as square of the distance' thingy, but then again, I'm also then putting more elements in the same space due to the increased circumference.  It will probably all even out.  

    The diameter of the ring is all old math, and was based on even multiples of the segment length for the light strip fitting the inner circumference.  I hope that scales like I think it does.  

    It may also bring the edge of the ring into the FOV of the camera, which may cause me to need to move it back closer to the camera to kill the glare.  

    Trying it.

    Printing.

  • Clearance Clarence.

    Daren Schwenke2 days ago 0 comments

    My mirror arm modifications failed to clear the end effector pulleys.  These things will happen now that I have the motion platform and the P1 split into projects, and re-used the same global variables in both, so I can't just import one into the other.  Ooops.

    I have moved the virtual pulleys up to their 'ideal' location on the same plane as the center of the pushrod gimbal.

    It's now half a gram heavier, but prints faster.  Go figure.  

    Printing... again.

    <EDIT> I needed 1mm more, but I'm not willing to modify the end effector any more to get it.  

    Moved the mounting point on the head.  Printing that again..

    </EDIT>

  • Burn baby burn.

    Daren Schwenke2 days ago 0 comments

    Noticed as I was assembling the new main light ring in ABS that the edge had lifted and it was a little warped, and the 0.3mm single wall print was a little too thin for my comfort.  I changed it to two wall and reprinted. 

    I also noticed if I run the ABS as the absolute top of its heat range, like 275C, I get a flat black finish instead of more glossy.  Hey... I can use that.

    So I reprinted the part light ring like that.  It is there to keep the light from hitting the mirror directly, so a flat finish is good.

  • Reprint, aka, the chance to change everything.

    Daren Schwenke4 days ago 0 comments

    I've been modifying the source as I've been moving between parts to tweak things.  There was the distinct possibility I introduced incompatible elements in doing this.  Since I had a couple new parts to print anyway, I decided to reprint everything and finalize some things I've been meaning to do.

    • The end effector changes already happened a few days ago, and that moved the leveling to the side and added the ribbon cable run.
    • The pick and place head got some reinforcement around the groove mount.  I found that if I tightened the groove mount down hard, I could distort the body to the point that the spring on the nozzle would get bound up and not slide.  Fixed. I also increased the possible mounting range for the rotation servo mount, and fine tuned the Pi camera mount to self center better.
    • The push rod end now has a ribbon cable slot also, the servo plugs will now actually fit through the other holes without melting it first, and I tweaked the math so I can scale it a lot better.  There was an anomaly while printing the hinge area.   I was watching, so I saved the print by turning down the temp a little and slowing things down.  It is now a little grungy from having to sand down the mess in that area, but its strong and will work so I'm keeping it..
    • The mirror arm had the light ring mount moved out a little further to clear my '180 degrees from where I planned for it' end effector, some new channels for nicer wiring added, and some additional stiffening added where the servo drives it.
    • The part light ring got lighter, and I tweaked the mounting tabs to better center the light.  Well that's confusing...
    • The main light ring needed to be reworked.  I have been running the main light much more than would be used normally... like on for hours at a time, while working on this.  The PLA version was not up to that task and got squishy

    So... the main light ring base is now ABS, and the main light ring diffuser is now mixed material.  I didn't have any black nylon, so I just mixed in 30% black ABS into my translucent nylon.  Worked.  Angel hair stringies while printing.  Kinda neat.

    The rest of the new parts.

    Now to rebuild it all.

  • The wonderful simplicity of Metric hardware.

    Daren Schwenke4 days ago 0 comments

      I've come to notice some nice design patterns while building parts to work with Metric hardware, and I thought I would share.  

      Simple stuff, but it ends up meaning I need to keep less stuff in my brain while doing it.  That is usually a good thing.

      Size as used here is just the M number of the part, such as M3, M4.  Size is expressed as a diameter, with most OpenSCAD operations using radius, so <dia>/2.

      Clearance as used here is always 0.2mm, and that number came to be to allow over-extruding while printing to not affect the fit of the final parts.

      1. Through holes bolt sizes are just <size> + <clearance>.  So a cylinder to subtract for a bolt hole is:
        cylinder(r=(size+clearance)/2,center=true);
      2. Pan heads are always 2*<size> + <clearance> for diameter, and <size> for height.  So a cylinder to subtract to flush fit the head of a bolt would be: 
        cylinder(r=size+clearance/2,h=size,center=true);
      3. Encapsulating a nut or bolt head is just as easy.  Nuts are the same dimensions as pan heads, but you limit the cylinder to 6 facets.  The cylinder with 6 facets still has its vertices on the ideal cylinder, but the flats end up moving in the same as a nut.  So a cylinder to subtract to create a captive nut is just:
        cylinder(r=size+clearance/2,h=size,$fn=6,center=true);
      4. Threaded holes are <size> *0.9.  So a cylinder to accept directly threading in a bolt is just:
        cylinder(r=size*0.9/2,center=true);

      That's it.  Four simple rules and can you can use any metric hardware without measuring.  I've never actually looked up if there is a specification which matches these observations, but so far so good.

  • End effector tweaks.

    Daren Schwenke5 days ago 0 comments

    I've been slamming the P1 head into the bed on a regular basis while I work on implementing motion.  Unfortunately I need the vision on the head for some things, so not a lot of choice here.

    This has had the maddening tendency to throw off the leveling when the impact is off center.  My leveling screws only have so much pull before the cable slips.  Probably a good thing, or I would definitely be breaking stuff as I've turned the stepper current back up a bit.  I needed to.  At the edges of the build area with the head attached, I was starting to lose steps during > 400mm/sec rapids due to the increased mass.

    To this end, I've relocated the leveling screws to the side of the end effector, where I can get at them while the head is still attached.  

    I also lowered the gimbal hinge point and raised the virtual pulley.  The closer they are to planar, the better.  And... while I was at it I made a switch to enable/disable the blower mount/add a cable run for the Pi camera ribbon cable

    Printing, but this is a long one.  Need a small nozzle and low layer height to get the virtual pulleys to be smooth and accurate (and my first print failed on the hinge in the last 5 min)  ARGH.

  • Coordinated rotation.

    Daren Schwenke09/10/2018 at 10:38 0 comments

    Modifying and rebuilding tripodkins lets me do coordinated rotation now.

    This actually slows down the mirror flip, to match the plan instead of being 'as fast as it can go' so I probably don't actually want that, but I do want part rotation to be coordinated.  

    That will allow the command to return when the motion is actually complete according to the planner, and give me fine control over speed and acceleration.

  • Hats.

    Daren Schwenke09/09/2018 at 23:19 0 comments

    Well it seems I definitely have my software developer hat back on now, so I'm going to run with it.  I hope I don't lose my hat.

    Updated the BBG in prep for setting up my build environment, which broke Machinekit.  I'm bailing again, and starting over now with a fresh disk image about 1.5 years newer than what I was running.  When I worked on that image last, Stretch was brand new and I had to do all sorts of nonsense to get it to work.  Undoing that is likely more work than just starting over.  To that end, I've backed up my Machinekit config thus far here.

    <EDIT> Up and running on a new image, minus the updated kinematics.  That was relatively painless.  I now *have* to recompile tripodkins though, as my previously compiled .so for itripodkins (inverted) doesn't work anymore. So now my Z axis is upside down as tripodkins seems to ignore my negative HOME position, and so it doesn't flip the math on it's own.

    </EDIT>

    <EDIT_2:> Ok... Hats off to the Machinekit folks Realized it's all setup to cross compile right from the git repo, using docker.  That's probably what I did before and forgot about it.  Make a fork, made my changes, and ran the docker build using 

    scripts/build_docker -t armhf_9 -c deb

    Thanks to being able to use my room heater of an i7, less than 5 minutes later I had two .deb packages.  

    I ignored those and went looking for the 'itripodkins.so' file I just built, and found it in machinekit/rtlib/modules/.  That compile would have taken at least an hour using the BBG processor.

    I copied that into my freshly built image at /usr/lib/linuxcnc/rt-preempt/, and it works.  I now have the rc servo for part rotation as a proper axis, with limits, scale compensation, and the trajectory planner knowing exactly how fast things can move.

    Made a script to do the rest of the needed configuration.  I think I'll package up my own image from this.

    </EDIT_2>

    In other news, I think I've found a nice way to split the video stream going into Openpnp using Gstreamer vfl2sink, and the vfl2loopback kernel module.  Right now I can setup either the top camera, or the bottom camera in Openpnp, but not both.  They both expect exclusive access to the camera and since my implementation has only one camera... uh... that won't work.. but this might. If all goes well, it will even use DMA copies to do the split so basically no CPU penalty.  I'm psyched, but it's still early.  :)

  • Round and round.

    Daren Schwenke09/09/2018 at 08:17 0 comments

    Part rotation responds to joint position commands, but won't work as the C axis.  The reason is simple.

    Tripod kinematics in Machinekit doesn't pass it through, and worse... explicitly sets the ABC axis position to 0.

    I modified the source to fix it.  Took like 2 minutes.  But now I've now blown most of the night trying to get my build environment set back up for cross compiling Machinekit for the Debian Stretch armhf flavor which runs on the BBG.  

    It doesn't work.. I didn't isolate the libraries properly, so I'm pulling in wrong versions of stuff.

    So I just bailed and went the other route of just compiling it locally on the BBG, but for the life of me I can't get the my laptop connection shared out to it over USB.  I've done this literally hundreds of times, but my scripts/the old steps don't work anymore and I have no idea why.  I must have updated something and broke it.  

    EDIT: Tried the same steps on the Pi, and they work fine.  Going that 'route'...  I crack myself up.. Now it's just a matter if I can fit the entire build environment and a swap file in the 1 gig I have remaining on the onboard flash.

    I could always just resort to plugging it into my micro-router, but now this is personal.

    However, I have figured out all my Machinekit related issues:  

    • Mirror flips as a digital pin toggle
    • Rotation works and is a proper axis (minus tripodkins needing to be recompiled)
    • The solenoid works as a digital pin toggle.
    • PWM for the lights is an analog pin setting.

    Got to play with the camera, and discovered I really need to split my lights to run on two seperate mosfets.  The glare from running both lights in parallel completely overwhelms the bottom vision.  I'm redesigning the flippy part of the light too a bit while I'm at it.

    Here is a little video of most of what works now, with me manually putting in the appropriate M and G codes, and manually stepping the joint position for part rotation in 10 degree increments.  I'm still about half a degree off on my scaling for the negative side of the C axis rotation, and I believe my limit settings also need to be scaled now as I can't go a full 180 anymore.  For a first try though here, it was actually pretty close.

    I also ended up replacing my dirt cheap mirror flip servo with a proper one.  I tried to design the mirror arm to tolerate a pretty wide range of error and still stop centered, but what can I say.  The knock-off servos just suck that badly and the brand name ones behave a whole lot better.  They were ok at 50Hz update rate, but when I switched to 400Hz, they got worse.

    I think I'm going to relegate the knockoffs to just powering the tape feeders, where they just do the grunt work of pulling back the lever and no accuracy is required at all.

  • Keep away from open flame.

    Daren Schwenke09/06/2018 at 22:57 0 comments

    I was mounting the head and putting on a bit of heat-shrink when I got too close to one of the lines.  Oops.

    So much for seeing if it would stay calibrated when I moved it to the Makerspace tonight.

    A little bit of code, an hour drive, and now replacing a line are what stand between me and a video for you all.

    EDIT: Ok.. a little more than a little bit of code.  My digital pins within Machinekit are not cooperating, so I can't control the mirror or light from within Openpnp.  Ah well.  

    Recorded where I'm at anyway.

View all 86 project logs

Enjoy this project?

Share

Discussions

jediminer543 wrote 03/10/2018 at 10:28 point

This is pretty awesome.

Do you have any idea when you will be releasing the files? My local hackspace has been wanting a pick and place facility for a while now, and has a couple of unused 3D printer frames lying around.

Thanks.

  Are you sure? yes | no

Daren Schwenke wrote 04/26/2018 at 23:20 point

Files are up.  Not cleaned up, but they are up.

  Are you sure? yes | no

Marc Peltier wrote 02/19/2018 at 11:10 point

Hi Daren!
I had guessed the organization of gear train, and the need for a 90° gearbox, between the servo output and the actuator gear.

I recently experimented with gears in POM, very cheap on aliexpress. com. There are all kinds of models, straight, in crown, or at 45°, with different numbers of teeth. The bore is generally 1.95mm, when they are designed to be pressed together on a 2mm shaft, or 2.1mm, when they are designed to rotate freely on the shaft.

I was able to resize the bore with my lathe, according to my needs. For the small series we use, it is better to base the design on existing gears, to be modified at the lathe. Moulds are very expensive!

You can probably also make the splines for coupling with the servo output by heat, deforming an existing POM part with a brass servo output coupler, used as a heated punch. A hijacked hot-end will be perfect for that...

  Are you sure? yes | no

Daren Schwenke wrote 02/19/2018 at 15:11 point

That is pretty much exactly the path I took and the parts I used.  The fitment depth is critical though to prevent backlash and binding which took some iteration.

  Are you sure? yes | no

Marc Peltier wrote 02/20/2018 at 09:38 point

Just an idea this morning:
Dismantle the servo. Mount the potentiometer directly on the Pick&Place rotary tube, and try to directly link the last pinion of the servo gear train to this tube, with no 90° deflection, making it a part of the servo system. By the way, you will probably be able to improve the transmission ratio, and in the whole the precision in rotation. The very short stroke of the Z-Probe should make it possible to find a pinion thick enough to take up this movement without loss of link.

Of course, this will completely call into question the beautiful symmetrical architecture that you currently have, but I'm sure you will be able to quickly find a new layout logic, just as satisfying !

  Are you sure? yes | no

Daren Schwenke wrote 02/20/2018 at 10:06 point

Yep.  If I can't get the accuracy I need with just the digital servo, reading the output shaft angle directly is one way to move forward.  The servo potentiometer is still only 180 degrees though and a rotary encoder of sufficient resolution to actually improve the situation would greatly increase the cost.  

Rolling your own encoder you would need at least 400 cuts in a disk to improve here.  3D printing that at even 1 nozzle width per cut is still too large to fit nicely in the current design.

I toyed with the idea of drilling some holes in the third to last gear inside the servo and adding an optical gate there (with the servo re-wired for continous rotation).  The PID loop would move to Machinekit which is well suited to do a good job at it out of the box. That would work and I even have a suitable gate in my parts bin.  I would rather not though.

There are even existing multi-turn servos which are not continuous rotation designed for RC sailboats too, but again... many times the cost.

In the end, I'll probably just live with whatever accuracy I can get here.

  Are you sure? yes | no

Marc Peltier wrote 02/20/2018 at 13:11 point

Many RC servo potentiometers have a 270° stroke. These 9g servos are very economical, and trying to make your P&P head with just two digital servo controls makes sense. It's attractive because it's simple. And you could make a speed daemon with that, installed on a delta robot !

If you give up this approach, then why not just use this type of stepper motor Ø15mm, with directly usable output pinion and integrated planetary reduction: 

2 PCS high torque 5 V dc 2 phase 4 fil Dia 15mm moteur pas à pas avec micro planétaire réducteur avec engrenage conique(China)

https://fr.aliexpress.com/item/2pcs-2-phase-4-wire-Dia-15mm-stepper-motor-with-micro-planetary-reducer-high-torque-micro/32701351677.html?spm=a2g0w.search0104.3.28.9f4d765fv3pf93&ws_ab_test=searchweb0_0,searchweb201602_2_10152_10151_10065_10344_10068_10342_10343_10340_10341_10084_10083_10618_10630_10305_10304_10307_10306_10302_5722316_5711211_10313_10059_10184_10534_100031_10629_10103_10626_10625_10624_10623_10622_10621_10620_10142,searchweb201603_25,ppcSwitch_5&algo_expid=17e14cc8-4653-4261-ab15-56833755b9ca-4&algo_pvid=17e14cc8-4653-4261-ab15-56833755b9ca&transAbTest=ae803_5&priceBeautifyAB=0

You will get more than 2000 steps per revolution, about 2 turns/sec, with a backlash of about 5°, which can be cancelled by a spring. It is probably easier than using a position encoder and MachineKit...

  Are you sure? yes | no

Marc Peltier wrote 02/19/2018 at 06:35 point

Very well done !

I'm very happy to see this, because it's totally in line with what I imagine as equipment for my own Zatsit delta robot, very soon on KickStarter: www.zatsit.fr

Zatsit does not need the standard mount. Do you intend to publish the STL files, or better, the design files, so that it is easier to make the necessary adaptations?

You can get very cheap front surface mirrors here :

https://www.surplusshed.com/search.php?search=front+surface+mirror

Congratulations again!

  Are you sure? yes | no

Daren Schwenke wrote 02/19/2018 at 08:01 point

Thank you.

The source is a mess right now and I'd be embarrassed to release it.  I rushed it and most of my scaling and dimensional dependency best practices for OpenSCAD files went out the window. It's also started as an offshoot and is dependent on the code for the C1 so it would need to be split.  Eventually.

There are a couple bits like the right angle drive gears for rotation which require accuracy/fine detail beyond what any 3D printer can handle though.  I made the gears for the prototype by hand from existing injection moulded nylon gears, but it took a lot of patience and a couple tries to get them right.  If it works well, I'm going to look at getting them injection moulded with the servo splines built in.  Even then I think the only way to make the molds will be EDM.  Tiny stuff.

Thanks for the link.  I should be able to get a perfect set of mirrors here next time.  Still learning.  I got about 3 more tries here before I have to go spring for another $1 mirror.  Long term I'd definitely just source them cut to size, but this is something that people with a lot of patience can DIY to cut costs if I figure out how to do it and document it.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates