Further help with 1/2 car model

@Umar Apologies- I was trying to upload a new set of photos and the upload kept failing so I thought I would get rid of some of the old ones. Sorry for the mess- I will create a subsystem once this is working, but I have now calculated the heave and pitch acceleration using the acceleration from the suspension compliance blocks respectively.

I have then intergrated these to calculate the pitch and heave displacement, which are now showing up as non 0 which is fantastic. How does this now reconnect into my model? So that when I run it my multibody experiences both pitch and heave? Does an existing part of my model need to be deleted?

Many thanks,

Sarah

[Sarah]

I have taken 1.35 as L for reference.

[Umar]

Hi @Sarah,

Thanks for your endorsement, very kind of you. As far as the update — it looks like you’ve made solid progress getting the heave and pitch accelerations integrated and showing non-zero displacements. That’s exactly what you should expect at this stage.

From the screenshot, your setup now mirrors the standard half-car suspension architecture used in the MathWorks “Half-Car Active Suspension Model” and “Vehicle Body with Pitch and Heave Dynamics” examples. The 1.35 m scaling factor you used for L is consistent with the lever arm applied between front and rear suspension forces to compute the pitch moment.

To answer your question about how this reconnects to the rest of your model:

1. Connecting back to the Multibody domain: The integrated *heave* and *pitch* displacements should feed into the multibody representation of your sprung mass (or the Vehicle Body block, if you’re using the Vehicle Dynamics Blockset). Now, if your multibody body currently has joints fixed in the vertical and pitch directions, change those to motion inputs. In Simscape Multibody, you can enable “Motion → Provided by Input” on the relevant joint (translational for heave, revolute for pitch). Use Simulink-PS Converter blocks to drive those motion inputs with your displacement signals.

2. Avoiding duplication of motion: Make sure any previously existing body motion drivers or vertical/pitch constraints are disabled. Otherwise, you’ll end up over-constraining the system. Also, you don’t need to delete the suspension compliance sections — they remain responsible for computing the dynamic forces that generate your accelerations.

3. Verification: Once connected, rerun the simulation and check that the multibody body responds with the expected heave and pitch motion.The responses should correspond closely to the integrated outputs you’re seeing now.

Once that’s confirmed, it’s a good idea to group the new heave/pitch motion calculation into a subsystem so the model stays clean and easy to maintain.

Overall, you’re on the right track — the integration and scaling look correct. At this point, it’s just a matter of routing the heave and pitch displacement signals into the Multibody motion inputs so that your physical body experiences the same dynamic response you’ve computed from the suspension compliance paths.

[Sarah]

Thank you so much I’ll try that tomorrow !!

[Sarah]

@Umar Thank you so much for all of your help!! I keep trying to upload a new photo to show you my progress but it will not work so I shall describe..

Currently I have my road bumps as my main input into the mutlibody model.

Do I now want to make my heave and pitch displacements my multibody input, with the bumps as inputs direct to the wheel within the multibody model?

Many thanks in advance,

Sarah

Answer 1

[Umar]

@Sarah, you're doing great and you're almost there. Let me clarify the signal routing for you because this is a common point of confusion when connecting compliance models to Multibody.

The answer to your question is, no, don't replace your road bump inputs. The road bumps should stay exactly where they are as inputs to your suspension compliance model. What you've computed—the heave and pitch displacements—are the outputs that describe how your vehicle body responds to those road inputs. These are two separate things: the excitation source (road) versus the dynamic response (body motion).

Here's how the signal flow works in the standard MathWorks architecture: Your road bumps come in and excite the wheels at the tire contact points. These create suspension deflections at the front and rear axles. The suspension deflection at each axle is basically the difference between where the body is (including its pitch angle) and where the road is. Those deflections generate spring and damper forces. Those forces then drive your equations of motion for the vehicle body, giving you heave and pitch accelerations. You integrate those twice to get your heave and pitch displacements, which is what you've already done successfully.

Now for the connection to Multibody: those integrated heave and pitch displacements should drive the motion of your vehicle body in the Multibody domain. You need to set up your Multibody body with a prismatic joint for heave (vertical motion) and a revolute joint for pitch (rotation about the lateral axis). On both joints, change the actuation setting to "Provided by Input" instead of having them constrained or free. Then use Simulink-PS Converter blocks to feed your displacement signals into those joints. Make sure to enable second-order filtering on the converters—this is important because it smooths the signal and automatically computes the velocity and acceleration derivatives that Simscape needs internally.

The critical thing to avoid here is double-constraining your system. Make sure any other vertical or pitch constraints on your body are disabled, and don't have any other motion drivers competing with these new inputs. Your suspension compliance sections should absolutely stay in place because they're still doing the important job of computing the forces that generate your accelerations.

Once you wire this up, the behavior should be: road bumps excite your suspension at the wheels, suspension forces drive your body dynamics calculations, integration produces your heave and pitch displacements, and your Multibody body follows those computed motions. The motion you see in the Multibody animation should match the displacement plots you're already getting from your integration blocks.

To verify everything is working correctly, run the simulation and check that your Multibody body is moving with the same heave and pitch behavior you're seeing in your integrated outputs. They should match closely. If you see any strange behavior or the simulation won't run, it's usually because there's a conflicting constraint somewhere.

Your setup with the 1.35 m scaling factor for the pitch moment arm is correct and matches the standard half-car architecture. You're modeling the vehicle body with four states: heave position, heave velocity, pitch angle, and pitch angular velocity. This is exactly what the MathWorks sldemo_suspn example does.

Think of it this way: the road profile is what happens to the vehicle, the suspension compliance model figures out what forces result from that, your equations of motion determine how the body responds to those forces, and the Multibody representation just visualizes and tracks that response in the physical domain. Each piece has its job, and you're not duplicating anything—you're just connecting the pieces properly.

Once you get this connected and verified, I'd recommend wrapping your heave and pitch calculation blocks into a single subsystem with clear input and output ports. This keeps your top-level model clean and makes it easy to maintain or modify later.

You're on the right track and this is really just the final wiring step. The hard part—getting the dynamics and integration correct—is already done.

[Sarah]

Hi Umar,

Apologies to message again but I have been tearing my hair out over this problem! In my prismatic/revolute joints, under the actuation tab, I have the option to make Motion or Force "Provided by input". I have just integrated the displacement to get heave and pitch acecleration in the equations of motion, so I am unsure whether I am supposed to make Motion or Force "provided by input" as neither seems to make sense to me.

I am very sorry, I'm sure you thought you had got rid of me by now!

Thanks in advance,

Sarah

[Umar]

Hi @Sarah,

Glad to hear back from you. At Mathworks, it is our goal to help out. If not too much to ask; is it possible for you to attach screenshots of GUI parameters settings, it will help me a lot to figure out what are you actually struggling with.

[Sarah]

Hi @Umar,

Yes of course let me show you what I have done- sorry I am reluctant to tidy it until I have something working so it is a bit messy.

I have my overall diagram that looks like this: we have heave and pitch displacements calculated. I have verified these using the scopes and they both have motion. I have then used a 6DOF joint- to feed these displacements into, as the revolute joint did not seem to be in the right plane. I have set Ry and Pz to "Provided by input" as you can see below. Is the problem that I am inputting Force instead of torque to Ry?

Here is my multibody model could the problem have arisen from the mismatch in frames?

Thanks so much,

Sarah

[Umar]

Hi @Sarah,

I went through your block diagram and the Simscape joint settings in detail, and I also checked the MathWorks documentation to confirm what the model is expecting. Here’s the short version of what needs to be fixed.

The main issue is that the model mixes two different ways of driving the suspension—prescribing motion and applying forces—and the current wiring sends the wrong type of signals into the wrong inputs.

Your heave and pitch displacement signals are being fed into ports that the joint treats as force/torque inputs. Displacements aren’t forces, so the joint reacts unpredictably. To prescribe motion correctly, the joint needs to have “Motion Provided by Input” enabled for the pitch and heave axes. Once those motion ports are turned on, your displacement signals must go through Simulink-PS Converters so the joint receives proper physical-signal position inputs (with automatically generated velocity and acceleration). At the same time, force and torque inputs for those same axes should be disabled so the joint isn’t being driven by two different methods at once.

The second problem is that the axes in the joint don’t line up with what the vehicle model considers pitch and heave. Because the 6-DOF Joint has a fixed order of translations and rotations, the frames have to be aligned so the pitch displacement really maps onto the correct rotational primitive and the heave displacement maps onto the correct translational one. If they don’t, the model applies motion in the wrong directions. This can be corrected using Rigid Transform blocks or by reorienting the base and follower frames of the joint.

Finally, once motion is being prescribed properly, it helps to enable the joint’s sensing outputs so you can monitor forces and verify the behavior. This makes debugging much easier and matches how MathWorks suggests validating multibody setups.

In nutshell, enable motion inputs on the correct joint axes, route your displacement signals into those ports through converters, turn off force/torque actuation for those same axes, and make sure the joint frames are aligned with the vehicle’s pitch and heave directions. After that, the model will behave consistently with the calculated heave and pitch signals.

Hope this helps clarify the changes needed.