close-circle
Close
0%
0%

Robot Overlord

3D simulation and control software for robots

Similar projects worth following
close
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 (RO) gamifies industrial robot programming. It makes controlling them an intuitive experience driven by immediate visual feedback by displaying a 3D model of each robot 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.

My first robot was a crab robot. All I knew back then was that hardware mistakes are expensive and software mistakes are cheap. So I put a 3D model of my robot into an empty video game and taught it to walk. When that worked, I copied the walk code into my actual robot (based on the 3d model) and it worked. Since then I've added all my favorite robots to one app to keep development effort to a minimum.

At present each robot has a context-sensitive menu to control it. If the robot is connected to the simulation, they move together. In some cases pushing the real robot affects the simulation. Work has begun on undo/redo, which will later evolve into record & playback.

There is a lot of opportunity to improve the software ease of use, add achievements, steam distribution, a point system, etc. I'd like people to plug in a robot, give it a command, and let players on the web game their way to an optimal solution. I'd like a VR interface for tele-robotics. I want my robots on the first experimental SpaceX trips to the moon, and then I want them to build our moon base by remote control. Join me!

  • 1 × Eclipse
  • 1 × Java
  • 1 × OpenGL
  • 1 × Fusion360
  • 1 × Maven

View all 10 components

View all 14 project logs

Enjoy this project?

Share

Discussions

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

Does this project spark your interest?

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