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


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

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.