Posts by TygerDawg

    Does "machine tending" mean "machine tool load & unload"?


    If so, then the cycle time is probably a sufficiently-long duration. Then it may be possible to incorporate a place/re-position/re-grip sequence of steps that may mechanically give you the grip accuracy you need.

    IMHO I think that you are going to discover that there is no solution that meets the requirements of

    1. inexpensive
    2. easy to implement
    3. does not restrict working volume or access to workpieces
    4. is simple and fast to build a DIY system

    In my teaching episodes, I finally and reluctantly acknowledged that students will be students: clumsy, underskilled, impatient, refuse to read instructions, entitled to believe there are no consequences to their reckless actions, and they already know everything. They also think every machine should have the same ease-of-use and speed of reaction as an iPhone.


    My teaching method guides the students into the realization that robotic programming is a game of diligence, discipline, and patience. My teaching rigs all have surfaces of home-store semi-rigid foam insulation boards for the inevitable crashes and scrapes. My fundamentals teaching methodology is delivered in progressive steps using a flat table surface and a simple pointer tool:

    1. Rigorous skills development of motion mode and pendant fundamentals with practicum before proceeding to simple programming. Students must pass this 100% before moving on to demonstrate competency.
    2. Simple joint mode teaching of a path. The printed path contains linear & circular paths, but the first exercise is strictly non-oriented point-to-point joint moves. Tool-Z is not aligned perpendicular to the surface and this enhances understanding of coordinate systems and limits of joint mode teaching.
    3. Same path, but this time introduce Tool-Z perpendicular to surface for ease of teaching. Base mode and tool mode teaching used.
    4. Same path, but Tool-X (or Tool-Y) must now change orientation and follow the tangent of the path.
    5. Same path, but now linear & circular interpolation is introduced.
    6. Same path, but now variable speeds and variable tool tilt orientations are introduced.
    7. Same path, but now variable point accuracy is introduced (which is manifested in a zig-zag path segment).

    By the time the students get to Step 3 they are usually very competent and don't crash the robot. Usually. After Step 3, the remaining steps progress very rapidly. But crashes still occur in the foam board, so no damage is done.


    After students complete this sequence, we move on to more advanced 3D paths with integrated gripper & sensor tasks. Home-built fixtures and teaching objects are clamped on the foam board.


    If you are committed to a crash sensor, then here are a few ideas for DIY devices to ponder:

    • investigate "3D printed flexure robot gripper" for images of ideas of things already done
    • flexible strip resistors attached to flexible elements, then measure the voltage through the resistors to sense defection. I had a student develop this idea for sensing the bending position of a finger inside a glove. This would require electrical integration & programming.
    • 3D printed hacked copies of commercially available breakaway devices...maybe could be done. Maybe.
    • Tool-Z collision devices may be sufficient with spring-loaded designs.
    • Depending on how sophisticated your robot of choice is, there may be an opportunity to monitor the current of the wrist joint motors. Too much current = crash or collision. But this is a tricky software solution.

    And for another opinion...


    When I was involved with shipping arms all across North America, we had the following guidelines:

    • even if we specified an "air ride van" for shipping via truck with a softer ride, we always assumed the arm would be subject to severe road vibrations and those vibrations could possibly damage joint transmission gear teeth through repetitive stressing
    • arm would be securely bolted to machine base or heavy shipping pallet
    • arm would be tucked to minimize extended arm link mass that, when subject to road vibrations, would impart inertial loads on the links that would create unwanted torque and possibly damage gear teeth...tucking position was chosen to minimize this effect and we never sent arms in extended vertical configuration
    • we would always use some type of heavy padding in the tucked position...polyurethane foam, layers of heavy bubble-wrap, blue/pink house insulation foam, or even folded shipping blankets to help mitigate vibration-induced relative motion...the inertia would be absorbed through the housing element upon which it rested
    • Once a bunch of Valedictorians shipped our equipment during winter on an open flat bed trailer. The equipment arrived at the destination covered with winter salt spray and rusted over. After that, we sprayed preservative on all unpainted surfaces and shrink-wrapped everything

    It has been many years since I was deep into V+ language, but something doesn't seem correct with your code. Perhaps. Maybe. Possibly.


    Your method of calculating and using the INVERSE transform dif bothers me for some reason, and I cannot discern why (too many years ago). :sleeping_face:


    Establish a frame (user coord sys) in space with


    SET pallet = FRAME(loc.origin, loc.x.axis, loc.y.axis, loc.origin)


    This assumes that you taught the three frame locations properly (and taught with an accurate tool):

    • loc.origin is at the ORIGIN of the new frame
    • loc.x.axis is ON the X-AXIS of the new frame
    • loc.y.axis is somewhere in the positive X-Y plane of the new frame (not required to be ON the Y-AXIS of the frame, but is nice if it is)
    • fourth argument defines the location of the new frame origin
    • orientation of the three frame location points is irrelevant, only X, Y, Z are used to calculate the frame

    Do all of that, then your command to calculate a point relative to the new frame pallet is:


    SET pick = pallet:TRANS(x_offset, y_offset, z_offset)


    BUT it is critical to recognize that the new point pick has the orientation of the new frame pallet. That is, if your frame pallet Z-AXIS is pointing UP (e.g., towards the ceiling) and you desire to have your gripper Tool Coord Sys Z-AXIS pointing DOWN to the workpiece (e.g, towards the floor), then you must reverse the orientation.


    SET pick = pallet:TRANS(x_offset, y_offset, z_offset):TRANS( <either RX = 180, or RY = 180> )


    If frame pallet is taught with foresight, then the pallet Z-AXIS is pointed the direction you need for the tool Z-AXIS, you just have to adapt the X, Y, Z offsets to match your physical position.

    Consider doing searches for "how to build an electric go kart." Plenty of people have posted their attempts at building various vehicles with various levels of performance. Reviewing these posts may enlighten you to the world of mechanical engineering, mechatronics, and power transmission.


    Unsure why you need Raspberry Pi for this. But one of our local University Summer Engineering Camps does R-Pi programming with the MIT SCRATCH application for drag & drop R-Pi programming. Very easy for non-programmers.


    After review, you may choose to punt on the idea of a ZooWagon and change the project scope to a little ScooterBot to run around the house instead. I did not look, but I would suspect that there are 100's of free project plans for such kid-friendly projects. What you DON'T want to is be overly ambitious and discourage your kids from exploring this world because they were overwhelmed by complexity and got burned out.


    BTW: "pulling a wagon around...the zoo." That's called exercise, isn't it? Just sayin'. :winking_face:

    Is difficult to discern because there is no code provided.

    But it looks like this bug may be a logic error in your code, not so much the value of the rz.

    It has been many years since I touched a Stubby arm. But if I was programming this, I would establish a frame at the bottle. Then calculate some quantity of locations relative to that frame to provide the cap turning action. Execute those motions as a subroutine.


    You probably do not have the infinite-turn Joint6 option, so you must verify you start the turn at a good J6 location each time. Else you will accumulate J6 degrees.

    3000 mm height would be a challenge, given the vertical orientation of almost any extruder tool. Desiring a second hand robot suggests you possibly have a limited budget. Another challenge.


    For really BIG workpieces, I concur with HawkME on the gantry suggestion.


    I have seen Thermwood's Large Scale Additive Manufacturing machine up close. It is a large format gantry dispenser.

    Thermwood LSAM - Large Scale Additive Manufacturing


    It is used to dispense polymer structures and then machine the surfaces smooth. The machine uses Siemens PLC + CNC + servo drives. CNC path programs developed from CAD-CAM software (with additional customization). Servo drives for axis motion and large raw material melting extruder and smaller precision dispense extruder. Many man-years of engineering development work was done on this impressive beast. Very expensive. The last I heard (couple years ago), the US Government ordered so many LSAMs that Thermwood had a multi-year backlog.

    Robot specification sheet will specify mass moment of inertia MMI limits for Joint5 and Joint6, sometimes also Joint4.


    MMI values will specify the maximum torque the joint can handle by motion equation

    Torque = (MMI) x (Alpha).


    MMI is a directly related of your end effector mechanical design (mass, size, etc.). For example, SolidWorks used its Mass Properties function to calculate an end effector assembly model's MMI about specified axes.


    These MMI limit values are developed experimentally by the manufacturer for full payload & full speed motion in all configurations. Limits are due to motor torque and gear train design in order to meet repeatability specifications and survive the design service life. MMI values can be exceeded if speed is reduced. The reduction amount is not specified and usually determined by experimentation and experience.


    If the end of arm tool has any additional loading (such as forces applied to a milling cutter), then these forces will apply torques to the joints 5 & 6. These additional torques must be accounted for in the overall payload analysis.

    First things first: decide what it is you wish to teach your students.

    • fundamental exposure to robot technology
    • simple programming via Teach Pendant Programming TPP
    • more complex programming with structured language
    • simple pick & place or more complex path applications
    • systems integration (sensors, grippers, vision systems...)

    Simple: less time, effort, cost. Students get less learning and skills.

    Complex: more time, effort, cost. Students get more skills (but is more needed for High School?)


    Do your students already have some programming experience? Many do not. Nor have patience to read, study, and learn.


    My University / Engineering Technology labs use small Kawasaki units. Selected because of TPP +AND+ a very powerful & easy structured language together. Not terrible. But I only use TPP because my students are iPhone generation and don't know, and don't care, about structured language programming.


    I use RoboDK extensively in my course. I want students to know what is offline programming and also to help visualize 6DOF motion. Education license is what I have, minimal or no charge. Full function, six months. RDK is a very good package once you get over the learning curve. Can integrate Python programs for exotic actions, so can do "programming" with that.


    I wanted to evaluate an interesting new small lab scale 6-axis cobot from IGUS. But these products are new release this past Spring and I have not been able to get my hands on one yet. I ***think*** I got budgetary pricing of ~USD$9K (?) each at one time. They also have other types like gantry units.


    Skyefire mentioned Automation Studio. Fabulous product, insanely expensive for Academic use. I discovered a much less expensive alternative that I use in my classes, AUTOSIM PREMIUM from IRAI France. Less polished than AutoStudio or the equivalent FESTO software package, but very powerful anyway. I use it to teach students fundamentals of pneumatic circuits. My colleague uses it for hydraulics technology. It can also be used for PLC and industrial control circuit simulation.


    IRAI France also has an interesting "robot" simulator package for HighSchool or less called MIRANDA. You may find this interesting. Find link to it on their website.

    Many, many options available for this. Some may even be inexpensive.

    Search strings:

    • Cartesian robot or Cartesian actuator
    • XYZ Gantry or XYZ Gantry robot

    You need to define your maximum Z-axis height.

    Resolution is usually very high, but you need to define your needs.

    Motors used to drive the axes may cause noise problems depending upon your required traverse speeds.

    Concur.

    Staubli, Kuka, etc., have +World_X axis pointing forward from the robot.


    Kawa is rotated, +World_Y points forward from the robot.

    The Kawa World coord sys is like most milling machine tools: standing at a mill, +Z is UP, +X points to RIGHT, and +Y points FORWARD.


    Why they choose to do this and be inconsistent with the rest of the robot market is one of this life's great mysteries.


    On my small teaching robots, the Tool Flange coord sys is also a bit different. -Tool_Y points through the dowel pin. So +Tool_Y points opposite the dowel pin. :thinking_face:


    Kawa makes a nice robot system, but it has its quirks. Perhaps my assumption/assertion that Kawa is essentially a captive company for Toyota (and, to a lesser extent, Ford) is true. So they don't need be market-consistent or friendly.

    As a rule, I ***NEVER*** change the BASE of a robot. In my particular world, there are just too many problems that doing this could create. Especially if I change the BASE on an application and leave it for some other poor goombah to discover by accident. Most robot users/programmers do not understand transformations, so why leave these boobytraps out there for others to find?


    It's been many years, so please forgive if my transformation math is not exactly correct.

    If I remember correctly, SHIFT only applies to points in the BASE coordinate system.

    So the problem statement is:


    GIVEN:

    • arbitrary FRAME (call it: frame1) out in robot space taught in the default BASE robot coordinate system
    • an X-Y-Z pattern of points relative to frame1 (call them pt1 = frame1+TRANS(X1, Y1, Z1), pt2 = frame1+TRANS(X2, Y2, Z2), etc)

    FIND: I desire to move the points pt1, pt2, etc. to my dimensional specification within frame1 (sort of like using SHIFT inside frame1)


    SOLUTION:

    • OPTION1: Use TRANS function to calculate transformations within the frame1 coordinate system
      • command: pt1_new = frame1+TRANS(X1+X1_shift, X2+X2_shift, etc)
    • OPTION2: inverse the frame1 back to BASE and then use SHIFT within the BASE coordinate system
      • command: pt1_new = SHIFT(-frame1+pt1 BY X1, Y1, Z1)
        • ASSUMPTION: all of the various coordinate systems are aligned suitably. Else it may be necessary to change the order of the X, Y, Z components to get the desired changes

    Like I said, it has been many years and my command might be incorrect. I'd have to find a machine and test this and prove the correct trans math order. But I hope that you are understanding my intention.

    You may not ever resolve this. Reasons:

    • robots are repeatable, not accurate
    • path accuracy is a tubular tolerance zone around a mathematically perfect path definition and is dynamic based on arm configuration (varies all over the work volume)
    • a robot arm ain't a rigid CNC machine tool
    • servo parameters for individual motors may need tweaking to smooth out those bumps...not recommended
    • some arms are meant for carrying heavy loads point-to-point, not to follow a path

    Servo-tweaking:

    Years ago I was engaged in a project to resolve an out of tolerance condition on a Staubli robot path doing high-precision cutting. The application was analyzed. It showed that the path segment containing the tolerance deviation occurred when the J2 and J3 links went through an inflection point. The arm extended, paused, and then retracted. J2 & J3 opened, paused, then closed. Poof: consistent path tolerance deviation at the inflection point.


    How resolved: some really clever French servo programmer engineers "super-tuned" the servo parameters and sent to us a new servo parameter setting. Problem was corrected. But I hate solutions like that: implementing a "special" in the field and leaving it for the next poor b@st@ard to find.


    Wrong arm use:

    I was tasked with a dispensing job using a refurb BigYella spot welding beast. Dispensing path tolerance is very forgiving. Except this big arm had to move its J5 & J6 in wild gyrations as the dispensing gun traversed around a sharp corner. Angular accelerations were high for J5 & J6. Result: squiggly dispensing lines that could not be programmed out. Cause: big J5 & J6 gears made for carrying heavy payloads, not doing finesse work.

    Quote

    What is your budget?

    Cwany: We know the price range of this size of cobot and are prepared to commit the funds to it if it is the right choice for the organization. Why do you ask? Any Educational Discount that might be offereed doesn't really add up to much. None of the cobot manufacturers are cutting any substantive deals for Academia. I guess it is too early in the market cycle.


    Skye: thanks for the good insight. Familiar with UR arms, have seen the Fanuc CRX arms webpages. Was curious what BigYella had to offer that would discriminate their product from the herd. We already make the students sweat over another well-known industrial arm.


    Thank you for your replies.

    Anyone else have any insights to offer?

    It is not my intention to create a firestorm of opinions with this question.


    I have a situation that requires fast resolution.

    We have an opportunity to move on the purchase of ONE collaborative robot.

    It will be used for academic student teaching, student projects, and so on.


    Given the evolution of the cobot market so far (October 2021), which brand of robot would you purchase (5-10Kg-ish payload range) ?

    Brief reasons why would be nice.

    North American market only.

    You may be lucky enough to find some descriptive VAL3 language programming documentation available for no cost. Check the Staubli Customer Support site. Those are reference documents and not useful without training. Useful knowledge of programming VAL3 applications comes with a Staubli training course.

    Very interesting insight in this discussion. I know very little about Fanuc arms & programming. I'm looking to expand and as popular and pervasive as Fanuc robots are, I'm not sure now they would be a good fit for me.


    Quote

    Edge case, general industry, fancy programming is all I do.


    Would be cool if Fanuc developed a proper IDE.

    I've done plenty of that also. Just curious: what is your favorite choice of robot brand for this level of work?


    Don't know when VAL was introduced, but I used BOSCH robots (nowadays they don't exist anymore) in early 80's. They had a complete language with variables, structures lke "if then else" "switch case" and so on....<snip>...They had multitasking, and they where able to control multiple mechanics with one controller. What a pity that they didn't survive.

    You would very much like the Staubli VAL3 language and the integrated & powerful IDE Staubli Robotics Studio SRS. VAL3 does all of that. I haven't punched keys on SRS in years, but it was awesome for complex programming tasks.

    In the early 2000's I was approached by a large company for just this. The task was repair of turbine blades. The problem:

    • blades are very expensive so repair is preferable to new
    • blades undergo high-temperature loading during service. Blades demonstrate creep after being in service, and the distorted shape does not agree with the CAD model.
    • blade leading edges and tips erode during service. This produces random "scallops" and reduces surfaces that must be rebuilt by welding new material, then manually finishing (machining & grinding) to an aerodynamic profile.
    • The skilled crafts employees used to do this repair task were all approaching retirement age.

    My client wanted a magical software package capable of developing a repair strategy for a blade and create robot welding paths based on the repair requirement. I researched vision systems, scanning, CMM measurements, point clouds, and so on. I did not find any useful solution. As far as I knew at the time, the technological level of software was not sufficient to perform this adaptive/generative CAD task.


    Almost 20 years later, the technology level is probably suitable for this. Massive amounts of programming would probably be required. My guess is that it still does not exist on the market. Therefore it is still probably less costly to simply hire & train a new generation of craftspeople.

Advertising from our partners