Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5

Alignment of wrist axis for milling

#1
Hello!

I am setting up a milling work cell with my Staubli Rx90 (1994, CS7 w Adept MV19 controller).   

The issue I am having is I did a poor job of aligning the bracket I made to hold my router, and now it is about 2 degrees off.  (Wrist axis, joint 6).

How can i alter the position of this joint without the milling program (imported from Fusion) changing it back to it's slightly skewed position?). 

I can alter the joint position, as well as the tool position, but as soon as the milling program executes, it goes back to being askew.  

I thought about changing the calibration in my controller's software, but that is dicey as the robot is new very much packed away in a work cell, and I can no longer get the machine into it's regular "ready" position.  

I actually tried this and it was a disaster.  I had to physically move the robot out of the cell to fix it!  (Perhaps if I was better at this I wouldn't have screwed it up so badly, but my machine likes to calibrate itself standing upgright, and it can't do that where it is, as the ceiling is only 7' tall).  


Thanks,

David
#2
If I understood well, you want to adjust your tool and your TCP 2 degrees with respect to the robot flange. In this case, you can move the geometry of your tool (z rotation of 2 degrees). You can also offset your pose by 2 degrees (I recommend you to use the script formula on your TCP to recalculate it).

Can you provide your RDK project file? We can help you better.
#3
(03-28-2022, 09:49 AM)Albert Wrote: If I understood well, you want to adjust your tool and your TCP 2 degrees with respect to the robot flange. In this case, you can move the geometry of your tool (z rotation of 2 degrees). You can also offset your pose by 2 degrees (I recommend you to use the script formula on your TCP to recalculate it).

Can you provide your RDK project file? We can help you better.

Albert,

Thank you very much for your assistance!

I have spent the past 3 or 4 days trying different things attempting to get this to work.  In many cases, the simulation looked good, but I didn't understand the relationship between the tool I had added, it's orientation, and the tcp & move geometry command.  I had an idea of what I needed to change, but was unsure how to go about it.  

What I needed to do was play with the script formula (thank you for mentioning that, I wouldn't have known to use it) and I had to adjust another number on the Staubli/Mecademic option (I actually had two joints needing adjustment - 5 needed +1, 6 needed + 3.4.  

I think some sort of video or step by step guide to tool alignment would be very helpful, especially for those of us who don't have access to proper machine shops ;)    I tried out Jeremey's video about calibrating the TCP, but that didn't seem to do the trick, although I imagine it likely has made things more accurate for me.  

These problems may be very straighforward to someone who has an extensive background in this field, but from the perspective of a hands-on craftsperson (woodturner), I feel may be a good idea to create better documentation to assist those using your software. 

Looking forward to showing you what I plan to make with this wonderful software.  Here's a snapshot of my 1994 Staubli Rx90.  

Thanks to you and Jeremey for sorting this out for me!

David


Attached Files Thumbnail(s)
   

.rdk   fixed.rdk (Size: 1.12 MB / Downloads: 227)
#4
Thanks for your comments.
I certainly plan on creating such a tutorial in the future.

Jeremy
Find useful information about RoboDK and its features by visiting our Online Documentation and by watching tutorials on our Youtube Channel


#5

.rdk   non calibrated.rdk (Size: 5.95 MB / Downloads: 324)
[attachment=3184 Wrote:Jeremy pid='12128' dateline='1648553334']Thanks for your comments.
I certainly plan on creating such a tutorial in the future.

Jeremy

That would be excellent!  

I am giving the machining a try now, and running into an interesting problem.  I've imported an nc file from Fusion to Robodk (maybe I should try another file format?).  The fusion simulation looks perfect - the first 7mm deep cut looks like a long spiral in the shape of an irregular rectangle, with a small, consistent overlap of 1.5mm. 

Robodk also appears to have the correct path drawn in the 3d interface, and described in the simulation.

However, once the robot begins cutting the path, it clearly has a mind of it's own.  It is a bit erratic - sometimes following the path described, at other times acting a bit like a pinball machine, taking diagonal paths across the space, bouncing around, with a lot of tool time not actually cutting.  Unfortunately, this pinball-like-path, while mostly functional, removed two importand chunks of plywood that were meant to be left, as a result of un-planned diagonal cuts.  There are also some small areas of wood left over where the path did not intersect them. 

This is also a problem for me because I don't want to stress the robot or router too much, and was not planning on having more than a 1.5 mm overlap for most of the cutting.  Quite often, the overlap is a full 1/4", ploughing straight through areas it was supposed to be gently trimming.   


Could this have to do with the tolerance settings for joint singularities?  I don't think I've played with those and believe they are at their defaults.  

I'm using a 1/4" carbide cutter, and have tried this with my tcp calibrated, as well as non-calibrated.  I don't see any difference in the path.  Photos and station attached for clarification.

Do you folks have any idea I could try for getting a path that remains closer to the one simulated?  Despite the fact that I am having some hiccups, I am really enjoying learning to do this work.  This is the first time I've attempted to mill anything substantial with the robot.  :)


.rdk   non calibrated.rdk (Size: 5.95 MB / Downloads: 324)            

Thanks!

David
#6
That's weird as the path in RDK seems fine.

Can you spot in the code where the first erratic move happens?
And attach the code you loaded on the controller?

Jeremy
Find useful information about RoboDK and its features by visiting our Online Documentation and by watching tutorials on our Youtube Channel


#7

.txt   selkie.txt (Size: 133.19 KB / Downloads: 217)

Hi Jeremy,

The first time it is obviously taking an unplanned shortcut is around step 255-265 (according to the staubli controller).  

One pattern I noticed - the left side of the machined pattern has VERY small step-over.  Maybe 1.3 or 1.5mm.  (good for me)  The right side (as shown in photos) has step-over ranging from 5mm to 10mm!   

What do you think could be causing this unbalanaced step-over?   

Maybe it's a calibration issue, but I still don't think it explains why the path is so different from what was plotted in fusion.  It appears normal-ish for a bit, but it often will create a diagonal cut, cutting lots of air, and leaving some areas un-milled.  

Attached is what I sent to the controller (selkie.v2)  I renamed to .txt and removed the latter 3/4 of the program so it would fit the .txt file size limit.  

Thanks,

David

I realized that adjusting the staubli's 5 & 6th joints would very likely completely screw up the tcp calibration. Going to re-do that now.. I still am not sure that would explain the strange and large detours, however..
#8
All good here. I still don't know what happened with that pocket path.

I may try playing with Fusion 360 some more / altering the settings and pehaps attach an led to the end of my router bit. Then run the programs without stock in the dark using time-lapse photography to see the path it takes. I don't know of any better way to simulate it.

I am wondering - does RoboDk alter the cartesian coordinates Fusion spits out? If it does, can I ask it not to do that, in an effort to preserve the path made by Fusion? It's ok if I have issues with singularities as I can work around those, but I am just wondering how to approach that problem (the pocket clearing path going all over the place).

The adaptive clearing, while much more time consuming to calculate, seems to be working better for me.
  




Users browsing this thread:
1 Guest(s)