Like what you see? Support me on Patreon.
Building an open source robot arm for makers and small businesses
Like what you see? Support me on Patreon.
@Andreas Hoelldorfer has been building a 3D printable robot arm. It's making progress faster than mine.
His forte is hardware and mine is software. It seemed only reasonable to combine forces. So I asked him to share his Inventor model files with me, and then I imported them to Robot Overlord.
Here's a quick video of forward kinematics in action.
Inverse kinematics shouldn't be too hard. Java support for joysticks is shamefully bad. Firmware to connect RO and AHRobot together is definiitely possible.
Meanwhile I've been spending a lot of my free time working on my own design. It's very slow going. I have the wrist designed to satisfaction and the elbow is working-but-ugly. The shoulder and the pistons to drive the arm backhoe-style is where I'm currently struggling. I wish I had more time!
instagram doesn't embed, boo hiss. https://www.instagram.com/p/BDoEmVzIfO7
Yesterday I moved the software for controlling the arm from http://github.com/i-make-robots/Evil-Overlord to https://github.com/marginallyclever/Robot-Overlord. I, for one, welcome this move.
I also completed the merge of the older Arm3 into Robot Overlord, along side the Evil Minion (5 axis), the Delta Robot, the Stewart Platform, and Spidee (crab robot). The only robot that isn't merged is the Makelangelo, which has been eating all my time by being very very popular.
Also last week I was looking at https://hackaday.io/project/3800-3d-printable-robot-arm and I see @Andreas Hoelldorfer has used a camera quick-connect for his tool changer. Great minds think alike!
Going from zero to one of something is challenging.
Going from 1 to 2 is still challenging, even if you're planning ahead for it. The bill of materials was wrong, the assembly instructions weren't written down, and there were design choices that didn't matter for "just getting it done" that made doing it again a pain in the ass. Already I'm thinking "all this here, this over here, and those bits should be changed for easier manufacturing".
I've ordered enough parts for five machines, and I've begun assembling them. The documentation will be smoothed out by then.
Because of the high difficulty assembling the machine I'm only offering to ship fully assembled arms: http://www.marginallyclever.com/product/evil-minion-5-axis-arm/
I've only had one robot go to >1000 units. I look forward to having an arm do the same.
Picture was taken at Makerfair NY 2015. Curiously, the photo didn't include attribution and the arm doesn't include an intel chipset AND the fair they are promoting is not one to which I have been invited. If you are in Rome for the fair, ask the intel booth "where is the arm?" Maybe if we make enough noise they'll fly me to other EU fairs to set it up and bring it to you.
...which means once I setup my robots in the simulator their locations will persist. This will make it easier to run more sophisticated tests. It also means that (in theory) I can stream worlds to another computer. Why not gamify it? I wonder how hard it would be to make Evil Overlord run with Steam....
Replaced all the shameful wiring that killed my public demos.
It was like this: https://instagram.com/p/8lroiJIfJ0/
Now it's like this: https://instagram.com/p/8mMWpdofDs/
Modded a few parts to improve cable management. Fewer danglies. Eventually all the cables will be sealed away.
The gripper code I wrote while at NY Makerfair didn't include the 3D model parts. Now it does. 1:1 modelling across the board.
As of 2015-10-03 I have Evil Minions, Stewart Platforms, and Spidee-1 all running in Evil Overlord. This means less code for me to maintain, more cross-promotion, and opportunities for robots working together. For you it means one program to install instead of three.
For a while now I've wanted to support many robots in Evil Overlord. To do this I need two things: (1) a way to select robots on the screen and (2) a context sensitive menu for each selected robot. I've had #2 for a while now. Today I got #1 working.
0800-1300 today was spent cleaning up code for menus so that each tool on the arm generates it's own sub-menu and there's the start of an attach() and detach() behavior that swaps out the sub menu.
1300-1800 was spent building a ray picking system. Ray picking involves shooting a ray out of the camera, through the cursor, into the 3d world, and finding the nearest thing that the ray hits. Those five hours were spent checking the ray went out, stayed correct, and so on. I got that working and felt very good about myself. Mentally, I turned the page.... and realized I'd have to build code to make the ray hit every triangle in every object, figure out which one was closest, optimize the shit out of it... Aw hell no.
Surely there's a way to get the OpenGL graphics to tell me what's under the cursor to begin with, right? They're already doing all the heavy lifting. (In retrospect) it would be stupid to reinvent the wheel. As it turns out glRenderMode(GL_SELECT) is for exactly that purpose. I'm so happy it works, I don't mind the time wasted on the ray picking.
Here are two great links I found to explain how OpenGL sampling works.
Now in Evil Overlord you start with an empty world and the context sensitive menu is set to the camera controls. The "World" menu at the top has only one option: "Add Evil Minion". Click it and an Evil Minion Arm appears in the world. now any time you click on an EM the menu changes to that robot. You can connect over serial, drive it with FK and IK, and open/close the gripper.
I have tested adding multiple robots to EO at once they are independently selectable, each can be connected separately, and clicking on the background (anywhere with no robot) returns you to the camera menu.
Should the next step be:
I'm in Ottawa, Canada, visiting my parents for the next few days, and trying to run my business from remote is tough. At least I have Evil Minion #1 with me to hack on.
The wrist rotation is the only rotation that can move more than 360 degrees. If the wrist is at 350 and I say "go +20" it wants to reach 370 but the sensor says 10. Uh oh! Same thing going down (start at 10 and move -20).
Fellow Vancouver hackspace member Shane figured out a solution that works really well. I could complain that it only works if your move command is less than abs(180) but we don't listen to that nasty little voice, do we? No, we don't.
I've also moved all the code for the gripper tool into an ArmToolGripper class that's derived from an ArmTool class that's derived from an ObjectInWorld class... phew. An ArmTool loads and displays the STL for a given tool and provides an attach() and detach() hook. Like every ObjectInWorld it can provide and update a UI. That way when you choose to attach the gripper it will display open/close buttons. When you choose drill it will have speeds. When you choose air pump it might have suck/blow/off.
Now I'm actively looking for software design advice to create the record & playback system. The Makelangelo does it all by saving commands to a text file and then spitting those commands out in an uninterrupted sequence. The Evil Minion is far more sophisticated. So much so that I don't yet know how to tackle the challenge. One possible way is a multi-track editor. Another is something that looks like node-RED or Scratch. I could go the route of one of my competitors and make a custom 4th gen language nobody else uses.
In other related news, at the NYMF I saw a robot arm that claims to have 20 bits precision, but doesn't come assembled, doesn't have ANY software, and could only make a single move. I'm already working with my suppliers on a 14 bit version, so a 20 bit version can't be that far off.