Ground reaction forces during stair climb

Hello,

I am trying to simulate stair climb using mocap data. No ground reaction force measured, and therefore, AnyBody GRF prediction is being used. Motion is such that the person walks few steps on a level ground to the staircase and then start climbing.

As shown in the attached image, GRF prediction stop working when the person is stepping on the stairs. Is there a way to simply setup things such that GRF prediction works throughout the motion (level walking and stair climbing)? I appreciate any advice in this regard.

Best regards
Jeevan

Hi Jeevan,

This looks interesting and I agree, the GRF prediction in the standard model will look for contact only at ground. I think the quickest fix could be to implement multiple instances of GRF prediction, once (or twice, if you don't know which leg will land on which step) for each step. So, in the file where you have your GRF prediction (typically in Setup\ForcePlates_GRFPrediction.any), you could add extra implementations of GRF prediction, for example:

FootPlateConditionalContact GRF_Prediction_RightStep1(
  NORMAL_DIRECTION = "Y",
  NUMBER_OF_NODES = 25,
  NODES_FOLDER = FootNodes,
  SHOW_TRIGGER_VOLUME = ON,
  PLATE_BASE_FRAME = Main.EnvironmentModel.GlobalRef) =
  {
    CreateFootContactNodes25 FootNodes(foot_ref = 
    Main.HumanModel.BodyModel.Right.Leg.Seg.Foot,
    NAME="Step1") = {};
    
    // Additional force plate settings
    Settings = 
    {
      LimitDistHigh = 0.315; // Vertical height
      LimitDistLow = 0.215; // Vertical height
    };
  };

A couple of points are important when you do this:

  • You should set the contact detection threshold (Settings.LimitDistHigh and LimitDistLow) for each step height correctly. Alternatively, you could create reference node for Step1 and use that as PLATE_BASE_FRAME instead of GlobalRef.
  • In the CreateFootContactNodes25 class template, you will need to add a unique name (as I have done in NAME="Step1"). This class template tries to create contact nodes on the foot and when you implement it multiple times for the same foot, then you will have existing reference nodes on the foot with the same name. That is why you need to provide unique names.

Then, you should consider if you want to do this also for the left leg for Step1, in case this is random for different subjects. Likewise, then you will need to define GRF prediction for both legs for step2.

I haven't tried it on a stair-climbing model so I am not 100% sure if it will work perfectly. But i hope it does :slight_smile:

Best regards,
Dave

1 Like

Hi Dave,

The alternative method you mentioned worked perfectly (by creating a reference node for step1 and use that as PLATE_BASE_FRAME instead of GlobalRef)

Thank you so much for your clear and prompt clarification.

Best regards
Jeevan

Hi @jeevan ,
are you also modelling stair descent by any chance?
I've tried to implement the same solution with multiple instances of the GRF prediction for both left and right legs, but during swing phase, when the leg swings through the plane associated with a given step height, it detects a brief contact for a couple of frames that shouldn't be there.
I've played a bit with the various thresholds but I haven't found any solid combination that works yet, so I was curious if you were experiencing something similar.
Otherwise I would need to assign specific "heights" to the left and the right foot, but that requires knowing which sequence of steps the subject is performing, and I wanted a more generic solution.

Thanks for the tip of the unique naming NAME="Step1" @dschander , that's exactly what I was missing :slight_smile: I was trying something different, like creating the 25 contact nodes only in the first GRF_Prediction_RightStep1 instance, and then pointing to the same nodes in the subsequent instances: NODES_FOLDER = .GRF_Prediction_RightStep1.FootNodes, but then it was causing some conflicts with the DrwSphere in ContactSurfaceDistanceAndVelocityDepLinPush.any(10), so your solution works a lot better without modifying any AMMR file.

Thanks!
Enrico

These settings seem to do the job now for stair descent:

    Settings = 
    {
      LimitDistHigh = 0.015;
      LimitDistLow = -0.005;
      LimitVelHigh = 0.4;
    };

Hi Enrico,

I did not attempt the stair descent. At the moment we are doing a climb simulation as a part of another project. However, thanks a lot for sharing settings corresponds to the descent simulation. It might help us in the future.

Best regards
Jeevan

Hi Enrico, Hi Jeevan

Thanks, Enrico, for contributing to the post! You raised a very valid point about contact detection during the swing phase. Besides the threshold velocity, another consideration could be to reduce the radius of the contact detection. This may work well if you know already which foot will land on which step and you can locate the PLATE_BASE_FRAME close enough to ensure contact with the correct foot and exclude the swing phase of the other foot. This is, of course, not a generic solution. Another point that I was wondering about is that the steps are usually rectangular and often you have some overhang of the foot. That is, there is partial contact between the foot and the step. This may be of importance. Ideally, you would like to have contact detection in a cuboid rather than a cylinder, as is currently implemented.

In fact, back in 2020, I was working on a stair climbing model during my PhD and I modified the GRF prediction class template to check for contact detection in a cuboid. I have attached below the three files that you would need,
ContactSurfaceDistanceAndVelocityDepLinPush_Stairs.any (23.4 KB)
FootPlateConditionalContact_Stairs.any (156.2 KB)
ConditionalContactDistanceAndVelocityDepClass_Stairs.any (3.7 KB)

The files contain comments regarding the changes I made so, hopefully, you would be able to understand the changes. You would need to include "FootPlateConditionalContact_Stairs.any" before the Main in your model. These files are supposed to co-exist with the default GRF prediction files (maybe not necessarily in the same folder - but I could be wrong), which are loaded by default in any case.

These files are not as polished as AMMR files since I made them during my PhD. For example, I didn't work on visualization of the trigger volume or the smoothing function at that time :slight_smile:

Best regards,
Dave
p.s: sorry for the delayed reply, I was on vacation.

Hi Dave,

Thanks for sharing more information on this topic. It seems like there is a lot going on with stair climb simulations :slightly_smiling_face:

Best regards
Jeevan

This topic was automatically closed 125 days after the last reply. New replies are no longer allowed.