Hi，Great project. I'm very interested in the design process of this robotic arm.Now，I‘m a college student, and I want to design a 3D printing mechanical arm like this by myself, but I don't know how to start,I would appreciate it if you could give me some hints.

@TheotherMike The goal is to easily generate motion profiles for each type of robot through a common interface.  One stand alone app for each robot type is stupid.  Gamified systems integration is where it's at.

That was more or less my question... I think it would be very helpful to make good documentation and tutorials how to work with RO and also about the "common interface" and what "gamified" means in your case.

This is an interesting project you have going on. Once you get RO working with VR do you have any other development plans for it? Things like allowing objects to be added for the robot(s) to interact with? 

https://hackaday.io/project/12971-robot-overlord/log/43186-how-to-load-an-stl-file-in-robot-overlord

Oh very cool! Thanks!

Hi Dan,

no, no, as I wrote! I don´t have mixed up anything ! THAT is the point ! ;-)  But it seems it´s not...

Think of a real robot arm equipped with a simple controller and a "cartesian" firmware, such as grbl or so. Its calibration is just linear and lets say g1 X10 equals to a movement of 10°.

Now, in ROverlord, the arm geometry is implemented which can be seen on the screen. Now using ROverlord, open a standard cartesian gcode and the multiple paths are shown in ROverlord (compare with a gcode simulator). Using pan/tilt/shift etc. move the gcode-paths (the whole pathway package) as you like to place them accordingly with respect to the robot model in order to adjust distances etc..

Now connect the arms end effector or the tool tip with the pathway and define its angle/distance/offset to the gcode pathway package. Now, let the tool tip and with it the whole arm move along the gcode path and read out the arms angle movements.

The readout then contains the angular position of each joint and its velocities which can be converted to a new gcode set which can be fed to the cartesian controller.

With this, many, many diferent robot arms could be controlled without tackling the IK on the controller. Instead one could use the ROverlord to visually see, what it will do, fine tune the arms positions as there are several solutions how to drive along the gcode paths....would be a visual Robot-CAM-Program...

I don't know why you want to send angle values.  GRBL is sending cartesian XYZ translations and trusting the firmware to move in straight lines.  If I send angle values only I cant' trust the firmware to move in straight lines.  Perhaps I am mistaken.  From here It sounds like your fundamental assumptions need work, the issue you want to fix isn't actually an issue to begin with.  taking gcode from one machine and running it on another is theoretically possible, provided the gcode does not have machine-unique codes that are essential to successful simulation.

It was just a thought... Many guys out there want to have a Robot arm (me too ;-)), and main problem is not the mechanical part but the Controlling part. There are some high priced CAM-Systems for Robot programming, out of reach for 99% of us. Everytime one Needs to adopt the special arm geometry, wether in IK or in the post processor.

As far as I now understand, ROverlord is a movement Simulator which Shows how it will move according to the code one has created somehow.

My thought was, use ROverlord to visually create the pathway and Export the code to control every Robot with a simple Controlling System because all movements have been converted to the angular movements of the arm. Provided the angle readout is executed often, one can again trust the Firmware because it just follows the angles in the same way it follows the XYZ translations....

3D CAM Systems for CNC-mills are more or less available and I think it would be beneficial to use an arm similarly.

I searched the WWW for examples I have in mind...but only found one: "RoboDK"

But maybe I´m completely wrong, so please apologize... Perhaps it´s better to ask the other way round, how would you do the following:

You want to laser engrave an Image (lets say you can use a vector Format, not Pixel by pixel) onto a wooden board using a self built Robot arm with 5 axis. Assuming the Laser control is working and the only Thing you want to do is path planning?

Now a friend Comes, but with a 4 axis arm, wanting to engrave the same Image...

Each robot developer creates their own IK and builds the RO model of their
robot.  The Robot Overlord developer (me) deals with creating path
solutions (generating tool paths) which are then sent to the robot. 
what happens inside the robot is the robot developer's business.  If you
want to send angle values instead of gcode, you can do that.

So, you can load an Image or dxf-file to RO and create the paths for engraving it using your own Robot model ??

Dear Dan,

awesome Project and I read about it several times before!!

A question that comes immediately into my mind....is there an Option to use the R.-Overlord to read/open a common gcode (generated for an cartesian mill or printer), connect the tip of the milling bit/end effector/Extruder nozzle of the Robot model with the gcode, read out all the angles and velocities and export a modified gcode which includes the Special geometries/kinematics of the Robot? With this, one would "not have to deal" with inverse kinematics. Would be somehow like the old cnctoolkit.

So, one could use it as a multifunctional post processing and visualisation tool for different robot geometries. At least for robots with low number of degrees of freedom...

Kind regards

Mike

Hey thanks, @TheotherMike.

inverse kinematics should be handled in the robot firmware.  Gcode shouldn't have anything to do with IK.  It sounds like you've mixed two separate things.

If two robot will obey the same gcode, their IK/FK doesn't matter.