Which features are really important for offline programming? With so many options, picking the right software for your robot can be confusing. Here are 5 features you can safely avoid.
Some years ago, I was looking around the market for a good simulator for my robot application. After testing software, after software, after software, I was getting nowhere.
Each package seemed to have some features which made it useless for my needs. One software would make it very easy to create a new robot, but lack the ability to interact through an API. Another software would interact very well with other programs, but the physics would become completely unstable, seemingly at random.
I started to ask myself “What features are really necessary for my application?”
I suddenly realized that I had been looking for the “best” robot simulator. Instead, what I should have been looking for was the package that made my life as easy as possible, whilst providing only the features that I really needed.
With offline programming, this is also a good strategy. Look for a software which makes your life easy, whilst providing the features that you need. Avoid features that are not necessary or that will make your life harder.
Recently, a helpful user wrote a list of feature requests on our forum. It caught my eye. Some of the requests made a lot of sense, but a few of them struck me as unnecessary for offline programming. It reminded me of my past dilemma and prompted me to think:
Which features are unnecessary for offline programming?
In a moment, I’ll tell you five.
What an Offline Programming Package Isn’t
First, let’s be clear about what offline programming software is and what it isn’t.
The purpose of offline programming software is to provide a way for you to quickly and easily program your robot whilst maximizing productivity. As the Robotics Industries Association explains “[Offline Programming allows] for quicker deployment at a lower initial cost [and] has become an essential part of planning and designing an industrial robot system.”
Therefore, offline programming (OLP) software should be easy-to-use, reliable, and have a focus on improving productivity.
That’s what OLP is.
Here’s what it isn’t:
OLP isn’t a simulator for highly realistic models of a virtual world. A good OLP package shouldn’t try to accurately model every object, particle, and beam of light in a ultra-realistic model of the world.
But what if I want a highly realistic simulation!?
Then you don’t want offline programming!
High degrees of realism in a simulator require a whole different set of features than those required for good, efficient offline programming.
The features that make this realism possible often reduce the productivity of robot programming and make it harder to use. You have to do a lot of fiddling around to “get the simulator to play nicely” which means more programming and less productivity.
If you are in the situation where you need an ultra-realistic robot simulator, it’s likely that you are a researcher of some sort (either academic or industrial). You are probably developing complex control algorithms and want test them out with the most accurate simulated robot that you can find. This is great, but it’s not what offline programming is for.
5 Unnecessary Features in Offline Programming Software
Here are five features which are usually unnecessary in OLP software. I say “usually” because there may be some exceptions, but in most cases you don’t need a software with these features.
1. Physics
This is a big one. A lot of robot simulators include physics engines which model the forces in the virtual world. Physics engines allow you to, for example, create a ball which will fall to the ground and bounce in a “realistic” way.
Physics are necessary for some types of robot simulation; for example, when testing algorithms for advanced grasp planners, walking robot simulation, and stair climbing. However, using physics comes at a cost — it’s a pain in the neck! I can’t tell you how many hours I’ve spent trying to “get the physics to work” instead of doing the robot programming itself.
For almost all OLP applications, realistic physics is just not necessary and it’s not worth the headache. For example, you just want to be able to easily program the robot to pick up a ball and place it on a table. You don’t care how realistically the ball bounces when it hits the tabletop.
Even when physics is necessary, research has shown that less accurate physics engines can have better performance than realistic physics for some robot applications.
2. Advanced Surface Modeling
Surface modeling is only really important when you’re making a computer game, product demo, or a CGI movie. It allows graphic designers to add realistic surfaces and textures onto their models, which improves the level of realism. However, this is purely an aesthetic feature. For robot simulations, it’s rarely worth the bother.
With offline programming, we don’t really care how realistic the models look. It’s sometimes helpful to be able to choose the color of objects — so that we can differentiate between them — but that’s about as far as it goes.
3. Shadows and complex lighting
A similar feature which does not make sense for offline programming is advanced lighting. While shadows and complex lighting setups might make the virtual scene look more appealing to us, it doesn’t help with the performance of the robot program.
You might think that lighting is important when are using robot vision in your application. However, there’s a problem with this: it’s very difficult to reliably test a vision setup in a simulator because the real world is always more (visually) messy than a virtual world. A much better solution is to make a simple, physical test with your vision sensor and test it out in the real environment.
4. High-Definition Rendering
Rendering is the process of turning a rough virtual scene into a pretty image or video. It’s most often used when you’re creating marketing materials for products which do not yet exist. A CAD package or 3D modeling software can render the model into a scene, complete with backgrounds, lighting, and surface modeling.
For offline programming, this level of realism just doesn’t make sense. It provides nothing to the functionality of your robot program and requires you to do a lot of unnecessary work (e.g. setting up the lighting, choosing surfaces and backgrounds, etc).
If you want to show your robot program to clients or colleagues, you can easily export it as a video simulation which demonstrates the necessary functionality without all the fancy extras.
5. Advanced CAD/CAM Functionality
An OLP package is not a Computer Aided Design or Manufacture (CAD/CAM) package. In fact, if you find software which claims to do both of these tasks equally well, be suspicious.
Gone are the days of the single software package which does absolutely everything. These days, the best software is highly targeted at a particular set of functionalities. With OLP, this functionality is programming robots.
Of course, you will also want your OLP software to be able to interact well with your favorite CAD/CAM software. That’s why interoperability is vital. Find out more about this in the post Don’t Want to Change Everything to Use Robots? Well, Don’t!
Which features do you think RoboDK is missing? Tell us in the comments below or join the discussion on LinkedIn, Twitter, Facebook, Instagram or in the RoboDK Forum.
