[Robotgroup] Intro to RG

Tue Jan 23 07:24:41 PST 2007

Hi Jay,

I missed meeting you at the last RG meeting. I'm usually a late arrival on Thursdays due to other commitments. I'm the person Vern asked for an estimate on doing a custom PCB for interfacing the Soundgin with a Basic Stamp. If I knew a bit more about the Lego NXT interface, I'd consider looking into trying the Soundgin adapter you mentioned for that too.

I looked at the ARM Automation site yesterday after seeing your post on Soundgin. Is ARM Automation related to ARM microprocessors?

I'm interested in learning some more about the sensors used on actual robot work cells as opposed to those used on small mobile robots. I'd be willing to discuss a time of flight sensor.

Paul Atkinson

----- Original Message ----
From: Jay Mackey <jay.mackey at armautomation.com>
To: Robot Group <robotgroup at puremagic.com>
Sent: Monday, January 22, 2007 2:27:52 PM
Subject: [Robotgroup] Intro to RG

Hi group,

I visited the meeting on Jan 18.

I live out past Dripping Springs and work at ARM Automation, halfway between
Drippin' and Oak Hill.  We do work for mostly large manufacturing companies
that require automation, usually industrial robotic automation.  However,
the company has produced its own servo motor design called the DISC motor,
which incorporates the servo controls in a module that attaches directly to
the motor resulting in a clean cylindrical motor/controller combo, which has
been used in many different ARM applications and sold to third-party
manufacturer as well.  You can see some of the things we do at ARM on
www.armautomation.com.  (I'm the guy in the green shirts on both the
Capabilities and Solutions pages.)

I've been with the company for three years now, helping produce robotic
workcells, using mostly Fanuc robots.  But I also did a test system with an
Epson robot for a major computer manufacturer that inserted two DIMM RAM
modules into the memory slots on a motherboard inside an open case.  The
robot could pick the memory from a tray and place it precisely in a slot
with virtually no tolerance for position error.  The computer chassis could
be turned to a random orientation.  The Epson has a Machine Vision option,
and we used three cameras with the Epson to find the locations and
orientations of the memory modules, computer chassis, and the slots inside
the chassis.  One camera looked down from above the chassis position to
determine the chassis location/orientation, and two small cameras were
mounted on the robot end-effector that were used to find the precise
location of the memory module in the tray, and also to refine the location
data on the memory slots on the motherboard.  This setup could pick and
place a memory module at a rate of almost once every six seconds.  The
design would allow for picking two memory modules at a time, and then
placing two modules in quick succession.

Before working for ARM, I was with a Dallas automation company called
Spectra Technologies for over ten years, & would probably still be there,
but they overextended themselves and have gone out of business.  I was
involved with some light custom board design there, as well as various
robotics and custom automation projects, and a lot of machine vision over
the years.  On these projects I do the electrical controls design and
documentation, or the programming, or both, depending on the size of the
project and the time involved.

Automation companies tend to be small, and it is much preferred that
employees be 'versatile', so I have gotten to learn lots of different
things:  PC programming with .Net, several different proprietary programming
systems only encountered in the automation field, board design of custom
DeviceNet-enabled input/output PCBs, lots of electrical controls design
using AutoCAD, some light 3D mechanical design, various kinds of motion
control design and programming, lots of different varieties of Machine
Vision, several different industrial robots, from roll-your-own 2-axis
Cartesian robots, to 4-axis SCARA arms, to 6-axis fully-articulated arms
with greater than 2 and 3 meter radius reaches.  I also do the proposal
graphics for our sales guy.  When we do proposals for robotic workcells, we
sometimes have to do some simulation beforehand using high-end 3D software
purchased from the robot manufacturer that can tell us if a robot model can
reach everything, and also what its cycle time will be, give or take a few
tenths of a second.  Sometimes, we don't need a full simulation with video,
but we do need to show a moderately accurate layout of the proposed workcell
with robots, conveyors, etc. and how it might fit into existing floor-space.
I CAD it up in Google SketchUp 6 PRO, because it can import models, such as
the robot, and because it is very fast to build various conveyor or safety
fence components, and then reuse those components on new proposals.

I only had two years of Computer Science, back in '83-'85, for whatever that
is worth given the tech available back then, and I never graduated.  I was
blessed to get the job at Spectra in about '93, and learned most everything
I know on the job.  So, I have some very broad expertise, but it is fairly
shallow in many areas.  I'm certain that the RG has individuals who are more
experienced in any specific field, such as board-level electrical design, or
PC or controller programming, but I can probably compete with almost anyone
on general versatility.  ;)  (I also created the ARM website.  My personal
hobby time is probably spent more on 3D and 2D graphics.  I own Photoshop
and some fairly high-end 3D modeling, rendering, and animation apps, as well
as having access to SolidWorks and PRO/E at work.)

BTW, electrical controls design in the factory automation field involves
designing a system of systems, usually.  A typical Robotic Workcell will
have the robot controller, which might require as much as 30 Amps of 480VAC,
so there is some moderately high-power distribution design involved.
Usually, much of the components & systems that are required in a workcell
run off of 24VDC and maybe some 120VAC, so it is possible that a medium
sized transformer will be required.  Sometimes we only need a 10 or 20 Amp
24VDC power supply that uses 480VAC 3-phase as an input, so no 120VAC
transformer is required, or else the plant provides both 480VAC and 120VAC.
In either case, with a robotic workcell, the power distribution and
protection circuits tend to be fairly involved, and have to meet local and
national electrical codes.  With robots, an advanced safety system is always
required.  We tend to use a programmable dual-redundant safety-monitoring
controller that is almost as sophisticated as the main controllers.  A
safety controller is used to monitor dual-redundant circuits to which safety
switches, emergency-stops, light curtains, safety mats, and other devices
are connected.  When everything is in a 'safe' condition, then the safety
controller 'authorizes' system startup.  There are usually motion
controllers involved in addition to the robot itself.  These motion
controllers could be AC motor drives or servo drives of some type.  There is
also always some kind of input/output system, which could be DeviceNet,
Ethernet-based, or some other I-O system.  Sensors and actuators located in
various places throughout the workcell have to get their signals to/from the
robot controller, or whatever high level controller is being used to control
the overall function of the workcell.  An operator interface is usually
required, which may itself be an industrial computer with flat-panel touch
screen that is programmed with a highly customized interface.  Finally, if
the workcell requires Machine Vision, there is usually another standalone
computer that has an image-capture card in it with one or more cameras
connected to it.  The vision computer, robot controller, & operator
interface computer all communicate over Ethernet, so that is one more system
to spec and integrate into the workcell.  Depending on the complexity of the
task, another controller may be required to control conveyors or secondary
systems.  Usually one person, sometimes me, does all the programming for
everything in the workcell, which can include a robot controller,
programmable motor drives, programmable safety controller, a programmable
logic controller or embedded PC, operator interface computer, and machine
vision computer.  Over the past three years, ARM has had one to three
projects of this complexity each year.

I've owned a Lego RCX 1.0 since they first came out, and just bought a NXT,
but haven't received it yet (maybe today).  Most of my personal efforts in
hobby robotics will be using the NXT, or a laptop or pocketPC and the NXT
combined in various ways.  Given my experience with machine vision, I have a
strong desire to integrate autonomous camera-based navigation into a NXT/PC
setup.  The vision software has to run on a modern PC to be effective, or
minimally on a processor 10 times as fast as the NXT with about 20 times the
memory.

My biggest disappointment in robotics, besides the failure of AI proponents
to deliver on almost any promise ever made, is the expense of decent
sensing.  Commerical laser scanning capable of anything close to real-time
scanning cost thousands of dollars, and commercial camera-based guidance
(machine vision) is the same (it used to be tens of thousands not that long
ago).  However, there are now third-party companies providing some
interesting sensors for the NXT, and I'm hoping there are some open-source
machine vision code libraries that turn out to be useful.  I'm wondering if
it is now economical to make a home-grown time-of-flight laser distance
sensor?  

Jay Mackey
Controls Engineer
ARM Automation, Inc.
Austin, TX

_______________________________________________
Robotgroup mailing list
Robotgroup at puremagic.com
http://lists.puremagic.com/cgi-bin/mailman/listinfo/robotgroup

____________________________________________________________________________________
Don't get soaked.  Take a quick peak at the forecast
with the Yahoo! Search weather shortcut.
http://tools.search.yahoo.com/shortcuts/#loc_weather