Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

Re: Re: robotic laser welder

by bikeNomad (Priest)
on Jul 30, 2001 at 21:22 UTC ( #100906=note: print w/ replies, xml ) Need Help??


in reply to Re: robotic laser welder
in thread robotic laser welder

You might be surprised at the lack of speed required to control robots. I've done a lot of robotics work for semiconductor fab tools (in Smalltalk, not Perl, but the same ideas would work for Perl). Many semiconductor robots have serial port inputs with relatively high-level command sets. Like, for instance, go to pre-taught position#1. This doesn't take too much speed, as long as the next command comes pretty soon afterwards. Remember that motions in the real world often take in excess of a second to perform; even Perl can keep up with this! Likewise for robotic welding (I've programmed multi-axis TIG welding robots before too); a typical general-purpose multi-axis robot will also take a high-level command over a serial port.

What's described here is a layer below that, where the coordinate transforms are being done in Perl, and the various motors are being controlled by a separate motion controller (you have synchronization issues whenever you have to control multiple motors at the same time: if you don't stop and start them at the same time, your motion path gets pretty wierd).

But Perl can even work for lower-level systems (though you may need to use Inline to talk to the hardware registers). For instance, there are ISA-bus motion controller cards that use motor controller chips like the LM629. You just tell these chips how you want the motor to run, and then you tell all the chips to start up simultaneously.


Comment on Re: Re: robotic laser welder
Re: Re: Re: robotic laser welder
by ginseng (Pilgrim) on Jul 31, 2001 at 00:09 UTC
    Indeed, BikeNomad. My favorite robot is from STRobotics in England and Russia (um, Ekatarenaburg, I forget. Is that Ukraine?) Their stuff is designed on the Z8000, and runs a language they call RoboForth. It's a pretty fair implementation of Forth, and that is one of my all-time favorite programming languages. (My opinion: Forth is to assembly what Perl is to C.)

    As this application went, I didn't have a robot controller that would take nice high level commands like "Go to position #1" or "Go through your canned routine #7", but I did have a motion control framework to work within, like "Here are a few hundred points for four axes. Pass through them all at these speeds, and interpolate all of the linear positions." In effect, their programming language was halfway between assembly and basic, or kind of a non-graphical PLC ladder logic, if you've ever seen that. (On the old AutomationDirect software, you could see what the graphics boiled down to. I think the A-B PLC-150 software was the same way.)

    My references to maybe needing C and an RT operating system stem from the lower level question. What if I were building a robot in Perl, not implementing one on a motion controller? We would need the speed. Actually, we probably would need more speed than that...a DSP is really the most appropriate tool. Keeping the axes synchronized is not just a matter of starting them all at the same time, though if you have a good PID (or other) control routine running, it helps :) What needs to happen is that each axis needs to be tied to the position of the other axes. These requires continuously knowing the encoder position of each motor, and making sure that the others are keeping up. Really, I guess it's also the first two derivatives of that, watching position, speed and acceleration of a master axis, and tying slave axes to it. While the math can be done (and pretty darn quick) on a general purpose CPU, DSP's are optimized for this. (Since I'm onto analogies, a DSP is to math functions what Perl is to text processing.)

    But I've never programmed one of those, though I guess it's much like most other embedded applications. Like most people, if I don't know the right tool, I tend to use the wrong one ;) So my inclination is to suggest C and RTLinux, even if they are less than perfect for the job.

    I'd like to use Perl for more low level work, controlling hardware registers and talking directly to real world stuff. (I think of the real world as things that move and have mass, at least more mass than electrons alone ;) Alas, my other life is interfering, and I will be focusing on the 'Net instead. I've given up the control geek lifestyle to build my ISP business. The next low-level control project is probably not going to happen until I integrate a PC into my 1973 VW camper-bus, or go buy a Unimog and play with its electricals.

      With the right controller hardware, you can do robotics with Perl. The LM629 chip I mentioned implements a PID control algorithm. I've found that two or three of these work fine for robotics with multiple motors running simultaneously, even from a high-level language. You just program them so that their trapezoids are the same length and have the same duration of acceleration, then start them simultaneously (you'll probably want hardware that's set up for simultaneous starting).

      More and more, it doesn't make sense to have a single central program/processor running everything from low-level control (motors and limit switches) to high-level control (scheduling, receiving commands from the network, UI). Processors (and specialized controllers like the LM629) are cheap; they should be put into hardware that needs them. It almost never makes sense to have a general purpose computer controlling motor hardware directly (i.e. reading encoders and controlling PWM or steps). You want an embedded system that can present a reasonably high-level interface (like the one that was described in the original post, or like my semiconductor machine robots).

      Where Perl is somewhat weak for robotics and other embedded systems work (IMO) is in its lack of threading, and in its lack of a standard idiom for handling exceptions. With die/eval you have one option: to abort the operation (you can, of course, retry the whole eval block if you want). Other languages offer better control on exceptions.

      For instance, Smalltalk allows you to retry the method call that threw the exception (as opposed to the whole block in Perl), or to resume it as if nothing had happened. This has been helpful in my embedded systems work for handling robot errors like timeouts, and in situations where there could be some chance of human-assisted error recovery.

        I agree wholeheartedly. It looks like the LM629 will move the positional control layer down into hardware, and works like a specialized DSP. Ideal. I'm sure the application is becoming pervasive enough to justify high volume production of specialized silicon.

        I'm all in favor of offloading to coprocessors. It's been a fascination for me since reading the thesis that described the Connection Machine in 1986, and realizing that two or three processors are probably more within reach for me than 65,536 of them ;) I still want a i960 coprocessor card, even though i no longer have a computer that is slower than the i960...

        The problem is, IMO, that the interesting work is being done on the coprocessor, not on the glue program. If Perl is simply connecting the user to the hardware, the program might be mundane. (I'm the same way with Internet programming. I want to implement business logic, not build interfaces ;)

        I haven't gotten into exception handling greatly, but what's wrong with using {..} or do {..} rather than dying? Ah, I see...you may be re-eval'ing the whole block, as you said. Yes, I see...no way to say, handle this exception this way, as we would with signal handling. (Can one define new signals?)

        Continuing as if nothing happened and relying on the operator to extricate the situation is not too trying, though. I don't know how Smalltalk handles that, but it doesn't seem to need a special code construct, to me. But I am not a language designer, just a code mechanic.

        You seem to have the skills and tools to get into hardware, right? I've done that at jobs, generally where I had someone nearby with hardware expertise to watch over my shoulder. I've prototyped PIC systems and the like (8051, etc.) and designed some circuit boards, but I really don't like hardware. It's one of those things that gets my hair falling out. (Like the week I spent trying to figure out a software bug that only happened when the flourescent lights were off...turned out to be a UV-EEPROM without it's window cover on...I didn't clear that particular register while initializing the program.) At any rate, I envy people who are good at hardware, and have put together good tools for working with it. They aren't stuck (like me) with making do with what's at hand.

        'Course, if I really made do with what's at hand, I'd probably take my old EISA RAID controller and have fun with it's coprocessor, complete with a meg of memory...

        Has anybody tried circular profiling with LM629?

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://100906]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (10)
As of 2014-09-02 09:11 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite cookbook is:










    Results (20 votes), past polls