The Sixi 3 robot arm is the result of many years of study and research. I’m trying to build my dream machine that avoids every problem discovered in my previous robot arms. My short list of desirable things include:
Easy manufacturing = use less unique parts = use repeating components.
Easy maintenance = daisy chain components.
Safer = no loose wires, always know where the arm is, responsive behaviour. (safety third!)
To that end I’m on my second attempt to design and program the board of my needs. Here’s where I’m at today, December 31, 2022. Read on for all the details.
Discord user Wted00 said “You talk about Sixi 3 a lot. What ever happened to Sixi 1 and 2?” Great question, long answer. This video covers robot arms before Sixi and then all three models of the current brand, along with interesting things learned along the way. Plus stick around for movement demos at the end.
So you’ve got Marlin firmware installed, your models ready to load into Robot Overlord and now the struggle is figuring out the Denavit–Hartenberg parameters. We’ll cover where to find critical dimensions, some of the pitfalls along the way, and compare with a few different models to help clear up any misunderstandings. It is assumed that you already absorbed an understanding of D-H parameters from places like the wikipedia link previously mentioned.
Start with the data sheet
Commercial electronics products should have a data sheet or user manual. This is true for electronics components and it’s true for robot arms. The data sheet will have operating limits, physical limits, dimensions, use instructions, and more.
This is the dimension drawing for the 6-axis Sixi 3 robot.
some values have been rounded and may no exactly match the D-H parameters in the open source code.
D-H parameters in Robot Overlord
Here are the D-H parameters from Robot Overlord for Sixi3 6-axis model. Dimensions here are in centimeters. thetaMax and thetaMin are the rotation limits on a given joint.
It’s good to remember that the physical point of rotation (PoR) is not necessarily the same as the mathematical PoR. It’s tempting to think of the first PoR being where the shoulder meets the base, about 40mm up from the origin. Actually it is at the origin! Here is what it looks like illustrated by the Robot Overlord simulation
Sixi3 in Robot Overlord with “show lineage” turned on
At each PoR there is a 3×3 matrix. Each matrix has red/green/blue lines meaning x/y/z axies, respectively. Notice that the axis of rotation is always the blue z axis. The first joint has a blue line pointing up, as does the 5th. The 7th matrix on the face of the hand is the attachment point for a tool.
The math model and the physical model are slightly different like that. It is important that the axis of rotation is in the right place. It is not crucial that the point of rotation be, say, right between two moving parts. Typically the PoR is constrained by the location of the previous and the next PoR. Each of them is also constrained by the D and R values – you cannot “move” from one link to the next along the green Y axis…ever.
Compare and contrast
Here’s an image of a meca500 I found in their user manual.
Can you identify all 6 PoR? If the first joint (0) is at the origin, where are joint 3, 4, and 5?
Final thoughts
Work out the mathematical model of your robot before you do the rest of the design. Nobody wants to be stuck with a model that is incompatible D-H parameters.
Add your arm to Robot Overlord and share it with us. We want to celebrate your greatness and collaborate together.
Robot Overlord is going to be the inkscape, the VLC, the Steam of robot arms – the one vendor-agnostic interface everyone teaches, knows, and loves. In order to get there it has to support every robot arm under the sun. This post is for robot arm makers that want to save time by not writing all their own code.
Some of the arms already available
Did you know Robot Overlord speaks natively to Marlin 3D printer firmware? Save even more time by using the same firmware.
You will need
A 3D CAD model of your robot arm
The D-H parameters of the arm in the same pose as it appears in your CAD file
The ability to write Java code for the Robot Overlord project
Some familiarity with git (forks, commits, pull requests)
Prepare your CAD file
It is easiest to export your arm into discrete moving sections, all of which with the same origin at the bottom center of the base of the arm (see slide 1). This is the same origin as the D-H parameters.
A meca500 robot, color coded with the base and six parts. the origin would be in the red part, on the same axis of rotation as the pink part
To help Robot Overlord run smoothly and to protect your IP it is recommended that you decimate the model by removing all hidden internal structures and components. Consider leaving screw heads while removing the threaded sections to save many megabytes of file size.
Each discrete section should be exported as an OBJ or STL file. (more on this later.)
The exported files should be located in /src/main/resources/[your robot folder]/. So if your robot is named Foo then it would be /src/main/resources/foo/. It would be consistent to name them base, j0, j1, etc.
Prepare your Robot Overlord class
In Robot Overlord’s /src/main/java/com/marginallyclever/robotOverlord/robots/robotArm/implementations you will find the collection of currently supported robot arms. It may be easiest to copy one of these classes and modify it for your purposes. Here is the minimum needed to code your arm. Every instance of Foo should be replaced with your class name.
public class Foo extends RobotArmIK {
private static final long serialVersionUID = 1L;
public Foo() {
super();
setName("Foo v1"); // the name that appears to users.
}
@Override
protected void loadModel() {
setBaseShape(new Shape("Base","/Foo/j0.obj"));
// The DH parameters and the model file, added in order from J0 ... J5.
// angles are degrees, distances are centimeters.
// name d r alpha theta thetaMax thetaMin modelFile
addBone(new RobotArmBone("X", 7.974, 0,270, 0,170,-170,"/Foo/j1.obj"));
addBone(new RobotArmBone("Y", 9.131,17.889, 0,270,370, 170,"/Foo/j2.obj"));
addBone(new RobotArmBone("Z", 0,12.435, 0, 0,150,-150,"/Foo/j3.obj"));
addBone(new RobotArmBone("U", 0, 0,270,270,440, 100,"/Foo/j4-6.obj"));
addBone(new RobotArmBone("V",15.616, 0, 90, 90,270,-90,"/Foo/j5-6.obj"));
addBone(new RobotArmBone("W", 5.12, 0, 0, 180,360, 0,"/Foo/j6-6.obj"));
adjustModelOriginsToDHLinks();
setTextureFilename("/Foo/texture.png");
}
}
Now that the arm can be loaded by the app it needs to be on the menu of things that can be created by the user. In /src/main/java/com/marginallyclever/robotOverlord/EntityFactory.java add your new class:
public class EntityFactory {
private static Class<?> [] available = {
// ...
com.marginallyclever.robotOverlord.robots.robotArm.implementations.Mantis.class,
com.marginallyclever.robotOverlord.robots.robotArm.implementations.Sixi2.class,
com.marginallyclever.robotOverlord.robots.robotArm.implementations.Sixi3_5axis.class,
com.marginallyclever.robotOverlord.robots.robotArm.implementations.Sixi3_6axis.class,
com.marginallyclever.robotOverlord.robots.robotArm.implementations.Thor.class,
com.marginallyclever.robotOverlord.robots.robotArm.implementations.Foo.class, // "Foo" must be your class name.
};
// ...
}
Now when you run the application and open the Add menu your robot name will appear.
‘Foo v1’ will appear on this list
Model size and orientation fixes
It is possible that your model appears in Robot Overlord too large, too small, or the parts are rotated in a strange way. My solution is to use a modelling program like Blender to rotate, scale, decimate, and even texture the model.
Forward and Up will control the rotation. +Z is always up in a Robot Overlord scene.
Selection Only will simplify your exporting from Blender. In the image above it will only export J2.
Scale will control the size. For models that appear in meters instead of centimeters, choose 0.1. If your model is imperial, you’ll probably want 2.54.
Now share it with …the world!
You’ve changed the code, you’ve massaged the model, it runs on your machine. Now to share it with everyone else! A pull request from you to the Robot Overlord project will tell the dev team that your stuff is ready. This is the best way to make sure your model gets in the way you want it.
No time? Let us do it for you.
We can add your model(s) to our system. Contact us! We’re looking to collaborate and work with everyone. Writing the class is free; preparing the CAD files is specialized work we outsource and will quote.
What about URDF files?
URDF is the Unified Robot Description Format, part of ROS, the Robot Operating System. ROS is a nice system but much harder to get running – part of the reason I work on Robot Overlord. Join the Robot Overlord github project and help make it happen? Imagine what we could do together!
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.
