I’m quite new to AnyBody and i’d like to build and drive an external skeleton based on the scaled MoCal full body model. Thus, I need to export the segments, the joint nodes and joint constraints. Unfortunately I cannot find any contants such as e.g. sRel of joint nodes in hdf5 output files. How is it possible to export such model parameters (after running the parameter and optimization study)? Should I use AnyOutputFile or is there a way to include those values in hdf5 outputs?
thanks very much. Using AnyOutputFile for constant values works well now.
Now I need to pass the kinematics from the AnyBody model to my kinematic model (just for rendering purposes) and vice versa (to control AnyBody). The first part runs without any problems. However, in my kinematic model I have to work with global transforms (positions + quaternions) per segment. How can I use that as inputs for kinematic drivers in AnyBody?
I already found this thread: http://forum.anyscript.org/showthread.php?p=20751
Is there any straighter/smarter solution?
thanks! And there is no way to specify the kinematics by directly setting the .r and .Axis properties of each segment?
Another question: in the full body model the leg joints are specified using regular AnyRevoluteJoint and AnySphericalJoint classes whereas the shoulder and arm joints (e.g. the sternoclavicular joint) is modelled with AnyKinRotational, AnyKinLinear and AnyKinEq. In the latter case I have trouble translating that to my own kinematic model. Can I simply replace that with a regular spherical joint? In other words: can I expect that the connected endpoints will coincide after a successful kinematic analysis or is it possible that there will still be any substantial displacement? The same question also relates to the pronation supination joint (combination of joints).
It is not possible to directly write an expression or similar for r and axes, to control these you need to use the different type of motion drivers availble.
In the arms you are right there are used different type of custom joints made using combinations of AnyKinLinear and AnyKinRotational. In some cases i guess there are AnyKinLinears with all three constraints locked… so effectively a sphericaljoint, in other cases it is only a few of the constraints which are locked so then it is not that simple, the reason for this is the body forms closed kinematic loops in the many locations such as shoulder girdle, forearm, hand feets etc. If these are replaced with simpler formulations it may affect the end positions a bit depending on how this is done.
Could you explain more about the purpose for exporting the model?
thanks for your extensive answer. Ok, I think in case of the sternoclavicular, acromioclavicular and glenohumeral joints all AnyKinLinears contraints are locked, so I could model them with pure spherical joints.
Sure, I’ll shortly describe the purpose: after running a kinematic analysis in AnyBody the kinematic model and its kinematics are exported to a different simulation software where we simulate the influence of IMU (intertial measurement unit) to segment calibration on the prescribed kinematics. So, the initial kinematics from AnyBody is assigned to our own kinematic model and altered. These altered trajectories should then be passed back to AnyBody where we’d like to investigate the (biomechanical) effects of our simulated IMU to segment calibration.
Since we have only implemented the most common joint types (spherical, revolute, …), I either have to map the AnyBody arm joints to ours without introducing major kinematic errors or somehow emulate their behaviour.
By the way: it would also be ok to omit some segments (and thus the connecting joints) such as the clavicula and scapula as we don’t plan to place IMUs there. But in that case we would also lose the (altered) trajectories of these segments and the passed back kinematics would then be underdetermined in respect to the AnyBody model. An imaginable solution would be to run again another kinematic analysis in AnyBody based on our altered, underdetermined trajactories. But I don’t know if that is possible.
I am thinking if it would be possible to do sensitivity/influence analysis inside AnyBody so avoiding the export?
If what you do outside AnyBody is to rerun the kinematics with different positions of the IMU sensors wrt to the bones, this might also be possible to do directly inside AnyBody, but this depends on the format of your input data ofcourse, if you IMU provides position data i think it would feasible.
Concernign the last question.
Is there a difference in the format of original intput data and the altered data?
If the format is the same it should just be applied…
If the format contains less info, then you could possibly mix the solution, simplest crude way would be to add all the original drivers on top of the altered drivers with a soft weight on a better solution would be to pick out the DOF which are not driven by the altered data and drive only these with the old data.
If what you do outside AnyBody is to rerun the kinematics with different positions of the IMU sensors wrt to the bones, this might also be possible to do directly inside AnyBody, but this depends on the format of your input data ofcourse, if you IMU provides position data i think it would feasible.
Yes, that's basically what we do and yes, the IMUs provide both estimated global position and orientation data. I have to think about this approach but don't know how to implement that in AnyBody.
Anyway, I think the export works fine now. There are no gaps or jumps between segment nodes connected by joints. So I could simply model all joints as spherical joints.
I'm still confused regarding the (underdetermined) kinematics:
Yes, the inputs (kinematic trajectories) can be different. For now, we can get IMU data for each segment from our simulation. But later on, using real IMUs, we can't attach them to smaller segments such as clavicula, scapula, wrist joint segment, etc.
Ok, you suggest combining the new, altered kinematics with the old DOF wherever the new one is underdetermined. But using global orientations there is no guarantee that the segment's endpoints will meet (i.e. the joint constraints are fulfilled). And using local orientations the error would propagate to the end of the segment chain. Wouldn't it be better to reconstruct the missing DOF by finding new segment rotations that are minimally different compared to the old ones and also fulfill the joint constraints?
A more fundamental question regarding the AnyBody model:
The kinematics analysis example also doesn't generate kinematic trajectories for each DOF in the model. For example, the output kinematics for the left arm are:
Concerning howto to the sensitivity study inside AnyBody, if you IMU is connected to a AnyRefNode then the sRel and ARel of this node will alter the position wrt to the bone. You could run a AnyParamStudy (see tutorial on this) that would take these values (sRel and ARel ) through some variations and for each of them rerun all kinematics...
I'm still confused regarding the (underdetermined) kinematics:
Yes, the inputs (kinematic trajectories) can be different. For now, we can get IMU data for each segment from our simulation. But later on, using real IMUs, we can't attach them to smaller segments such as clavicula, scapula, wrist joint segment, etc.
Ok, you suggest combining the new, altered kinematics with the old DOF wherever the new one is underdetermined. But using global orientations there is no guarantee that the segment's endpoints will meet (i.e. the joint constraints are fulfilled). And using local orientations the error would propagate to the end of the segment chain. Wouldn't it be better to reconstruct the missing DOF by finding new segment rotations that are minimally different compared to the old ones and also fulfill the joint constraints?
I am not sure i fully understand it all, but you are right about the global rotations this is not good since it may affect end positions, i my experience markers virtual or real is best way to ensure hands and feet positions.
Concerning the last question
The reason why the AC joint output is not there is because of the contact between scapula and thorax takes away DOFs. So it would be overdetermined if these DOF was applied. In the spine there is a rhythm which sets all joints according to pelvis/thorax rotatations. The rhythm can be disabled if needed...
We will try the approach using virtual markers and the parameter study within AnyBody.
However, as we later also want to directly track skeletons with IMU data using our tracking algorithms, the export approach is something I’m still working on. In the end, we just want to run an inverese dynamics analysis in AnyBody which is fed with the anatomical joint angles from out tracked skeleton. So, the main difficulty is to come up with a skeleton which is both trackable with real IMUs and anatomically close to the AnyBody skeleton. But that issue is surely completely independent from AnyBody. Nevertheless, I’d like to better understand the modelling of the AnyBody skeleton, so I read about the spine and shoulder rhythm generators and have some more questions:
Aren’t the SC joint DOFs also overdetermining when using the shoulder rhythm? The shoulder rhythm report states that “… a shoulder rhythm has been developed, defining the motion of the scapula and the clavicle as a function of humerus motion”. So, the glenohumeral DOFs should suffice?
Regarding the spine rhythm I found your explanations here http://forum.anyscript.org/archive/index.php/t-2349.html. As I understand, the last 3 columns of the matrix can be seen as weighting vectors relating the segments’ X, Y or Z rotations to the respective T12L1Jnt rotation. So, for example T12L1Jnt.RotX can be found by solving ThoraxPelvis.RotX = DotProduct(weighting_vector_X, (1, 1, 1, 1, 1, 1, 1) * T12L1Jnt.RotX)?
