I am building BVH input files for an AnyBody musculoskeletal model from IMU data (7 lower-body sensors), and I have a question about how the joint rotations in the MOTION section should be defined.
As I understand it, each joint channel in a BVH file holds an Euler-angle rotation relative to the parent joint. In my pipeline I can compute the joint angles in two ways:
Raw joint angles – the rotation between adjacent segments as measured by the IMUs, where a standing (static) pose does not necessarily give exactly zero.
Offset-corrected joint angles – the raw angles minus the angles measured during a static standing trial, so that the standing pose becomes zero by definition.
My question is: which of these should be written into the BVH file for AnyBody? In other words, does AnyBody expect the BVH rotations to be zero in the standing pose defined by the HIERARCHY offsets, or does it expect the "true" joint angles regardless of what the static trial gives?
Any advice or pointers to how others have handled this would be greatly appreciated.
That is an interesting question. First of all, you have collected only lower limb motion data. How are you planning to input Ground Reaction Force (GRF) into your model?
Anyway, I think what you are describing is essentially a calibration step of your recording. Therefore, I think it is important to correct for the offset in the standing posture. I think the question that will answer your question is whether the joint angles you are saving actually reflect the motion of the subject or not. So, if the subject has the knee flexed to 90 degrees, you should see knee angles around 90, and not around, for example, 30 degrees.
In AnyBody, the BVH mocap model is driven by adding virtual markers to the stick figure BVH model. We don't use the actual joint angles from the BVH file to directly drive the human model joints. You can actually make a small model to test your data. You can simply use AnyInputBVH to load your BVH file in the model and add a study to see how the motion of the stick figure model looks. Based on that you can adjust your export pipeline and/or you can adjust the marker protocol.
I am Donghwan, a postdoctoral researcher in the same lab as Seon Wook, and I am replying on his behalf.
Thank you for your advice on using AnyInputBVH. We will use it to visually verify the stick-figure motion in our processed BVH files.
Regarding your question about the GRF: during our experiment, we collected data using IMUs, a motion capture system, and force plates. We have already synchronized the motion capture system with the IMUs (Xsens DOT).
Our first goal is to run the model simulation using IMU data combined with GRF data from the force plates. Our second goal is to run the simulation using only IMU and GRF data (without relying on reflected markers).
Lastly, regarding the offset correction Seon Wook mentioned, I will personally review our data processing pipeline to ensure we applied rigorous inverse multiplication using Quaternions or rotation matrices, rather than simple arithmetic subtraction of Euler angles.
It makes sense now. Besides the temporal synchronization between your IMU and mocap system, one other important aspect for your second goal is to understand how to position the force plates correctly with respect to the IMU data. Small errors in GRF due to inaccuracy in the positioning of the subject on force plate can lead to significant errors in joint reaction force and joint moments.
I was reading my previous reply again, and I just want to add that we don't have so much experience in house regarding preparation of the BVH files. So, I am not completely sure about what's the best way to prepare the raw data from the sensors into a meaningful BVH file with sensible data. When I think about it again, the sensors should normally be able to figure out gravity and their orientation with respect to the vertical. Maybe the process of offsetting for the neutral posture is not needed... but probably it is because the sensors will be attached somewhat differently on every subject. I suppose you can find more information about this somewhere else.
Regarding quaternions, I can add that AnyBody can read in quaternions. I don't know if that helps you or not.