I won't include all of the (mostly mundane) code,
but I recently finished a Perl project that provided
control logic for a robotic laser welder...
What is a robotic laser welder? In this case it's a four
axis robot for welding small items with a 14 joule
laser. The main controller is an Dell 1U rackmount, running
OpenBSD, talking to a motion/IO controller.
In the spirit of recursion though, this also made for a
"Cool Uses for Cool Uses for Perl", as we tested the entire
device (sans laser-light-show) as a speaker for an electric
bass guitar... check out
this link to see my buddy Xam playing it as a $ 6-figure
amplifier. (Explanation - By controlling position of the
axes based on an amplified bass guitar input, we made the
entire device reverberate throughout the shop. The video has
a decent audio track. We also tried hooking it to a Diamond Rio,
not shown, but the frequency response range was much better
suited to the bass.)
If you're disposed to checking it out, enjoy. I certainly
enjoyed using Perl for this cool application.
(redmist) Re: robotic laser welder
by redmist (Deacon) on Jul 27, 2001 at 13:46 UTC
|
That sounds like it would be awesome code! Or at least not mundane. Pretty please with sugar and sweet stuff on top post it. Can you tell us more about the kind of interface? How was it implemented with OBSD? Were there any bugs initially that led to *ahem* interesting results? Robots rule! Please release the source!
redmist
Purple Monkey Dishwasher
| [reply] |
|
Unfortunately, while the code is mine to reuse, it is not
mine to distribute, and I can not post it in toto. But you
probably wouldn't want that ;) It's four programs, each
about a thousand lines, and the math (actually, geometry)
behind the path generation is hard to follow (involving
three cartesian systems and two polar systems, and multiple
translations between them.)
Sorry, don't mean to suggest it's not of interest or too
hard to understand, 'cause neither are probably true, but I
still couldn't post it all...and being a huge open source bigot
myself, it's not easy for me to say that.
| [reply] |
|
Oh how the Gods have frowned upon me on this dark day. A thirst nearly quenched, only made worse by proximity to the panacea code. A thousand years in the darkest dungeon have I been through without my beloved robotcode, and an eternity of torture and death awaits now that my one true chance for ultimate liberation through the code of robot has gone.
I can smell the sulfur and corpses already. Decomposing jaws mouthing, "ro...bot...code. Want...robot...code." A metaphor for myself and my needs. I can feel the pain, the pure, unadulterated pain of living without the robot code. I can hear the screams of a thousand lost souls in the aether crying for robotcode.
redmist
Purple Monkey Dishwasher
| [reply] |
|
|
|
Re: robotic laser welder
by mattr (Curate) on Jul 30, 2001 at 12:37 UTC
|
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. | [reply] |
|
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.
| [reply] |
|
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.
| [reply] |
|
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.
| [reply] |
|
|
|
|
|
Damn..... that does sound cool.
I just had to say that :-)
| [reply] |
|
| [reply] |
Re: robotic laser welder
by mattr (Curate) on Jul 31, 2001 at 13:48 UTC
|
Thank you very much (everyone) for all the interesting
comments!
I guess I don't have the same problem with the customer
building a new machine since they cost a quarter mil ($)
each, but since it is very highly tweaked already and the
only moving parts are the powder bucket and laser head,
I think if Perl is used it will probably be mainly in
developing data models which will get crunched by the
preprocessor, and maybe in a web site that handles requests.
It would be very cool though if we could have a more
realistic 3D display on the terminal but not
so sure it is needed right now.
Your links ginseng are very interesting, especially
I noticed rtlinux has gotten more mature it seems, and the
puffin page (Mat project on sourceforge) mentions that
you can have different processes written in different
languages.
I still am pretty interested though in seeing if a partly
Perl system is fast enough to write to a rotating mirror.
Not for the system mentioned above, for a simple rgb
projector setup. Another friend (a DJ)
has a powerful laser like that used in clubs but it is
mainly powered by a dedicated PCI card and an already
large library of (C,windows) programs but I'll have to
keep thinking about what is possible.
Thanks again for a very interesting post. | [reply] |
Re: robotic laser welder
by Anonymous Monk on Jul 31, 2001 at 08:42 UTC
|
Ginseng what on earth is the 500+ Mb avi sitting next to Xam's bass solo?
peas,
Jerrygarciuh | [reply] |
Re: robotic laser welder
by theorbtwo (Prior) on Jun 30, 2002 at 04:26 UTC
|
I'm confused -- you have video of using a robotic laser welder as an audio amp... and don't show a robitic laser welder is in! I demand that you shoot another video! <G>
We are using here a powerful strategy of synthesis: wishful thinking. -- The Wizard Book
| [reply] |
A reply falls below the community's threshold of quality. You may see it by logging in. |
|
|