Hello,
I would like to bend line at various angles just like robot arms. I am trying to do in 2D first but cant form the algorithm effectively other than repeating the same definition over and over. Kindly see my file and make it effectively.
It would be good if I can develop N number of lines with N number of lengths and angles for each and in 3D
arms.gh (10.9 KB)
Please don’t double-post:
Since the same thread is in the developer class this means that you are after a code based solution? If so see attached:
Lines_LengthsAngles_V1.gh (8.7 KB)
If on the other hand you want to do that interactively (and manage history and variations) this requires some lines of code more (swap volatile-persistent data per cycle).
Excellent Job. I was trying with grasshopper components but failed. Thanks a lot. You are awesome now.
Er … not even close, I’m afraid: see attached where the trip to the rabbit hole just begins.
Lines_LengthsAngles_V1A.gh (121.9 KB)
Although it Ăs quite slow but brilliant work. When I read clash checks I thought you make the pipe avoiding clash with each other that would be impressive too but I understand that is time taking process. But overall you are the real MVP today.
Is slow because Rhino is just a surface modeller (and I’m not using instance definitions [but that’s a minor issue here]) … meaning that you date 100% the wrong girl for that type of stuff (but hope dies last). I would strongly suggest to find some friend of yours with some real-life experience in MCAD matters (and CATIA/Siemens NX knowledge).
For some primitive clash checks (1M miles away from reality in real-life robotic arms) see attached.
Lines_LengthsAngles_V1C.gh (128.7 KB)
Can you enlighten me why the number of lines is less in the output and why it straightens up after certain degrees and line vanishes at zero degrees?
Lengths are checked against the 6*RS value since the test joint (both ends per arm) is made that way (remember: that’s just a stupid demo).Thus by increasing the RS you may get different lengths.
Angles are checked against the constrains imposed by the topology of the spherical joint (the extension required to “grab” the male join and the all overall R/RS ratio) meaning that the bigger the size … less and less “steep” angles are required for avoiding clash issues.
For the zero degree … er… hmm… maybe there’s a bug around (I’ll investigate soon). Anyway no special attention is given on that case since this is NOT the way to design any robotic arm in real-life.
Thank you very much for the info. I was learning about the movement but you gave me more insights for checks. For now it is just an arm like Tars has in interstellar movie but also trying to adapt ball shapes. Thanks a lot for your impressive work.
Also I want to ask you whether you have prior experience in studying robotic movements? collapsible types
Tars was a very primitive thingy (but the movie was OK).
I’m in the AEC market sector … meaning that occasionally I design special stuff (for assembling on site complex facades/trusses/membranes and the likes) using CATIA and/or Siemens NX (and in some rare cases Microstation Connect). In general any solid app worth the name includes feature driven modelling, clash tests and kinematics … meaning that you can avoid reinventing the wheel. Parametric (as defined in GH) has very little importance for that type of stuff in real-life.
WHAT AN IDIOT:
I was using the same check for null/default double values in the Length Lists (that’s OK) and in the Angle Lists (that’s NOT OK) … and … well … the deafult value (0) was excluded from the angle party … meaning that a 0 angle was never considered as a valid angle value. See correct results with these checks properly modified:
I’ll fix this ASAP.
Moral: WHAT AN IDIOT.
I wouldnt call you an idiot though… Human … for a moment i thought you might be an alien doing all these advanced stuff… Jokes aside… Still its an amazing work.
Well … I’m a pro meaning that ANY mistake is out of question (but HUGE mistakes are OK, he he).
Until the def is ready see here the angle auto correction working in a given random node: you would agree that for the R/RS values used the join has reached the max possible angle (a 1 degree free-play/tolerance is included as well: better safe than sorry):
BUT … for the 2nd angle measurement mode where clash checks are not included (to indicate the whole point) … see what happens (female black part clashes with the pink cylinder part of the male join):
Kindly post the corrected definition.
Added some checks more (angles) and removed the stupid part.
Lines_LengthsAngles_V1CA.gh (130.5 KB)
But … the thing is that no real-life robot arms use spherical joins … meaning that the whole def is just a simple/entry level demo indication with regard the clash tests required (that are a given in CATIA/NX/Microstation anyway). That said trigonometry is a good thing … but if you have to resolve high pressure cables clash situations … well … hello CATIA.
Here’s an auto angle adjustment (animating R slider from 0.10 to 0.39, RS: 0.55) demo:
