Close
0%
0%

Robot Overlord 3

3D simulation and control software for robots

dan-royerDan Royer
Following
Liked Like project

Just one more thing

To make the experience fit your profile, pick a username and tell us what interests you.

Pick an awesome username
hackaday.io/
Your profile's URL: hackaday.io/username. Max 25 alphanumeric characters.
Pick a few interests
Projects that share your interests
People that share your interests

We found and based on your interests.

Choose more interests.

OK, I'm done! Skip
Similar projects worth following
9.6k views
13 comments
121 followers
View Gallery
You're a dev building a robot and you want a 3d simulation and/or some control software for your machine. A well known, easy to use interface. You also have finite time and want to enjoy life, so you need something simple to code and painless for your customers. Robot Overlord is for you.

Robot Overlord gamifies industrial robot programming. It makes controlling them an intuitive experience driven by immediate visual feedback and allowing a user to manipulate them in real time. It will enable telerobotics and drive-by-wire. It will enable simulating robots for better project planning and shorter development times. It wants to work with VR.

Think of it as ROS for Windows & Mac users. The focus is on ease of use; familiar, consistent user interface; and abstracting away device specific things like config files or text commands.

Robot Overlord 3 makes it easy for your to simulate and program robots.  It's great for robot arms, dogs, crabs, and more.  Join us!  Help make robots easier for everyone.

  • 1 × Java

View all 20 project logs

Enjoy this project?

Share

Discussions

Zboy1997 wrote 02/23/2019 at 06:48 • point

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.

  Are you sure? yes | no

Dan Royer wrote 08/05/2016 at 20:29 • point

@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.

  Are you sure? yes | no

TheotherMike wrote 08/06/2016 at 10:03 • point

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.

  Are you sure? yes | no

QuasarAlpha wrote 08/04/2016 at 00:56 • point

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? 

  Are you sure? yes | no

QuasarAlpha wrote 08/04/2016 at 20:07 • point

Oh very cool! Thanks!

  Are you sure? yes | no

TheotherMike wrote 08/03/2016 at 20:56 • point

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...

  Are you sure? yes | no

Dan Royer wrote 08/03/2016 at 22:33 • point

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.

  Are you sure? yes | no

TheotherMike wrote 08/04/2016 at 07:15 • point

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...

  Are you sure? yes | no

Dan Royer wrote 08/04/2016 at 17:46 • point

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.

  Are you sure? yes | no

TheotherMike wrote 08/05/2016 at 08:14 • point

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

  Are you sure? yes | no

TheotherMike wrote 08/03/2016 at 07:18 • point

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

  Are you sure? yes | no

Dan Royer wrote 08/03/2016 at 17:35 • point

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.

  Are you sure? yes | no

Similar Projects

We want to Simplify robots' conception for futur generations.
Project Owner Contributor

Simplify robots' conception

hippolyteHippolyte

Robotic body controlled by thought and managed remotely through internet from distant places. Who said you can´t be in two places at once
Project Owner Contributor

Yori 02 Avatar Robot & Cyclop VR headset.

diego-balarezoDiego Balarezo

I'm developing small robots that can be controlled via Twitch Chat. Twitch Plays Robot Battles
Project Owner Contributor

Twitch Chat Controlled Robot

theotherlonestartheotherlonestar

Self balancing robot software part is that you can build your own own at home using this
Project Owner Contributor

Making Self Balancing Robot Software Part

next-builderNext Builder

Does this project spark your interest?

Become a member to follow this project and never miss any updates

Going up?

About Us Contact Hackaday.io Give Feedback Terms of Use Privacy Policy Hackaday API

© 2025 Hackaday

Yes, delete it Cancel

Report project as inappropriate

You are about to report the project "Robot Overlord 3", please tell us the reason.

Send message

Your application has been submitted.

Remove Member

Are you sure you want to remove yourself as a member for this project?

Project owner will be notified upon removal.