robot arms in Robot Overlord
News

Friday Facts 11: How to add a robot arm to Robot Overlord (2022)

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!

News

Friday Facts 9: Daisy Stepper Driver 1.0

Daisy Stepper Driver is a closed-loop stepper controller that can be daisy-chained.

A stepper controller is a dual h-bridge circuit for controlling a stepper motor. You may be familiar with the A4988 stepper driver common in 2020s 3D printers. This board includes a more advanced model of the same. It can drive any one stepper motor at 24V up to 2A.

Closed-loop means that the board has a brain chip (MCU) that can read the motor position as well as direct. This way it can tell if it missed a step, bumped into something, is being driven, etc.

Daisy-chained means that they can be hooked sequentially. Sequential wires are much shorter. Shorter wires make for easier construction and repair. They are designed for up to 6 Daisies in a row. The Daisies talk to each other via the CANopen protocol.

The MCU is an STM32F103. In speaks CANopen natively while driving the stepper and listening to the sensor.

The CANopen master at the base of the robot can be any MCU that speaks CANopen. It synchronizes each motor and provides a single USB or bluetooth serial connection to the world.

What does this have to do with robots?

This board is designed to fit inside each gearbox of the Sixi 3 robot arm.

The old way a wire from every part had to run all the way through the arm and out the base. To replace the second joint from the bottom you would have to dismantle the entire arm. In the daisy chain model you only need to remove the elbow and disconnect the two cables to the next link in the chain.

Here’s a video of the arm moving IRL. Note the large cable hanging off the side – this version does not have the board in yet. It is the “outside” version of the wiring. I live in constant anxiety that they will get caught on something while moving.

Editor’s note – in this video one motor misbehaves. It was later found that the motor was negative 400-steps per turn instead of the expected 200-steps-per-turn.

Why isn’t the board in already?!

To test the board I have to be able to program it. To program the STM32F103 MCU I need to flash it with a bootloader via the programming pin J6. I have an STLINK V3 MINI to flash the bootloader BUT the MINI has male pins at 1.25mm pitch and my board’s J6 is 2.5mm pitch.

Editor’s note – I believe the larger connector is also a reversible connector.

Do you want to see this board get done? Say something nice on Discord.

What comes next?

Assuming this board is good and can be programmed… the next tasks are:

  • mount the board in the actuator
  • attach the disc to the output of the gearbox
  • run wires from one to the next and test the daisy chain
  • get an appropriate brain board and drive everything synchronously
  • make more boards

At the last stage it will be time to go to Kickstarter to scale production and bring the price down.

Did you design this board yourself?

No, and I’m proud of it! I have played with KiCAD in the past and done a few but this was beyond my skill. I found a great EE on Fiverr, gave him my specs, and he routed everything in a couple of days. Truly blown away by his skill. He even had a PDF step-by-step guide for ordering from PCBWay so I didn’t have to assemble the board or nothing.

Sadly, he closed his account and I have no way to reach him any more. Electroniikka! If you’re out there, know that I want to work with you again. I love working with talented people, it’s fun, easy, and it helps me scale up to the speed I long for.