Abnormally high reaction force in Simscape Multibody

Hello,

I have a simscape model of a hexapod robot which I am trying to make traverse over a small obstacle. When walking on the regular floor object, the robot is fine. However, as soon as the first leg makes contact with the obstacle, it experiences an abnormally high normal reaction force, causing the whole robot to get sent flying into the air. I am not sure why this is happening. The settings for the spatial contact forces between the floor object and the obstacle object are identical. Here is a video from the mechanics explorer (apologies for the speed, it may have to be watched on 0.25x playback).

I have tried everything I can think of - tweaking stiffness and damping parameters (K_obs and C_obs) and trying different solver settings/tolerances. Drastically reducing the stiffness and damping coefficients does help, but results in the legs of the robot sinking several millimetres through the obstacle.

I have attached a zip file containing the full project. To run the model, open and run HexMaster.m. Then, run adeept.slx. Any help would be massively appreciated.

[Jan Janse van Rensburg]

Is this fixed timestep? Do you have zero crossing detection turned on in the spatial contact force block?

This looks like the solver is missing the point of contact. For fairly stiff contract modelling variable step with zero crossing is a good setting

[Max]

Hi @Jan Janse van Rensburg, thanks for your response. I did not have zero crossing detection enabled, but it is now, and it hasn't resolved the problem. I am also using a variable step solver (ode45) have tried a number of different solvers but doesn't seem to affect the issue. Any other thoughts? Could it be anything to do with the zero-crossing algorithm in the solver settings?

[Jan Janse van Rensburg]

What is your maximum timestep? If you have stiff contact (in the order of 1e6) also try a stiff solver like ode23b. What is the weight of the components? Check to see that they are not overly light.

Answer 1

[Jan Janse van Rensburg]

Hi Max,

I took a look at your Simscape Multibody model and have a few suggestions that might help you get better results and improve performance.

1. Unit Correction: It seems like the mass of the lower plate is in grams instead of kilograms. Double-check the units for other components as well to ensure accuracy throughout your model.
2. Prescribed-Position Approach: You're using prescribed-position for the legs, which can generate unrealistic torques. It might be more realistic to use torque as an input to the legs, reflecting the maximum torque your motor can provide. Alternatively, you could measure the torque in the leg and adjust the motion accordingly.
3. Speed Adjustment: Your robot is moving very fast, and with the prescribed motion, the legs hit the ground at a high speed. This causes the robot to lift quickly and potentially launch into the air. Try slowing down the robot; I reduced the speed by a factor of 4, which produced more plausible results.
4. Simulation Speed: The ABS block in your energy consumption section is significantly slowing down your simulation. Disabling zero-crossing detection can help speed things up. Keep in mind that with prescribed motion, your energy calculations might not be entirely accurate since the motors in your model can provide any required torque.
5. Sample Time Setting: Your "Repeating Sequence Interpolated" blocks have a sample time of 0.01. Setting this to -1 allows the variable timestep solver more flexibility, which might not have a big impact now but is generally a good practice.
6. Convex Hull and Contact Proxy: Be cautious with the convex hull of the legs, especially since your STEP file includes the motor. This could result in an inaccurate representation of the foot. Consider using a contact proxy by adding a sphere with the diameter of the plate thickness to the bottom of the "femur," or use a point-cloud to describe the entire leg assembly accurately.
7. Simplified Control Strategy: If implementing torque-based control is complex at this stage, you could slow down the entire motion or just the gait when it’s close to the ground (e.g., when it’s 2-3 times the height of the obstacle).
8. Data Logging: Consider using Simscape data logging instead of manually adding "To Workspace" blocks, as it can streamline your workflow and improve efficiency.

There are several ways to enhance your model, and these suggestions should help you get started. Let me know if you have any questions or need further assistance!

[Jan Janse van Rensburg]

So to be clear on what the issue is why it is "jumping" it is a combination of prescribed motion and fast moving legs - so when the leg makes contact there is still some movement of the peg required to get to the bottom position of the peg movement so this accelerates the rigid-body of the system and essentially pushing the robot off from the ground, actually quite similar to jumping.

[Max]

@Jan Janse van Rensburg thank you very much for taking the time to look into my model! It turns out that the sample time setting in the repeating sequence interpolated blocks actually had the biggest effect. I think that with the setting of 0.01, the prescribed motion of the leg was missing the point of contact with the obstacle, and, as a consequence, trying to force it through the obstacle, resulting in a huge reaction force to compensate for this 'penetration'. Setting it to -1 has virtually eliminated the issue. There is still some bouncing - perhaps more than there is with the real robot - probably as a consequence of the prescribed motion approach, as you said. Perhaps changing to torque-based control would help reduce it even further, but unfortunately this is beyond the scope of the project and I don't have time.

I'll definitely take a look into your other suggestions for efficiency improvements, which are much appreciated as this is my first time using simulink/simscape. Cheers!

[Jan Janse van Rensburg]

Actually that is not the whole story: So there is certainly also an issue with the impact and motion control, I made a updated version of the model that mitigates that by slowing down when the foot is in contact, see the attached ANimated GIF

Furthermore, the Repeating sequence was taking your Time data's timestep and limiting the variable timestep solver to to not take a timestep larger than that (0.0001) - THis made the simulation very slow, so I made another approach, used a Lookup table and created a repeating clock signal. See the attached Project, I also added some directories to your files and made the master script run on startup