I bought and assembled an X-Carve CNC. I am now designing a few parts to hold the rotating air nozzle that will pick up jigsaw pieces. (purple plate, pin, plate, yellow tube.) once I can turn and suction up pieces I’ll add a few more bits to hold a raspberry pi camera, which will be mounted to look down at the nozzle.
Here’s the X-Carve mostly assembled.
This has been on the backburner for too long, sitting in a corner and taunting me with it’s unfinished business. The problem is not the suction nozzle or the camera or the code – it’s the janky gantry I built, partly to save money and partly to learn about CoreXY systems.
Business is good and the money is there, so I’ve purchased an Inventables X-Carve machine. Once it arrives I’ll mount the suction nozzle instead of a cutter and run the system like that. Later when the thrill of jigsolving is gone I’ll repurpose the X-Carve as a traditional CNC machine.
More when the X-Carve assembly happens.
Programming robots visually is proving to be a big challenge. I thought I laid all the ground work but now I’m not so certain.
Each derivation of Robot has a derivation RobotMotionState (a snapshot of the robot at a moment in time). By comparing RobotMotionStates I hoped to test for robot/robot collisions.
I’ve also got a system to command a robot to move, which changes the RobotMotionState, checks that it’s internally valid (robot can reach that far) and externally valid (doesn’t hit anything in the world).
I’ve been stuck for months trying to build a system of RobotPrograms. Something like the Adobe Premiere or Flash timeline, where blocks of time have one command each. I couldn’t wrap my brain around it enough to come up with generalize-able cases that could be written once and work for all robots.
In a dream last night I flipped things around a bit. What if a timeline has keyframes and each keyframe is a RobotMotionState?
Ideally there should be a way to interpolate between two RobotMotionStates. That way as the read head is moved along the timeline the robot(s) move between their states. There must also be a way to calculate the difference between two RobotMotionStates and send *just that change* to the robot as a command.
Oy. I’m not sure this is any easier.
To make RO easier for developers, I have published the API at http://marginallyclever.github.io/Robot-Overlord-App/
Next, the robots currently supported by RO will be moved to separate projects with their own github repositories.
A crucial feature here is keeping it easy for the end user, whom I assume (in a worst case) know nothing about computers. They shouldn’t have to modify the classpath or open a shell. I’d like it to be as easy as Arduino’s board support installer – pick from a list of plugins online, download on demand, and go.
Next, one or more tutorials will be made showing how to fork a repo, modify the robot type to your needs, and then publish your new plugin such that RO can find and install your plugin. Much easier than having to wade through the entire RO project and make a pull request.
After that I run out of ideas. Comment with your suggestions, please.
Here’s the latest robot I’ve added to RO: A new stewart platform.
Yesterday I went to NEWLINE hose & fittings in Burnaby, Canada, and picked up some new parts. The old model was the clear vynyl tubing and then a bearing to let just the tip rotate. Air was leaking through the two rings of the bearing. That made the suction at the tip too weak to pick up a jigsaw piece.
I suspect the final mechanism is going to be too large for the CNC head I’ve got. Lesson learned: get the tool designed first, THEN build the gantry that will hold the tool? No… that’s close…
When building a machine, I start by defining the goal, then work backwards from there. I needed a machine that would pick up jigsaw pieces and move them around from the internet. So the first thing I did was pick out a table for the jigsaw pieces, then build the biggest CNC I could on that table. Anyone else see how that’s backwards? Yeah. Looking back on it, it’s obvious.
So if I’m doing this the right way around, the immediate next goal is to get a nozzle on the end of this 1/8″ NTP brass 90 degree connector, and assert that it can pick up a jigsaw piece with the pump I have. Then build a mechanism A to rotate the nozzle. Then build a mechanism B to raise/lower mechanism A. Then attach that to the CoreXY. Etc, etc.
While I was there I learned about the threading on the 1/8″ NTP connectors. First off, the ones above are 27 teeth-per-inch, which we figured out with a Thread Gauge, a tool I’d never seen before. Neat! Also, the air-tight seal between two components is possible because the depth of the thread is tapered – as the parts are screwed together the fit becomes tighter. I was advised to tighten until I meet resistance and then give it an extra 1/4 turn.
The change to the milky white silicone tubing is to allow more flex when the nozzle tip rotates. I’m basing this choice off the uArm.
I’m also going to copy their idea for a rotation system, using some 3D printed parts to hold the brass fitting at the end of the tube on a hobby servo. Then all that will go on a second servo to raise and lower the mechanism, and the camera will be as close as possible to the lifter, which still having a view of the nozzle.
I’m going to try to make some nozzles that are all 1/8″ NTP at one end and different inner and outer diameters at the far end. For example, a nozzle for SMT components might be 1mm ID and 3mm OD. A jigsaw piece might need 3mm ID and 10mm OD, forming a wide flat suction cup.
Here is where I have a question for you:
Is it more efficient to
(A) make a few different designs at once and pick the best fit or
(B) make one, test, repeat until best found
?
