H-bot simulation

Hi all,

With your prior help (Daniel’s in particular) I’ve become addicted to simulating motion control assemblies I use in my artwork. Each time I do so, I not only become more familiar with Grasshopper and Kangaroo, but also learn something new about the movements of my kinetic sculptures. My current project involves an “H-bot” - 2D Cartesian belt-driven rig, where both motors remain fixed in place:
The two ends of a long timing belt connect at the carriage (middle), after snaking around the two fixed-motor pulleys, two fixed idlers (top), and four idlers mounted on a horizontal plate (not shown) that can move vertically. I’ve been unable to find an example that gives me clues on how to drive a belt with a pulley - any suggestions welcome!

you have some great ideas!

CONVEYOR BELT might be a starting point but I reckon you are going to need a custom goal. If it can be done on a surface, surely it can be done on a curve in 2D?

Thanks, Martyn - I wish I was clever enough to come up with this scheme, but it’s at least 10 years old (I don’t know who did it first). Not having to move the secondary axis motor is a huge plus for my purposes. I did find the conveyor belt example, but am lost as to how to “repurpose” it. I don’t need realistic 3D toothed belts, etc. - just the ability to slide a closed 2D curve that’s tensioned around some circles.


hbot.gh (17.4 KB)


You could also do something similar even without Kangaroo, but I already had the LengthSum goal from a previous project, so this was easy to set up.

Once again, Daniel - you are amazing. Thank you!!

this is, of course, leaving us wondering what are you going to use to control motors A and B and what are you going to attach to the carriage?

RestLengthSum … that’s cheating!

1 Like

This model doesn’t use Kangaroo and is more well-behaved in the sense that the “belt” never changes length because it stays within limits. The ‘H_size’ and pulley ‘radius’ are configurable.

P.P.S. Added all pulleys. (white group) Almost as complex as the rest of the model!

hbot_2021_Jul16c.gh (30.2 KB)


Added rotation angles and indicators for the two drive motors at the bottom. Zero position is when both ‘Y_move’ and ‘X_move’ sliders (blue groups) are centered at 0.5 and indicators are vertical. Sum of belt movements (distance) and pulley circumference (from radius) are used to calculate angles.

hbot_2021_Jul16d.gh (27.5 KB)


Super cool stuff! It somehow reminds me of Paul Gould’s robotics research with beaded thread:


This is a neat solution but I think what @Bruce_Shapiro is aiming for is to have the motor inputs the same as that which he would use in a real life model… So radians or degrees for each motor, or steps if he was using stepper motors so he can simulate the model with the same data / signals that he would use in real life.

I had a quick look at your model and it looks like your inputs are the amount to move the carriage in X and Y and you can output the angle that the motors would move.

I can’t see how to flip this so the input is motor moves and the output is X and Y… you are probably the best person to do this as you did the GH def!

Which came first, the chicken or the egg? For this, I think primary inputs would be XY coordinates, which is what the ‘Y_move’ and ‘X_move’ sliders (blue groups) effectively are. Actual XY dimensions from the center point are calculated in the model and can be displayed.

From the coordinates, rotation values for ‘Motor A’ and ‘Motor B’ are derived. I used degrees but in fact I’m calculating fractional rotations which can easily be output as radians or steps instead.

Just to clarify - the belt isn’t changing length in the kangaroo version either, that’s what the length sum goal is ensuring, and because there’s nothing opposing it, it converges exactly.

As I said in my original reply, there is indeed no real need to use a numerical solver like Kangaroo for something as simple as this, for which a basic geometric constructive approach might be better.

If you wanted to extend it to more complex setups with more cables/non orthogonal angles etc though, then the simulation approach might help.

Your model goes wacky when “safe bounds” on the sliders are exceeded, which causes the belt length to change. Limits could be imposed of course, as I did, but I don’t see any reason to use Kangaroo.

I didn’t get a single vote so far though? :roll_eyes:

1 Like

Yes, adding limits on the input is trivial.
I’m agreeing with you though - for this setup the purely geometric construction makes more sense.
I just took a look at your definition and it’s good - one vote from me.

I’m thinking it might also be nice to add a goal for cables rolling on general curves without slipping or changing length. Here you can just fillet the corners because the angle doesn’t change, but in other situations it could be helpful to allow the angle of contact with the pulley to vary (or even to allow non-circular pulleys/cams).

All I can say (again), is WOW. This community is truly awesome. Instead of commenting / replying separately:

@DanielPiker - I see now that Kangaroo wasn’t needed, but if anything, your swift response is even more impressive. And the process of going through the “economy” of your definition and C# is truly an edifying experience!

@Joseph_Oster - Thank you for your non-Kangaroo solution! Seeing it done in a different way, and incorporating useful components I didn’t know existed, like Seam and Region Union, is a wonderful gift.

@diff-arch - Thanks for the link to Paul Gould’s stuff. Love it!

@martynjhogg - The “end actuator” affixed to the carriage will be a magnet (traveling under a pan holding a field of sand and a steel ball). This is not really a “new” project - I’ve been using a polar mech to do sand-plotting for over 20 years, and continue to do so commercially. While I remain firmly biased toward circles over rectangles, fabricating large round things is harder. And evidently, not everyone wants a round coffee table :face_with_raised_eyebrow:. As for the inputs to the motors - that’s what led to my post. I want to be able to use our existing control-ware / mobile app platform with a Cartesian mech by modifying my original code so it can use existing “tracks” (nearing 1000 downloadable continuous line drawings created by our community of users) which are all in the polar “thr” format (Theta radians, Rho 0 to 1 for each vertex). Conversion of each polar vertex to a corresponding XY (and from there to AB) is trivial - but for long travel between distant polar vertices, I need to calculate intermediate points along the Archimedes spiral that is the “natural” path between those two points using a polar mech. I was hoping to use GH to guide / confirm my strategy - and thanks to you all, am on my way…

I wonder how easy it would be to connect the cables with a third axis to also rotate the end effector.
I imagine for the sand sweeping it would allow some interesting variations if you could also control the orientation of the ‘broom’.


Although there was some wonderful symmetry in using a square work space (as in previous models), I thought it would be practical to allow for rectangular dimensions… And clever to use a GH cluster to replicate the code that is common to both X and Y dimensions? But I am extremely disappointed to see flickering now that wasn’t evident before clustering! :frowning: I’ll be investigating this further… :man_facepalming:

The ‘Drive Rotation Angles’ shown in my model are intended to be inputs for the motors. They can be expressed in degrees, radians or fractional rotations which can be translated to steps.

hbot_2021_Jul17a.gh (39.8 KB)

Perhaps not your meaning, but simply attaching stuff to the ball sometimes offers an enjoyable third axis :slight_smile: