The Sixi Calibration Tool helps anyone using a Sixi robot make sure that the robot’s mental and physical states match.
They have to match or else.
If they do not match then the move you expect is not the move you will get. This could very quickly lead to an accident.
Ok, what do we do about it?
There has to be a way to synchronize the mental model and the physical model. The calibration tool is made to fit in one place and attach to the arm in only one way. This forces all the robot joints to move to known angles. Those angles are measured in the mental model in Robot Overlord and then copied to the physical model in the robot’s brain.
This blast from the past came up in my news feed today. In 2010 I didn’t know anything about building robots, I didn’t have CNC machines or laser cutters or even a 3D printer. I made my first parts from foam core and hot glue! Wild times, wild times.
Point being don’t let your tools stop you, don’t let your talent stop you. All you have to do is have the will to figure out a solution.
If there’s one piece of advice I can add… Someone already went through the pain of figuring out an easier way to do things. I’ve been there so many times: working on some small job N times and it’s always around N*90% that things start to get into a really good rhythm and I wonder “why couldn’t someone show me this technique at the start?”. So my point! My point: you find them and copy their method? That’s called “doing your homework”. You refine it and get really good at it? That’s called “practice”. Do these things. They help you get better faster, the most efficient way to make more stuff.
Unless you know a faster way. Then tell me because I want to copy your method.
I have been building a robot arm. You may have seen it on my Instagram. I also have an open source Java app called Robot Overlord, which can simulate the arm in 3D. Robot overlord can drive the simulation AND the real arm by moving the joystick. All the moves in this video were done with the Playstation controller:
In a previous post on Hackaday.io, I briefly covered a system I wrote into Robot Overlord that would capture all the joystick data and play it back on command. Technically, that worked. Qualified success.
However! Driving this way is way inefficient. new instructions are sent to the arm 30 times a second. The arm can’t see where it is going, so it can’t plan to reach high speeds. It’s like a very fast game of Marco Polo. Also if you’re a novice driver like me it’s really easy to go the wrong way. It would be great if I could move the simulated arm to a destination pose BUT only update the real robot when I’m sure I like my destination pose. Then the arm would then move in a straight line from start pose to end pose at top speed.
First I needed a way to save any pose to a file on disk and then bring it back. Then I could save and load single poses. Then I could play those poses back to the real robot, same as I did with the joystick model. Then I could repeat tests, which helps me confirm things work correctly.
If I have a start and an end pose then I can find a way to interpolate between two poses – I can split that line into sub poses if needed. I can already send poses to the robot. So what I can do is find the happy trade off between too many poses (no acceleration) and too few (less accurate movement).
Looking through my daily notes I see I started on the new system some time before 2019-8-13, because that was when the weirdness started: I found cases where recording to disk and coming back were out of sync. Not identically 1:1. Discombobulated. When I tried to play back a recording the hand of the robot (J5) was always turned 90 degrees from the original recording. As I began to dig into why, I opened a whole can of worms. Bigguns.
Worm: The robot sim in Robot Overlord was wrong.
When Jin Han and I built the computer model of the robot arm in Fusion360, the design was started in November 2018 and back then we started facing the wrong direction.
Arm designed pointing at -Z
When I say it was built facing the wrong direction, I mean that I imagined That both Fusion360 and Robot Overlord would have the hand pointing at +X and up was +Z. In fact, in Fusion360 the hand is pointing at -Z and up is +Y, and in Robot Overlord I reassembled the arm with the hand facing -Y and up is +Z. Copying the model over was stupid hard and I didn’t realize that was partly because I was doing it the wrong way, turned 90 degrees on two axies. It would have been easier if it was upside down and backwards!
My method to solve it was to load one joint at a time starting at the base, get it turned facing upwards, and then add another link and so on. Once all the bones were in their relative positions, build D-H parameters that matched.
Worm: The D-H model of the arm was wrong.
The Sixi was the first robot arm I ever coded that used Denavit–Hartenberg parameters. One of the reasons I used D-H parameters is that they’re well documented and supported by other people into robotics. I can easily use D-H to calculate Forward Kinematics (FK), where i know the angle of every joint in the arm and I want to get the pose of the hand. (A pose is a position in space and an orientation. One common way to describe this combo is with a 4×4 matrix). I could also use Youtube videos that explained how to calculate Inverse Kinematics for a robot arm with D-H parameters. Especially tricky is the spherical wrist:
Of course my code didn’t quite match the stuff I’d been taught because my model was facing -Y instead of +Z – a 90 degree turn. Every time the tutorials said use atan(y,x) I had to write atan(-x,y).
Not knowing that I’d done all this stuff wrong yet, I had to diagnose the problem. I build a jUnit test in src.test.java.com.marginallyclever.robotOverlord.MiscTests.java:TestFK2IK(). This test sweeps the arm through the set of all angles keyframe0. Every instance in keyframe0 creates some possible pose m0. Some m0 can be solved with Inverse Kinematics to make some other keyframe1. keyframe1 can create a pose m1. m1 should ALWAYS match m0. I got lot reams of big data, all of which told me Yes, there’s definitely something wrong. It took about a week of nail-biting research until I figured out and unscrambled each of those worms.
So what does all that mean? It means I can now build meaningful recordings and now I can start to search for the right happy trade off .
With this we can finally finish the hardware preparation for shipping
units, after which we can also get a final bill of materials and start
to package DIY kits. There will be two flavors:
DIY kits with all the non-printable parts.
DIY kits with everything, including the printed parts.
The software only lets each joint of the robot move within a safe
range to prevent wire twisting or other potential damage. That piece of
code does not consider the angle of joint A in relation to the value of
some other joint B. So it was still possible to make the arm hit
itself.
This new collision detection code prevents each bone of the arm from
colliding with other bones of the arm. At present it is a crude
collision detection system, using only the box around each joint.
Also now that these boxes have been calculated, the center of each
box is known. the mass of each bone can be pulled from the Fusion360
model, and then a point-mass physics model can be created to simulate
forces like gravity. This gets us closer to dynamics like push-to-teach
and telling the arm “please push on this item with a force of N
newtons”
Next
Next we’ll be assembling the new shoulder design with the PCBs that
should allow us to unplug the umbilical from the arm and the control
box. I’m thinking Twitch stream? Maybe just a Youtube Live, given the
recent Amazon protests. Choice of evil companies… hmm…
Delta Robot 3 uses three motors turned 60 degrees from each other to achieve XYZ translation motion. It is most popularly known in the Kossel 3D printer. You might have seen one of our robots at DEFCON being used to type out pin pad combinations to unlock a cell phone.
While we do not make the Delta Robot 3 at this time, we believe in open source software & hardware. So here is a copy of our internal Delta Robot 3 assembly manual.
This robot was designed at a time when we did not have reliable 3D printers. Challenge yourself to design STL models!
Special Thanks
Special thanks to Justin Engler, Jae Hess, Steve, Juho Leinonen, Mark Scheel, and Eddy Hodak for helping improve this Delta Robot 3 documentation.
Tools you will need
A soldering iron.
Crazy glue or wood glue. Crazy glue takes seconds to stick. Wood glue can take up to 24h and may require clamping.
A small Phillips screwdriver
a pair of pliers
Solder the wires on the switches
You can also crimp the wires with blade connectors if you have the tools. These days we prefer non-contact sensors for more accurate position sensing.
Snap together the ball joints
The
grip I’m using is the easiest way I’ve found to snap them together.
Pinch with the pliers to get most of the way there and then gently press
down with one finger and the plastic should “pop” onto the ball.
Glue the end effector together
These three screws are M3x25. This part could have been 3D printed in a single step.
Glue the biceps together
Please be extra careful to glue these correctly. Exact alignment is very important! The screw is M3x15. This part is much easier to make with a 3D printer where no glue is required.
zip tie & glue the stepper mounts together
Please carefully note the direction of assembly. It is very easy to assemble the entire robot backwards. Then the firmware won’t match the physical model and everything has to be redone.
You will need the motor mount plate
and the mounting bracket pieces.
Use some glue to attach the triangle face to the side of the motor mount plate.
install the steppers in the stepper mounts
Use M3x10 screws to attach the motors.
attach the biceps to the stepper motors
Depending on availability you may have received MOTO-0007 instead of MOTO-0003. Please see the links for details on the differences and what to do about it.
The arm will only fit when the flat side of the shaft is correctly lined up with the screw in the arm.
I am using a spacer to make sure that the biceps are attached at the correct distance from the face of the motor. The spacer should not be glued in! It is only temporary.
This is a closeup view of all three arms attached.
zip tie the three frame components together
Sometimes
humidity might make your unassembled pieces a bit warped. When they are
attached together with the zip ties they will straighten out.
close the frame around the stepper mount
Attach the base plate into the frame
There are many holes in this plate so that you have options when securing your work piece.
Attach the forearms to the end effector
In more recent robots our process is to precisely assemble the plastic rod ends onto the rods, then insert the balls, THEN attach the rods to the rest of the robot. The results are more consistent and accurate. What you see here is our process way back when.
These pictures show M3x40 screws, but we have changed the kits to use M3x30 screws.
Attach the forearms to the biceps
The screws are M3x30. The rods are M3x150.
I use the M3x30 screw as leverage to make screwing in the rod a lot easier.
The distance from center hole to center hole should be 165mm.
The two M3x30 screws should be parallel so that the whole
assembly makes a parallelogram. When I get close it can take a few tries
with half turns to get the measurements just right.
Assemble the pen collet
The
collet holds your pen in place in the end effector. If you drive the
tool too far down the collet will rise on the screws. It is our hope
that this will help prevent damage to your machine. A 15mm screw and a
nut are used between the glued layers. The capacitive pen is here for
reference, it is not included in your kit.
Electronics
Attach the switches on the frame
Make sure the zip tie is tight!
The funny angle is OK, and expected. You should be able to move the arm and touch the switch so that it clicks. This is the kind of amateur junk that made us move to touchless switches that don’t have “funny angles”
Attach the female plug to the RUMBA
attach the RUMBA controller on the frame
attach the switches to the RUMBA
The switch next to motor 1 should go to X-. The switch for motor 2 should go to X+. The switch for motor 3 should go to Y-.
Just above the pins are three symbols: +, -, and S. The red should go to +, the black to -, and the blue to S.
Attach the stepper motors to the RUMBA
Steppers are attached in counter-clockwise order on the frame and wired left-to-right order on the control board.
Depending on availability you may have received MOTO-0007 instead of MOTO-0003. Please see the links for details on the differences and what to do about it.
Teach the Controller
The brain of the robot is the RUMBA circuit board. To teach the
circuit board you will need the Arduino software, the RUMBA driver (so
windows/arduino can talk to RUMBA), and the firmware sketch that Arduino
will load onto the board.
Download Arduino software
and install it. Arduino software comes with lots of great sample code
to help you start learning about programming robots. You can use it to
read and edit the firmware for the robot.
Windows cannot find the drivers for the RUMBA automatically. Get them here.
Now that you have all the prerequisites, let’s do this!
Start Arduino software.
Choose Tools > Board > Mega 2560
Choose Tools > Serial Port
On OSX it should say something like /dev/tty.usbmodem12# You probably want the first one on the list.
On Windows it should say something like COM9. You probably want the last one in the list.
When your board is connected to a Windows computer it will appear in Start > Devices and Printers along with the COM port number.
Choose upload. It should be the second blue button on the left. At
the bottom of the Arduino window it will say “compiling” and then
“uploading” and finally “uploading done”. if you get timeout errors, do
these steps again on a faster computer.
Check the Controller is OK
Open the Arduino Serial Monitor (the magnifying glass in the top right corner).
Change the baud rate to 57600 (the drop down list in the bottom right corner).
You should see a message beginning with “Delta Robot v8-“. This
means the code has uploaded successfully. It should now be safe to
connect 12v power.
Put one hand on the power connector so if movement looks wrong
you can pull the plug immediately. This is your Emergency stop. Better
yet, have a friend ready.
Type “G28;” This tells the machine to find home by touching each limit switch one at a time.
Type “M114;” This asks the machine for it’s current position. It should start with
X0
Y0
Z4.77
The machine believes that the tool in the end effector is 0cm long.
Type “G54 Z-2;” Now the machine thinks that tool tip is 2cm below the end effector. Type “M114;” again and it should say
X0
Y0
Z2.77
because the tool tip has moved, even if the end effector didn’t. Now let’s try our first move command.
Type “G0 Z0;” This will lower the end effector until the tool tip
touches the bed. Since there is no tool at the moment it should stop
before it reaches the bed.
Let’s try different speeds now. Type “G0 X4 F3000;” The F3000 changes the feed rate – the speed – to 3000 microsteps per minute.
Finished Delta Robot 3!
The
steppers get very warm after running for a while. We have tested them
under load for 48h and they continue to function within spec without
unusual behavior. Even so, be smart: do not leave your robot running
unattended.
Auto home
The robot does not G28 automatically when it turns on to avoid the chance of accident. If you want to change that you can add
deltarobot_find_home();
to the end of setup() in the firmware.
200 step per turn motors
in configure.h there is a define for STEPS_PER_TURN. Change it to 200 if you have 200-step-per-turn (1.8 degree) motors.
Final thoughts
These days (being the days during which I write this post) Marginally Clever Robots do everything to avoid the use of glue. We like robots that can be un-made or repaired.
Did you know Delta Robot 3 is simulated in Robot Overlord? Connect one to the other and drive both at once!
