Pratt GAUD Robotics Spring 2015

Welcome to the show.

Replies to This Discussion

Permalink Reply by Denise Tang on February 25, 2015 at 2:08pm

Hi Brian,

Just figured out that part.

With the same file though- I have another problem. While I can see the code at the end- I am unable to export it properly. The monitor is telling me that the exported code is coming up blank- even though I can see it on the grasshopper file.

I have attached the files I am trying to export from on this reply.

Attachments:

DTang_Drawing.gh, 308 KB
DTang_Drawing.3dm, 1.6 MB

Permalink Reply by Brian Ringley on February 25, 2015 at 6:58pm

I was able to export the files using your definition as-is. When you export the *.mod file open it using Notepad++ or any simple text editor and you should be able to view the code the same way you can view it out of the HAL Quick Task Code output.

Permalink Reply by Denise Tang on March 4, 2015 at 3:45pm

Okay, After another painful session with the robot and the monitor we have identified the problem but I still can not resolve it.

The robot for some reason is starting at the end of my code instead of the beginning- so the reason it won't run is because it thinks its already done.

I have nowhere in grasshopper asked the robot to start at the end of my code. Could you take a quick look at it and see where I have gone wrong?

Best,

Denise

Attachments:

DTang_Drawing02.3dm, 1.6 MB
DTang_Drawing02.gh, 304 KB

Permalink Reply by Brian Ringley on March 23, 2015 at 8:14am

This sounds like an issue at the controller rather than anything to do with HAL. Your output RAPID looks properly formatted. Did the operator try sending the program pointer to the Main procedure ("PP TO MAIN")? This should start the program at the correct location even if the program pointer did not default there as it typically would.

Permalink Reply by Brian Ringley on March 24, 2015 at 9:02am

Many of you are receiving or have received errors in your HAL IKSolver component. Though this could mean many things, it typically indicates that certain paths are outside the reach of the robot. To see which paths and, as a result, which targets are outside of reach, read the Paths output of the IKSolver component.

The data structure of the paths will place the robot index in the first path and the path index in the second path. First we will want to convert the path to integers so that we can use it to search a list. For this you can use the Deconstruct Path component. Second we will want to shift the list by 1 without wrapping so that we receive the second integer (the path index) which we can then insert into the Index input of a List Item component to retrieve the unreachable targets from our list of all targets.

Once the unreachable targets are visible you will have a better idea as to how you need to modify your program to run properly.

Permalink Reply by Brian Ringley on March 24, 2015 at 9:30am

Some of you have asked how to merge grafted lists without combining items in the same branch from each list. In order to do this you must have a unique path per item. Once way to do this is with the Replace Paths component. Notice how I am recasting integers as Data Path Parameters in order to satisfy the Search Masks and Replacement Paths inputs of the Replace Paths component.

Permalink Reply by Brian Ringley on April 9, 2015 at 9:29am

Some of you have asked about turning your clustered panel results into rectangles to make the design and fabrication of your robotic end effectors simpler. The nice thing about clusters is that, provided you're consistent with your transformations (which is easy in Grasshopper), any manipulations will maintain a clustered result, which is to say that you will maintain your limited variation panel set based on either tolerance from the original panel or a set integer of unique panel types.

The attached definition shows one way (of many) to orient rectangles to the panels - in this case the Y axis of the rectangle is defined by the vector from the panel centroid to its edge midpoint. In order to maintain the frame axes' alignment with the original panel, the frame is taken from the centroid and then rotated based on the difference between its original orientation and the resulting orientation of the centroid to edge midpoint vector. Otherwise you'll get all sorts of wacky rectangle sizes as the frames of the clustered panels are not guaranteed to (which is to say pretty much will never) have consistent orientation.

Lots of collisions in the result - see if you can use Galapagos to optimize for maximum panel area with minimum panel collisions (hint: boolean test results are actually 0's and 1's and can be summed as part of your fitness value equation). Really want to go hard? Incorporate panel orientation adjustments per cluster.

Attachments:

SmartForm_Rectangles.gh, 84 KB

Permalink Reply by Milad Showkatbakhsh on April 15, 2015 at 3:09pm

We are working on the new tool path based on approach curves. In setting it up, we want to orient the robot following frames along the curve. In this set-up, there is a jump of robot rotation around the midpoint of the curve. What do you recommend for setting up these approach operations to avoid collision with an end effector and have flexibility in the degree of approach angle?

Attachments:

1.png, 482 KB
2.png, 394 KB

Permalink Reply by Peter Liu on April 19, 2015 at 7:49pm

Hi Brian,

We just encounter some problem about the working zone, which I couldn't find the way to fix it. don't know if you have any idea about how to fix this issue. The problem are First thing is that tool is not attached to the arm; and second, in the simulation, the arm rotate into the zone that totally opposite side but the tool (female mold) is in the right place.

rhino file Link

Gh Link

Permalink Reply by Brian Ringley on April 22, 2015 at 7:34am

Hi Peter,

There was an issue in my template file where I had inadvertantly used speed values to name zones. In the image below, the upper portion of the graph is correct and the lower portion shows the naming error.

However, as you can see, despite the naming error, the zonedata declarations are coming through properly as all zeros. (For more information on how zonedata arguments work, check out the Robot Studio Developer Center.)

The root of the problem is actually that our zonedata declarations are not making it through to the final RAPID code and, as such, are undefined (and seem to default to the name which follows RAPID naming standards of z[number]). The toolpath should be carrying our zonedata, speeddata, declarations, etc. but this data is not passing through the HAL post processor node. We'll have to check with Thibault as to what exactly is going wrong here.

Permalink Reply by Thibault Schwartz on April 22, 2015 at 4:07pm

Works perfectly here. If you use existing preset names (Cf. chapter on Zones and Speeds, RAPID manuals) then the post-processor will detect them and remove their declaration in order to avoid amiguity in the program that would result in an error. So to avoid that, don't use z or v as prefix, use something more specific.

In the screeshots above, you probably forgot to link your zones & speeds to the toolpath component, because they are not getting out from the declaration outputs. Otherwise please upload a file so I can have a look.

Permalink Reply by Brian Ringley on May 19, 2015 at 8:31am

This makes sense Thibault - problem solved. Thank you!