Rack and pinion on moving base SimMechanics 1st generation

4 views (last 30 days)
Hi,
I'm working on full vehicle simulations and on steering systems in particular. For my application I want to use a rack-and pinion to model the steering system. In my case the pinion is the steering-wheel input (axis which is fixed by a revolute joint to the chassis), the rack is the steering-rack which is connected to the tie rod and can translate wrt the chassis (prismatic joint). The whole chassis is of course not fixed in space but is driving around as well.
I've started of with the demonstration file mech_rack_pinion as provided by MATLAB. This file makes use of a velocity driver to link the translational velocity of the rack to the rotational velocity of the pinion.
I've altered this example slightly to correspond with the following drawing:
As you can see the pinion should rotate according to the relative velocity of the rack w.r.t. the chassis. However in my model it rotates according to the global velocity of the rack. I can't seem to change this in the velocity driver block since the options there are very limited.
I've tried to change the orientation of the coordinate systems from world to base and follower but this doesn't help since the orientation of the axis is not the problem..
I've attached my file to show you the problem. I need this to work in SimMechanics 1st generation since my whole car-model is build in this as well.
Jan

Accepted Answer

Andy Nitschke
Andy Nitschke on 10 Nov 2014
Thanks for the explanation of the issue you are facing and attaching the reproduction model. I was able to reproduce this issue and have put together a workaround for this issue.
Tony is correct, the velocities used in calculations by the Velocity Driver block are measured in the world frame, there is no option to use a local coordinate frame with this block.
The most simple way to workaround this limitation is to actuate both the Revolute and Prismatic joints separately rather than using the velocity driver block between the two to set up the rack and pinion constraint. I have modified the reproduction model you posted to demonstrate this workaround and have verified that the rack and pinion behaves correctly with both translation and rotation of the car chassis. Note that both the revolute and prismatic joint are actuated with the same signal aside from fact that the signal going into the pinion accounts for the pinion radius.
If possible it may be worth your time to modify the model to use SimMcechanics 2nd generation. There have been many improvements to 2nd generation, updated graphics rendering, better ability to componentize and reuse portions of the model, and updated constraints such as a gear constraint and rack and pinion constraint.
  2 Comments
Jan
Jan on 12 Nov 2014

Hi Andy,

Thanks for your answer. This solution seems to work but only if I prescribe the displacement of both. What I am looking for needs to work in a more general sense. I need the possibility for the rack to transfer forces to the pinion and the other way around. Just like in a real vehicle where the driver provides input through the rack-pinion to the tyres and the tyres provide feed-back to the driver via the same mechanism.

I've altered my drawing a bit and expanded it with the equations of motion. I'm still thinking that I should do something with the additional input of the driver actuator block as I wrote in my document. I've added two examples now;

The first one is your altered version, mech_rack_pinion_moving_workaround_Jan.slx Here I show you what I mean, I want to be able to drive the pinion with a torque and to obtain the correct motion and force at the rack and the other way around. Also at the same time. So I want a real kinematic coupling.

The second one is a solution I am working based on the driver-actuator block (mech_rack_pinion_moving_v3.slx). I have been able to compensate for translations here by measuring the chassis motion and providing this as an input for the driver-actuator block. See attached document. However, this does not seem to work (yet) for rotations. I think if we figure this out we can obtain a true kinematic coupling.

Andy Nitschke
Andy Nitschke on 21 Nov 2014
Hello Jan,
I looked into this some more and investigated why the rotation wasn't working correctly. In the process I uncovered some deeper issues which may cause problems with this workflow. I have outlined these below:
1. Velocity Driver uses world frame causes issues with translation: The velocity driver uses its equations with velocities measured from the world frame where as the body sensor was set up to measure velocity in the local frame of the body. This causes issues if the Chassis translates in the Its own X direction when it is not aligned with the world's X direction. Please see the attached model "WhyWeNeedToMeasureTranslationInGlobalFrame.slx". Note that the body sensor block is configured to use the local frame and when there is translation in the X direction at t = 10 seconds we see error on the plot at that time. Now change the Body sensor to world frame and notice that the error at t=10 seconds goes away.
2. Velocity Driver uses world frame for Rotation as well The reason we are seeing error in the rotation as well is because the velocity driver block tries to make Pinion rotate at the velocity specified in the World Frame. If we output the rotation matrix from the body sensor block and transform the rotational of the pinion body to the world frame we can see that this is what is happening. Please see "RotationAboutWorldZ.slx" for an example
3. Singularity Point number two means that if the axis of rotation of the Pinion ever becomes rotated 90 degrees from its original orientation there will be a singularity and it will need to rotate infinitely fast in its local frame in order to rotate at the correct speed in the global frame. In addition this means that if you ever come close to a 90 degree rotation from the original orientation the solution will involve math that is close to singularity and you will likely run into numerical issues and cause the simulation to run slowly. Please run "singularity.slx" notice that scale of the error is at 10^16 due to the singularity in the math.
Due to point number 3 if the orientation of the Pinion ever rotates 90 or close to 90 from the original orientation it will not be possible to get the model working correctly. I strongly recommend that rather than try to build a work around to this limitation you work on migrating your model to SimMechanics 2G. This new version of SimMechancis is much better, is under active development by, and includes more functionality such as a specialized Rack and Pinion Constraint. Is there any specific reason you don't want to move to SimMechanics 2G?

Sign in to comment.

More Answers (0)

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!