importing forces and scalars to Vicon Nexus?

[Mikko Pohjola]

I'm doing my master's thesis on motion analysis. I look forward to collecting all data (motion, force, emg) with Vicon Nexus 1.8. in the future, but currently I have non-standard force data recorded with external software alongside motion capture data recorded with Vicon Nexus 1.7.1. I'd like to know if it's possible to import and marry/synchronize externally recorded non-standard force data (+ some scalars possibly as trajectories) with the motion data. I'm aware of e.g. C3DServer, Vaquita Software plug-ins and b-tk Biomechanical toolkit, but I'm still unsure if and how well they will work in my case. I would be grateful if anyone familiar with this issue would be able to provide some answers to any of the questions below. It seems that most commonly motion data is exported to other software for further analysis with other data, but I would like to know if it's possible to go the other way as well.

1. Is it possible, and how, to import data to Vicon Nexus 1.7.1 or 1.8.3? Particularly, does Nexus allow creation of new analog or trajectory channels that were not determined when the trial was recorded?
2. How can/should the imported data be married/synchronized with the motion data? E.g. should the recording frequency of imported data be decreased to match the motion data? Do the lengths of the imported data need to be exactly the same as in the motion data? A trigger signal is recorded in both Nexus and the external systems, but the trigger does not always locate within the analyzable part of the motion data (other data available for longer periods than motion data). Gut feeling is that the data to be imported should be manipulated as ready as possible before importing.
3. How can the imported data channels be called from a BodyLanguage script? Are there perhaps some useful and available examples for calling/using measured forces in dynamic BodyLanguage models?

Thanks in advance to all responders!

Mikko Pohjola
University of Jyväskylä, Finland

[Lasse Roren]

Re: importing forces and scalars to Vicon Nexus?

Dear Mikko,

I've faced similar issues in the past, and I have also got some experience with the C3D file format and the various Vicon SDKs for data processing, so perhaps I can help you a bit.

1. The plug-ins that work through the Vicon processing pipeline SDK cannot create new analog channels or force plates. This means that unless you have a "dummy" force plate and analog channels in your trial which you are happy to overwrite with the imported data, you cannot really use this strategy - the Vaquita plug-ins also have this limitation. The only other way of importing external force data is to modify the C3D file outside of Nexus, and then import the C3D afterwards. This is possible through, for example, the C3DServer toolkit from Motion Lab Systems, or by reading/writing the file format manually. The C3DServer does allow you to use both .NET and MatLab programming environments, check out www.c3d.org for more info.

2. If you choose to add the force data by reading the C3D file, adding the force data and then writing it back out, then the force data must be written with the same frequency as any other analog data already present in the C3D file, which again must be an integer multiple of the marker data's capture frequency, for example 100Hz marker data/1000Hz analog data. If the C3D file contains no analog data, then you can choose any frequency that is an integer multiple. As for triggering - the most sensible way to do this would be to scan the data for the trigger signal and time shift the analog data accordingly before writing out the C3D file, to make sure that everything is synchronized within the file. It is also possible to use the "delay compensation" function in Nexus to adjust data after the C3D has been imported, but I would recommend trying to store all the data in the C3D file already synchronized.

3. Once the data is written correctly into the C3D file as a force plate, Vicon Nexus will interpret the data as a "proper" force plate, and you will be able to use all the normal BodyLanguage script functions to calculate reactions.

Best regards,

[Mikko Pohjola]

Re: importing forces and scalars to Vicon Nexus?

Dear Lasse,

Thanks a lot for your help! Apparently the way to go is to consider the alternatives for modifying the c3d files externally. This brings about couple of further questions. If anyone has experiences on these, comments are very welcome.

1. As the eclipse database in Nexus contains information about database structure and relationships between database contents in different file types (enf, eni), do these files also need to be modified if the c3d files are modified? Or can this be avoided just by creating a new database to a new location where the modified c3d files are stored?

2. How much manual work does it require and how error risky is it to modify c3d files (one by one I believe) in the above mentioned manner? What I'm thinking is that while probably doing this for a few files in no big problem (besides the effort of first learning how to do it) is it a sensible to consider doing it for hundreds of trials on tens of subjects? Has someone perhaps invented some ways to automatically modify c3d files in a corresponding manner?

Best Regards,
Mikko Pohjola

[Edmund Cramp]

Re: importing forces and scalars to Vicon Nexus?

Dear Mikko,

If you simply want to modify a lot of C3D files to add analog channels, modify parameters etc then you may find our C3Deditor program useful. This has a "batch" mode that allows you to set up a sequence of operations (such as adding analog channels, analog parameters, force plates etc) and then perform the sequence on a selection of C3D files ... or on all the C3D files in a directory tree. The modified files can be saved with a new name so it's pretty much risk free - generally you would use the C3Deditor to manually modify a single file to check that the planned edits meet your needs. Once you have everything organized then you create a batch command file to repeat the edits on all of the other C3D files.

You would still need to insert your new analog data into the files as a separate operation using the tools that you mention in the first post but this is relatively easy if the analog channels and parameters already exist in the C3D files when you open them. The C3Deditor is also very useful if you have a lot of C3D files and discover that you need to change a parameter in all of them ... typically scaling factors and force plate locations.

One other useful feature is that the C3Deditor can change the sample rates of the data in the C3D file so if your original files contain data recorded at 1000Hz and the data that you want to add is sampled at 1200Hz then you can use the C3Deditor to modify the existing data to match the imported data rate.

[Lasse Roren]

Re: importing forces and scalars to Vicon Nexus?

Dear Mikko,

1. The ENF/ENI files do not contain information that needs to be modified. You can, in other words, modify the C3D file where it is and retain the existing Eclipse structure. Of course, it would be sensible to back up the unchanged C3D files.

2. Depends how much you already know about programming and the C3D file format, and how complex it is to "translate" the data from your external system to something that makes sense in the C3D file. The easiest would be to store 3 x forces and 3 x moments in the C3D file, so if the data from your external system is in this format or can easily be translated to this format then it shouldn't be too bad - a little custom-written piece of software would be able to automatically merge the information in the C3D file and the external data file.

I have written similar things in the past, and would be able to offer professional services to solve your problem. I will send you an email with further details.

Best regards,

[Mikko Pohjola]

Re: importing forces and scalars to Vicon Nexus?

Thanks Lasse and Edmund for your help. The range of possibilities seems much clearer now. I will discuss and do some exploring of different options with others involved in the project, and then we'll decide how to get going with the case.

Of course additional comments are still very welcome!

BR,
Mikko