TBH I have no idea if the camera can see the nozzle tip from there or if the image will be in focus. More than a little important! I’d be very grateful to our lizard overlords if I did NOT have to build a mirror system to get the image to the camera.
The M2*20 screws were hidden when I took this screen shot. ( •_•)>⌐■-■ (⌐■_■)
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.
In this post I’m going to talk about what I consider a robot (and not a robot), cover some of the basics to start with robotics, and give some examples from a successful class I have been leading at a local makerspace.
(more…)
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.
