What's new
What's new

Learning to program robotic arms?

Graduate school. It is beyond the scope of a basic Engineering degree program.

Everybody else buys pre-programmed arms and has an expensive relationship with their service and software providers.
 
I think it depends on manufacturer. The only one I know is Staubli which uses their own language (it really isn't that different from C) The tool manufactures I have worked with like to have users pay for training courses or books to learn how to use their systems.
 
For basic motions you can figure it out on your own with the manual, but it's much faster and you'll learn much more by taking a course offered by the manufacturer. It's money well spent. Think of it this way - if your time is billed at $150/hour then a $1500 training class is going to pay for itself in the first 10 hours you spend doing productive work instead of fumbling around. Although personally, I think you'll get more out of the class by fumbling around for awhile before the class so you go into it with some understanding of what you need to learn. You'll be able to ask the instructor questions more specific to your application.
 
What? No it isn't graduate level. We did robot arms, programming, translation and rotation matrices and inverse kinematics, from scratch, all in undergrad. In one class.

And plenty of people without degrees at all program them. They're really not hard, it is just a set of languages closer to application programming than G code. And having a strong math background and sense of geometry helps.

But really. Not that hard. At all.
 
Making the arm go from here to there is actually the easiest part of it. It's integration with vision, local coordinate systems, tool offset, arm offsets, interaction with I/O, and building the user interface are where the complexity lies.
 
Kuka has an option where you can control it with a Sinumerik 840D . . . then G-Code is fair game.

Agreed, you don't need an advanced degree. And we have done a number of robot kinematic arrangements in years past with a Delta Tau controller including SCARA, Stewart Platform, and CHAOS stages . . . but bang for the buck is to take the OEM programming courses and use a standard / off-the-shelf robot.
 
When a previous employer bought our first robot, I had about 5 minutes of "how-to" at the robot dealer/integrator with the pendant, just to "see" how to jog the robot around... That was it - no previous experience beyond those 5 minutes...

And then, it was off to a 4-day class at Fanuc. At the end of it, I felt like I could take over the world. Programming, I/O, logic, motion, data registers etc. were super easy. I was impressed at how simple & intuitive they made it for the users.

I would concur that the more difficult part would be integrating the robot into other machines, but I would suspect anyone with a background in electrical/controls would have no issue at all with this.

If you can program/operate a CNC, a robot should be 4-5 times easier to program/operate.
 
Programming is programming, the only major difference between languages is syntax and functionality. Logic doesn't really change irregardless of the language used. If you can program macro G-code, you can program a robot once you learn the syntax of the specific language. It's akin to learning a different spoken language....... what you are trying to say is exactly the same (meaning), it's just how you actually say it is different.
 
Programming is programming, the only major difference between languages is syntax and functionality.

Broadly incorrect.



That language overview doesn't touch on reaction to stimuli.

Complete robot context includes both language and behaviour.

How many threads (lightweight processes) can you program simultaneously in G-code? You can't even recurse.
 
jCandlish . . .

We have programmed quite a number of specialty CNC machines (both on the PLC side and with special function calls combined with G-Code macros and M-Codes) that react to real time data with respect to cutting forces, torques, vision, etc. to dynamically alter destinations on the fly, cutting speeds, and a host of other things. We have linked up to 3 840D's together to manage simultaneous motion to 55-Axes of control.

With regard to more of a pure motion control application we are doing a pico-meter (yes, I completely understand how small this is) . . . resolution stage right now where we are sneaking up on the edge of electron orbits using a multi-threaded Power PC based controller with user written servo filter and an incredible array of multi-threaded logic to finesse following error down to the fractional nano meter level.

All that and I still have no idea what your graphic is all about.
 
All that and I still have no idea what your graphic is all about.

Then you are fortunate to have someone on staff to solve those programming problems for you, or you have a good co-operative and flexible relationship with your control supplier.

There is a hierarchy of algorithm capability based upon system architecture. The bubbles in the picture I posted are regions of distinct capabilities. Beyond simple procedure following (a tape machine where the tape is limited to motion in one direction only), it is essential that functions be able to call themselves. Functions that call themselves are not possible to program with G or M codes.

So your supplier is selling you that capability behind the vendor curtain.

I don't believe that you are doing pico-meter motion. If you're getting that resolution you're using an optical lever. Pico-meter sensing and pico-meter motion are two different things.

I did 10's of nanometers motion 25 years ago, with piezo stearing stacks for quality control of optical gyroscopes when they where prisms, before they transitioned to fiber loops.

I get tired of people that don't understand the fundamentals, and then wonder why stuff doesn't work.

Lets consider your 55 simultaneous axis claim.

If they are truly simultaneous then the 55th axis can be waiting on information from any of the other 54 axis. Likewise the 54th axis can be waiting on the outcome of the remaining 53 axis, and so on.

The set of possibilities that an interrupt would have to service would then have 55! or
1.2696403e+73 elements. That state space is absurdly large. Therefore your 55 axis cannot be truly independent. If you look at the Venn diagram of your 55 axis you may find that there are in fact 11 disjoint regions each having 5 degrees of freedom. 5! == 120, which is a considerably smaller number than 55!. Now if your 11 disjoint regions have to co-operate simultaneously then there would be at most 5! * 11! possible states to consider. That would be 4790016000 states, a number of unique locations that you could consider holding in a computer memory. But again, I would suggest an analysis would show that 11! is further divisible into disjoint sets.

Following an error down to a fractional nano meter I would believe. The rest? No so much.
 
Well, I do believe in my statement. I do actually program both CNC's and robots. You didn't quote the "major differences are syntax and functionality" part of my response - Functionality being the key word there in regards to your response. However, in the context of the point I was trying to make, basic programming logic is pretty universal across many languages. What you do with that basic logic is application specific, but how you go about laying out the basic logic flow chart for what you want to do won't change much, given the same application across different languages. Irregardless of language, for any particular application there are basic logic steps that must be done in a certain order to come up with the result you want.

It's no different than basic math. Do you add and subtract before you multiply and divide or vice versa?

If I want to pick up a part with a robot, do I not need to make sure the gripper is in the open state first?
If it's not open, what do I do?
Once I've opened the gripper, do I not need to make sure the part is actually there to pick up?
Once I think I have picked it up, should I not verify that I actually did?

This type of basic programming logic would apply no matter what programming language you were using, or what application you were attempting to perform.
 
Why would any axis require knowledge of the other axes? Trajectories are defined in a trajectory generator which at best is limited to updating every 50usec or so and servo loops manage each axis with regard to following the trajectory with only warning and/or fatal following error monitored relative to process management.

Controllers like the Sinumerik send only coarse trajectory updates and the splining between points is managed at the drive level in accordance to whatever parametric constraints you define relative to position, velocity, accel, jerk and smoothing algorithms you employ. How does one get 55! interrupt servicing requirements? You better hop over the border and school the folks at Siemens and set them straight!

While I am not at liberty to discuss particulars regarding fine positioning at sub nanometer levels, we too are using piezo actuators in a variety of control modes both in harmonic operation for high speed moves as well as DC bending mode of the crystalline structure for fine positioning. The controller is a Power PMAC and despite my ignorance of the graphic . . . the user written filter operating at a loop closure rate of 20kHz wasn't nearly the challenge as the mechanical isolation, temperature control and environmental challenges associated with these stages.
 
If you can program/operate a CNC, a robot should be 4-5 times easier to program/operate.

Programming is programming, the only major difference between languages is syntax and functionality.

Tony, I don't know if your comment was directed at my post or not, but I want to elaborate on what I said, as it may be helpful to others...

One thing that Fanuc did with their robot programming, (and I would imagine that other robot manufacturers have done also,) is they've made the programming language/syntax AND the programming input method so much more intuitive for the user. At least at the pendant, when you write a program, the pendant/software basically prompts you to make choices to "fill in" the program line, based on what you've already selected for that line... So basically, you cannot enter anything but a logical syntax for that line of program code.

If you begin writing the line as a motion command, the pendant then prompts you to fill in the remaining information, and you can only choose motion-related arguments to complete that line.

(I hope I'm making sense here...)

Contrast that to a Fanuc/anyone elses' CNC language, where you can type in complete giberish, the editor will accept it, and then you only run into an issue once you try to execute the program. Not so on the robots... They only accept, what is acceptable in the writing/editing stage... This makes it much more intuitive & user-friendly at the pendant, and greatly reduces the learning curve to program/troubleshoot.

It's probably fair to call it the "Mazatrol" of the robot world, if that makes sense...
 
jCandlish,

I build control electronics from scratch. It's what we do. I also have no idea what you are on about with your graphic. If you're arguing that G code is a regular language, you've never sufficiently used the macros.

Are you by any chance a systems integrator with a vested interest in making people believe robot programming is esoteric?
 
Why would any axis require knowledge of the other axes? Trajectories are defined in a trajectory generator which at best is limited to updating every 50usec or so and servo loops manage each axis with regard to following the trajectory with only warning and/or fatal following error monitored relative to process management.

Because this:


Lagrange's Equations : The math behind dynamic coupled systems.

A computer animation of a coupled 2DPF dynamic system.

As you couple more joints the dynamics get even crazier. To hinder the propagation of chaotic motion off the shelf robotic systems use extreme damping factors and so are limited to a small fraction of their actual potential.

Controllers like the Sinumerik send only coarse trajectory updates and the splining between points is managed at the drive level in accordance to whatever parametric constraints you define relative to position, velocity, accel, jerk and smoothing algorithms you employ.

You have jsut descibed a cam follower.


How does one get 55! interrupt servicing requirements? You better hop over the border and school the folks at Siemens and set them straight!

There was a famous question on a West Point engineering examinaton "How do you erect a flagpole"? The correct answer to which is "You command 'Sargent, take some men and put up a flag'".

Forgive my insubordination, but your flagpole is not going to put up itself.
 
With all due respect, you fail to explain how any motion system is required to service interrupts on the order of axis count factorial.

Your undergraduate example of a coupled double pendulum is a math whizzes dream . . . yet apart from the value of learning math, the practical use for the kinematic arrangement is nada.

Practical application of computational mathematics needs to be combined with practical application of engineering such that the kinematic arrangements, linkage stiffness, actuator positioning bandwidth, and application of forces in line with Dynamic CG are each sorted out in addition to controller determinism associated with trajectory management as well as servo loop closure (involving feed forward and feedback terms as well as feedback and trajectory planning interpolation and anti-resonance features) . . . All of which can be managed nicely using (1) interrupt per GROUP of axes on a well designed system. Certainly there are opportunities to exploit other sources for interrupts (i.e. Registration inputs, position compare outputs for firing a laser, or strobing a line scan camera) . . .

Have you applied a Sinumerik 840D controller on a high axis count system with adaptive control or in a robotic (Kuka for instance) application? Have you applied a Delta Tau or ACS Motion Control in a robotic kinematic arrangement?

Here is a practical deployment of high performance motion control that has been copied by every major robot OEM in the last decade. I worked with this demo in 2005.

 
With all due respect...

Have you applied a Sinumerik 840D controller on a high axis count system with adaptive control or in a robotic (Kuka for instance) application? Have you applied a Delta Tau or ACS Motion Control in a robotic kinematic arrangement.

I worked for five years on the DARPA project that became BostonDynamics. In the early years we had six legged robots that were modelled on insect kinimatics. The computers where by Evans and Sutherland. We had access to our own chip fab for specialized processors. At that time I worked with the vision team and on the design of domain specific languages and compilers for real time robotics.

You video is not a dynamic system. All the motion is pre-solved from a small set of well constrained conditions. Just like tick-tack-toe the outcome is known before the game begins.

A rather more convincing video would have been this one, where the arm has to calculate a strategy.


With all due respect, having a fat account with Seimens confers no knowledge.
 
All the motion is pre-solved from a small set of well constrained conditions. Just like tick-tack-toe the outcome is known before the game begins.

Which covers 95% of all industrial robot applications . . . again, how many interrupts required for the ping pong playing robot?

Estimate trajectory based on two sequential images from a camera + basic Newtonian physics equations. Plan new trajectory and required contact angle with ball and execute. The robot knows no difference whether the trajectory is planned weeks in advance or 100msec in advance. No difference from the Delta robot example above in that respect (and no difference in the number of interrupts).

As for Dynamic balance control with the DARPA Dog . . . certainly there is a much higher computational requirement. But again, this thread is about industrial robots, not esoteric pack bots required to navigate terrain.
 








 
Back
Top