How to override the movements of a “cherry picker” to avoid collisions

I am working on a project for which I need to program the movements of a “cherry picker” or “aerial work platform”, and I need to avoid it from colliding with a wall. I was able to create an accurate IK chain that follows the magenta trajectory, as shown in this video: Perspective.MP4 - Google Drive

However, the simulation created by Bongo has two main issues:
a) It makes the machine collide with the wall, and is unable to make it return to its original, “contracted” starting position at the end of the animation.
b) The machine performs unnecessary movements (excessive extension of the telescopic joints, deviations from the intended trajectory or rotating the worker’s platform, losing its correct orientation of being parallel to the ground).

I have tried to do the following to solve both issues respectively, but unfortunately I have not been successful:
a) Using expressions (disabling 3D tweening) to manually override the angle of the hinge joints or the extension of the telescopic joints (see images below).


b) Increasing the precalculation samples to achieve a simulation that is “smoother” and “looks better”.

Would it be possible for you to help me solve this? Attached you can find the Rhino file. In advance, thanks for your attention!
Cherry picker and wall.3dm (13.3 MB)

The reason for the machine to perform unnecessary movements is that there are lots and lots of variable elements (pivots and telescopes) in a linear chain. This makes that there are many ways to solve the chain (no to say infinite), hence the IK solver chooses any one at random.

It is somewhat like solving an equation like this: x + y + z = 7. To be able to solve this extra info on the relation between x, y and/or z is needed. In mathematic extra equations are required, a system of equations. Mechanical structures often use triangles and/or parallelograms to do the trick, thus creating a network rather than a linear chain.

Systems like your cherry picker need an advanced solver by which it is possible to specify certain restrictions/constraints (like e.g. parallelism). For instance, I assume the telescopes are supposed to only come into action when it is necessary for reaching to the highest cherry’s. Bongo’s Friction/Stiffness attributes are meant for that, but in my experience this never has functioned adequately.

Your idea to use Expressions to do so is quite nice. Unfortunately, Expressions are not taken into account by the IK solver. I’ll ask the developers whether that’s feasible at all.

And obviously, in this multi-solution case increasing the precalculation samples doesn’t help at all.

I think a working animation can be maybe achieved using partly Forward (keyframing the telescopes) and partly Inverse Kinematics. It would take work and lots of inspiration tough.

Luc

1 Like

When you mention that I need “an advanced solver”, do you think that one like PyBullet and its inverse kinematics solver would work?

.

I also tried to tweak the Stiffness attribute, by alternating between hinges with high stiffness + telescopes with low stiffness and hinges with low stiffness + telescopes with high stiffness. However, this didn’t cause any changes in the resulting animation. Why do you think stiffness doesn’t work?

.

Yes, I also tried to use Expressions but they didn’t work for me. I suppose that there should be a way to use them and solve this issue, so I would be very grateful if you asked the developers on how to do it.

.

By this you mean to employ a strategy of dividing a big, complex problem into smaller ones that are easier to solve? E.g., instead of trying to create a single animation for the whole magenta path, it would be better to divide the path in several segments and create separate animations using forward kinematics to define the starting position for each path segment (see image below)? Would it be possible to make the start and end positions of the machine to be coincident, so that they can be joined into a single smooth animation in the end?

.
And lastly, what do you think about the way I tried to use Expressions and Keyframes on my Rhino file? Am I using them correctly or are there any errors in the document?

Thank you very much for your quick reply @Luc!

Sorry for the late response. I was struck by the flu the other week – still a misty brain at the moment. Moreover your enigma was quite a challenge to conquer.

First the result of an examination of you model:

  • The trajectory curve counts 2998 control points. This isn’t much a Bongo issue, but I personally try to avoid the use superfluous control points - that just makes everything harder (for man and machine). I took the liberty of rebuilding the curve (Rebuild command).
  • ‘01_Base’ : is ‘Part of a IK chain > Constraint > Keep pivot location, orientation and scaling’.
    That’s not required. An element of an IK-chain that does not play a role as a Joint or a Constraint can simply stay a basic ‘None’ - also the ‘stable head of a chain.
    I can understand you thought you had to make is a steady by constraining it to its place, but that only makes the IK calculations more complicated.
  • ‘02_Rotator’ : I feel the limits setting of -225 till +225 doesn’t make much sense. It describes a range of 450 degrees – even more than a full rotation.
  • ‘10_Platform’ : is Joint and Constraint. Obviously the default ‘Keep pivot location, orientation and scaling’ constraint cannot possibly realized by the Solver. That’s the reason for the “Bongo: Constraint goal not reached” message to pop up. More over this makes the duration of the precalculation exceptionally long.
  • ‘Target’ : is Simple Constraint double; ‘Look Along Z Up’ and ‘To Path’. That’s unnecessary. ‘To Path’ suffice in this case. In this model ‘Look along’ cannot help to keep the platform horizontal.
  • There were some objects with History. I purged the History.
  • I changed the Timeline length in seconds to 50 in order to have a decent preview.
  • The composition of the Expressions you tried to use to control the angulations are correct, but keyframe data and Expressions are be ignored as soon as the object is made a Hinge or a Telescope etc…, that is to say only for the kind of freedom the IK requires (so Rotation keyframe data for a Hinge, Position data for a Telescope etc…).
  • Finally I found that there is no way to reach the most far out positions of Target with the limitation to 90° for the rotation of ‘03_Main shaft base’. I assume you tried this to avoid hitting the wall. I altered it into 180°.

In the enhanced version of your model (‘Cherry picker and wall 001.3dm’) percalculation is done swifter, because there are hardly no more ‘Constraint goal not reached’ situations.

Nevertheless, the model still shows clearly that there are 2 issues:

  • In this chain there is no way to keep the platform horizontal nor perpendicular to the path curve. I assume that was the general idea.
  • There are far to many variables in the arm (the randomness in solving x + y + z = 7). The resulting movement is far from logic.

Thus some Forward animation comes in: ‘Cherry picker and wall 002.3dm

Issue 1 above occurs because a “Constrain to object” allows full rotational freedom.

To solve this I have moved the ending-IK-Constraint from ‘Center point’ to the pivot which connects ‘Platform’ to ‘Platform inclinator’. ‘Center point’ is superfluous and thus deleted. ‘Platform’ is made child of ‘Target’ and various rotation keyframes are set in to keep the platform more or less perpendicular to the curve.

To solve the second issue the use of IK is restricted to the Hinges in the system, whereas the movement of the Telescopic shafts is done ‘by hand’ via keyframing. It is perfectly feasible to manipulate objects via keyframes in a chain that only partly consists of IK-skilled elements. An object in a Hierarchical chain will obey keyframes as long as a element in a chain isn’t made ‘Part of an IK chain’ in the ‘Constraint and Joint’ setting.
Image 0
As said, keyframe data (or Expressions) will be ignored as soon as the object is given IK-joint properties.

Moreover, in a child of parent (in a Hierarchical chain) has a special peculiarity. A basic Bongo object Position is always related to the World coordinates. On the other hand the child of a parent moves in its parental Object space. When Bongo rotates the parent (by keyframe data or by Expression data or by IK solver results) the directions in which the child moves are rotated likewise.

Mind you, the rotation of the parent had to be done by Bongo actions. Rotate the parent by Rhino rotate command will not do. Rotate the pivot by using the BongoRotatePivot command will not do. Also BongoRotatePivot the pivot of the child will not do.

A demo: ‘Child moving in parental space.3dm

This oddity allows shifting the Picker’s shafts in the correct direction while the hinges spin to their heart’s content.

In zero animation (a point where there is not any Bongo data (other than 0) influences the object – which is mostly at tick zero) the Main shafts of the Picker are nicely horizontal, hence their movement can be animated by using only the Y parameter.

In order to move the Secondary shafts also by using only 1 parameter, the longitudinal axes of their parent ‘06_Secondary shaft base’ in zero animation have to be horizontal as well.
So the objects’ zero animation situation is made like this


In your model, for ‘03_Main shaft base’, ‘04_Main shaft middle’ and ‘05_Main shaft top’, ‘06_Secondary shaft base’, ‘07_Secondary shaft middle’, ‘08_Secondary shaft top’ and ‘09_Platform inclinator’ the pivot is variously rotated 90 degrees about the main World axes. I see no reason for that. Although it’s harmless, I find it confusing and a potential for mistakes. So I’ve reset them all to the default (BongoRotatePivot (Reset) command).

Then… to constrain the ‘09_Platform inclinator’ to ‘10_Platform’ a pair of constraints is set up. Two points at the top and at the bottom of the axis of the spindle in ‘09_Platform inclinator’ and a point plus a curve defining their required position regarding ‘10_Platform’. The use of 2 constraints is necessary to keep ‘Platform inclinator’ horizontal as well.

I had to suffer quite a lot of ‘Constraint goal not reached’ messages before I finally found out that your spindle in ‘09_Platform inclinator’ is not exactly vertical. It differs 0.020 millimeters

Hence I used a perfect vertical central axis curve and a point dedicated to fit on the curve. Moreover this makes things visually more comfortable.

By trial and error some keyframes are set up to move the shafts telescopically in order to enable the IK solver to ‘reach’ the constraint. I tried to use Expressions to synchronise the movement of the “… shaft end” with that of “… shaft middle”, but I apparently increases precalculation time (more than double). So I kept keyframes for all for shafts – it isn’t hard to edit both parts simultaneously.

I hope that in model ‘Cherry picker and wall 002’ the cherry picker more or less acts the way you expected, apart from a little twitch at the start (hardly noticeable – best to be seen in Right View) and some turmoil during the landing.

The latter is when the platform travels along the final part of the path. Pretty much “Bongo: Constraint goal not reached” messages pop up. It’s obvious this specific part of curve is to hard for any cherry picker.

So, to cure that I adapted the end of the path-curve to be more natural: ‘Cherry picker and wall 003.3dm

The twitch at the start, is due to the fact that the start of Target’s path is strictly vertical. To enable ‘09_Platform inclinator’ to do likewise one of the arms of the picker needs some either to shrink or to stretch – which they cannot. I made an attempt by setting up some keyframed motion on one of the shafts, but the shift must be very subtle that it cannot be done ‘by hand’.

But… to get the hinge of ‘09_Platform inclinator’ over the point where it aligns with the hinge of ‘03_Main shaft base’ working with an arch-shaped path must be a possible.

Bringing in a small arc at to begin (and end) of the path helps out : ‘Cherry picker and wall 004.3dm

There you go.
Luc

PS. I had a hard time working on the model, among other because the symmetries of ‘09_Platform inclinator’ was rather messy.
Image 2a Image 2b
For complex Bongo IK structures (like this one) it is crucial that the geometry of the objects is correct. I would advice you to use Rhino’s Osnaps, Ortho and Plans features as much as possible. A well thought out positioning and use of CP (Constructions planes) and of the Grid and Grid Snap can also be very helping.

2 Likes

Thank you very much for all the dedication you provided for solving these issues @Luc !

I greatly appreciate the thorough explanation. Your final Rhino model was very useful for my work on this project. I will let you know if I need any further help!

Best regards,

Víctor Ramírez

1 Like