Hi!

Inspired by Karsten knee example, above, I created a simple robot arm with three joints and grouped the nodes in a way that makes the cascading better visible: the same block is used three times - I guess it would be possible to create a macro for that.






However, I'm still wondering if it's possible to do this cascaded rotation much simpler: at the moment, the whole thing is rotated, at first. Then everything is split in order to work on the next joint (and so on). I think it would be much simpler if only the first "bone" and "joint" are rotated and the rest orients itself accordingly. Maybe I need to use RotatePts, instead, building cascaded frames?

BTW.: I made a few observations:

1. "Concat" appears to be limited to six inputs (the "Inputs" field is greyed out in the right click pop-up menue after slot "f" has been created).
2. Of you need more than one clone, then you need to cascade Clone. Does it make sense to extend Clone for more than two outputs?

best regards

Bernhard

Hi!

Here's a variant that doesn't need concatenation and splitting via idxSelect, but it doesn't look as clean.

However, there is one advantage: in the previous version, it was necessary to manually enter the indices, whereas this version can be done fully graphically.



BTW.: what's the difference between "RotatePts" and "RotatePts"? I tried both and in the robotarm2 example and they are doing the same thing.

best regards

Bernhard

Hi!

Here's a mix of robotarm.nod and robotarm2.nod from the earlier postings. It's using only two objects for the concat and idxSelect stages, so there is no need to figure out the indices manually.
It looks cleaner, but I'm still not happy that the angles also need to be propagated through Math adders. That works ok for this example, rotating all objects around the same axis orientation, but if you need to rotate around several axis then it probably won't work as expected.





Mathematically, this is just a simple chain of vector calculations. It would be great if this could be mapped to nodes without tons of house-keeping around it. In this context, a experimented with the "vectors" in the extension, but couldn't yet archive the desired result.

BTW.: it appears that the "Rotate" node only makes use of the position of a supplied "Frame", but it doesn't use the orientation information. As far as I can tell, that would probably make it easier.

feedback is highly appreciated!

best regards

Bernhard

The rotate axis command uses the right hand rule, per M.G.
- B