http://www.perlmonks.org?node_id=100814


in reply to robotic laser welder

I think it's cool, especially since I would not have expected (well until Inline::C) that Perl would be fast enough to run a welding robot. Could you please explain this aspect of your project?

I am interested because I know some people who build what could be called 3D printers.. solid objects are built by laying down a thin layer of fine powder and fusing with a laser, then laying down another layer. Custom Windows software is used, and it might be interesting if we could automate all this with standardized, network-aware software.

I am interested to know if you use Perl in the modelling phase, in the building of a command list, or in realtime control, and what kind of limitations you have seen. Do you use any straight C (Inline or other driver software) or is it pure Perl? What does Perl enable you to do? Is quicker prototyping/testing better? Have you been able to enhance the system by including other Perl modules?

The bass thing is neat. Thanks for the info.

Replies are listed 'Best First'.
Re: Re: robotic laser welder
by ginseng (Pilgrim) on Jul 30, 2001 at 13:34 UTC
    I love those laser prototypers! soo cooool...

    The guts of this system is really a motion controller, which has a CPU and poor excuse for a programming environment for control, and a digital signal processor that takes care of motion control. The former is used for monitoring high speed inputs (like the anti-tiedown/anti-reset logic, and the joystick control during setup mode) and the latter puts the laser in the right place at the right time. The Perl programs merely make suggestions to the DSP on what the right place & time may be...

    So the architecture is like this:

    • The motion controller takes care of positioning and some high-speed input requirements.
    • It communicates via Ethernet to a Dell PowerEdge server, running OpenBSD.
    • The server runs several Perl programs:
      • The main daemon establishes communication with the motion controller, and keeps track of whole bunch of predefined macros for "canned" moves. (I have learned to love regex.) It also does some rudimentary machine control, like watching for parts to be in position, and then running another Perl program, to wit:
      • The path generation program calculates the location of the can in space, and generates the motion controller commands to follow that path (and pulse the laser appropriately). It gets its configuration information from a file created by:
      • The operator interface program gives the operator the appearance of control, while mostly milking him or her for some setup data, and maximum productivity. This is a Curses application.
    • If there had been more time, we had a hand-held serial terminal for the operator. But shipping interfered with production, so it went out with a monitor and a keyboard ;)

    Parts of the program are ridiculously slow. The path generator puts out around 500 - 750 lines to STDOUT (slurped up by the main daemon; see Exec Fork Trick for how I did that) and takes about 20 seconds to calculate. I used three cartesian systems (one for the machine as a whole, one for each of the two tools), and a pair of polar systems (because the tools rotate.) There are multiple translations back and forth. (Actually, there are hundreds, just to find the path around the corner radii.) If I had remembered enough trig, I probably could have avoided tons of this, and significantly improved the efficiency of that program.

    My original intent was to write the system in C, not Perl. (Yeah, --me on that point alone. I deserve it.) Various production delays brought me to consider Perl, though I had scarsely written more than 100 lines of it. It was still a good idea, and I started by writing everything in Perl for a few weeks before starting this project. (My prototyping on this project was implementing the MP3 Server and building an XMMS Alarm Clock, among other things. Not exactly traditional prototyping methods, but we still managed to get the job out the door.)

    The biggest advantage to using Perl was probably the speed of development, even if my inexperience with Perl worked against me. Honestly, I found it much easier to debug and troubleshoot as well, and having such an incredible regular expression engine was valuable.

    This application was not a terrifically difficult "real-time" application, though. Had I needed deterministic latencies and preemptive multitasking, I probably would have had to write it in C. I also would not have used OpenBSD -- I'd probably have built a LinuxPLC box instead, and possible even RTLinux or one of the similar projects instead. I'm glad I didn't need to. I like OpenBSD, and I like Perl.

    A note on why this source got closed, despite my best arguments. My customer has built machines that went to Taiwan. His company (before he started the company I was working with on this project) took 6 months to build and program one of their machines, and he went to start it up. One month later the customer had trouble with the machine, and he was back for a service call. In that short month, he discovered, they had built a fully-functional duplicate of the machine, and programmed it - without documentation beyond the basics. Given that experience, he's a little shy about releasing the code for a project that is transparently understandable from watching the operation. Only the complexity of the code would prevent a knock-off. (Preventing a potential competitor from reading the code is a delay, not a preventative measure.)

    This also gave rise to the introduction of OpenBSD to the application. Aside from the security advantages over Windows, using a UNIX-like operating system in this application was a no-brainer and an excellent choice. This gives us all kinds of potential for remote administration, plus a network gateway to the motion controller. We can do even firmware upgrades across the 'Net. Bonus. (Reminds me of the Cisco VoIP products running Win2k. They're getting infected with the Code Red virus. Hah.)

    Well, that's my 4:30 AM overview. Hope it answers the question. In short, this project seriously sold me on the advantages of Perl.

Re: Re: robotic laser welder
by bikeNomad (Priest) on Jul 30, 2001 at 21:22 UTC
    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.

      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.

Re: Re: robotic laser welder
by Chrisf (Friar) on Jul 31, 2001 at 06:55 UTC
    Damn..... that does sound cool.

    I just had to say that :-)
      Amen

      ----
      Zak