Strange Motor Collision Behavior

46 views
Skip to first unread message

Alex Teti

unread,
Aug 16, 2022, 3:10:33 AM8/16/22
to ProjectChrono
I was wondering what would happen if a motorized object (a rectangle) collided with a fixed object (a cube).

To my surprise, the result was either 
A) The motorized object (rectangle) being pushed away from its constrained location
or
B) The stationary object (cube) being pushed away from its constrained location

If I made the cube fixed (cube->SetBodyFixed(true);) then the cube would remain stationary and the rectangle would move.

If I used a ChLinkLockLock link to link the cube and floor, the cube would be pushed away (and then slowly drift back). 

Is there a way to make both the objects stationary after they collide, like if some metal object got stuck in a turbine and jammed it?
cube.png
motorizedRectangle.png
Message has been deleted
Message has been deleted

Alex Teti

unread,
Aug 16, 2022, 3:33:21 AM8/16/22
to ProjectChrono
"Note: this is a rheonomic motor, i.e. it generates the motion geometrically by strictly enforcing the speed constraint;
therefore no compliance is allowed and this means that if the rotating body hits some hard contact, the solver might give unpredictable oscillatory or diverging results because of the contradiction.
"

Is THIS the underlying reason? I don't think I can even say "rheonomic"!

Alessandro TASORA

unread,
Aug 16, 2022, 8:43:59 AM8/16/22
to Alex Teti, ProjectChrono
Yes, the reason is the one that you quoted. 
Both ChLinkMotorSpeed and ChLinkMotorAngle are Rheonomic (or "Rheonomous" in some literature), that is: the position is strictly enforced by some function of time, in a "geometric sense". Hence they don't allow compliance if they conflict with other constraints, and results can be impredictable. 

Only by using force- or torque-based motors like ChLinkMotorTorque (and adding PID controllers for keeping approximately the position via feedback loops, for instance) you can simulate that hard-stop scenario you need. But at the cost of more complication, and some compliance and latency and reduced bandwidth - just like realistic servo motors, by the way. 

Best regards 
Alessandro Tasora 


Da: projec...@googlegroups.com <projec...@googlegroups.com> per conto di Alex Teti <alexte...@gmail.com>
Inviato: martedì 16 agosto 2022, 09:33
A: ProjectChrono
Oggetto: [chrono] Re: Strange Motor Collision Behavior
--
You received this message because you are subscribed to the Google Groups "ProjectChrono" group.
To unsubscribe from this group and stop receiving emails from it, send an email to projectchron...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/projectchrono/0346f694-3438-4469-9a90-0ac702567730n%40googlegroups.com.


Firma il tuo 5xmille all’Università di Parma, aiutaci a essere sempre più accoglienti e inclusivi verso le nostre studentesse e i nostri studenti - Indica 00308780345 nella tua denuncia dei redditi.

Alex Teti

unread,
Aug 16, 2022, 2:51:49 PM8/16/22
to ProjectChrono
So if I just used a torque motor without the PID controllers, there would still be some "wiggling" to the motor joint?

alessand...@unipr.it

unread,
Aug 16, 2022, 6:28:10 PM8/16/22
to projec...@googlegroups.com
So if I just used a torque motor without the PID controllers, there would still be some "wiggling" to the motor joint?

it depends... for example if you set a constant torque to some shaft you may end with a rotating structure with linearly increasing rotational speed (constant angular acceleration), unless you have some nonlinear resisting torque that avoids such increasing unlimited drift.

In general it is unlikely that you will provide a torque to some actuator in a pure "feedforward" mode, ie. without implementing also some type of feedback to correct errors, ex. a PID. Well, this if you want to follow some desired position (or speed) setpoint.

Alessandro

Reply all
Reply to author
Forward
0 new messages