Get desktop application:
View/edit binary Protocol Buffers messages
The main service definition
(message has no fields)
(message has no fields)
(message has no fields)
(message has no fields)
(message has no fields)
Used in:
Used in:
Used in:
Used in:
Concatenates size, pos, euler, and color into a single vector, saving a few bytes of proto headers
Used in:
4 ints: from top left, size
Used in:
Concatenates radius, height, pos, euler, and color into a single vector, saving a few bytes of proto headers
Used in:
Concatenates radius, height, pos, euler, and color into a single vector, saving a few bytes of proto headers
Used in:
Concatenates radius, height, pos, euler, and color into a single vector, saving a few bytes of proto headers
Used in:
Used in:
Used in:
Concatenates size, pos, euler, and color into a single vector, saving a few bytes of proto headers
Used in:
4 ints: from top left, size
4 floats: min x, max x, min y, max y
Used in:
4 ints: from top left, size
4 floats: min x, max x, min y, max y
Used in:
4 ints: from top left, size
3 floats: min, max, value
Used in:
Concatenates radius, pos, and color into a single vector, saving a few bytes of proto headers
Used in:
4 ints: from top left, size
Used in:
Used in:
Used in:
Used in:
Used in:
Used in:
Used in:
Used in:
Used in:
Used in:
Used in:
Used in:
,Used in:
Used in:
Used in:
Used in:
Used in:
Used in:
Used in:
Used in:
Used in:
4 floats: min x, max x, min y, max y
Used in:
4 floats: min x, max x, min y, max y
Used in:
Used in:
Used in:
Used in:
Used in:
Used in:
Used in:
2 ints: from top left
Used in:
2 ints: width, height
This is the size of each frame in bytes. This should be constant across all frames in the file, to allow easy seeking.
This has all the global information about each pass
This is the global configuration of the skeleton
The version number for this file format
An optional link to the web where this subject came from
Any text-based notes on the subject data, like citations etc
Subject details
Details about the marker data as it will appear on each frame
Details about the imu data as it will appear on each frame
Details about the EMG data as it will appear on each frame
This is how many samples of each EMG we get per timestep (the multiple of the mocap sampling frequency for our EMG data, usually ~10)
Details about the exo DOF data as it will appear on each frame
Details about the subject tags provided on the AddBiomechanics platform
This is what the user has tagged this subject as, in terms of data quality
Used in:
The values for all the DOFs
This is an array of 6-vectors, one per ground contact body
These are the original force-plate data in world space, one per ground contact body
These are the center of mass kinematics
Relevant physical data transformed into the root (probably pelvis) frame
These are 6-vec's per contact body, so each length N*6
These are 3-vec's per contact body, so each length N*3
One 3-vec per joint
One 3-vec per joint
The recent history of root transformations, expressed in the current root frame
We include this to allow the binary format to store/load a bunch of new types of values while remaining backwards compatible.
These are marker observations on this frame, with all NaNs indicating that that marker was not observed on this frame
These are IMU observations on this frame, with all NaNs indicating that that imu was not observed on this frame
These are the EMG observations on this frame
These are the exo observations on this frame
These are the raw force plate readings, per force plate, without any assignment to feet or any post-processing
Used in:
This is the only array that has the potential to be somewhat large in memory, but we really want to know this information when randomly picking frames from the subject to sample.
This is how many frames are in this trial
This is the timestep used in this trial (assumed constant throughout the trial)
These are the processing passes that were applied to this trial
This records the tags this trial was assigned with on the AddBiomechanics platform
This is the number of force plates present on this trial
If there are force plates, we can optionally include each force plate's corners here, concatenated as 4 3-vectors per plate
This is true if we guessed the marker names without any ground truth from the user.
This is the original name of the source trial, before we (probably) split it into pieces during processing
This is the split index within the original trial -- 0 if we didn't split or if we're the first split
This is the shorthand for values from the original trial
This is the type of trial we're dealing with
This is the detected features of this trial
Many of the ML tasks we want to support from SubjectOnDisk data include effectively predicting the results of a downstream processing task from an upstream processing task. Trivially, that's predicting physics from raw motion. Hopefully soon, that may also include things like predicting IMU joint accelerations from raw kinematics.
Used in:
This is the type of the processing pass that generated this data
If we're projecting a lower-body-only dataset onto a full-body model, then there will be DOFs that we don't get to observe. Downstream applications will want to ignore these DOFs.
If we didn't use gyros to measure rotational velocity directly, then the velocity on this joint is likely to be noisy. If that's true, downstream applications won't want to try to predict the velocity on these DOFs directly.
If we didn't use accelerometers to measure acceleration directly, then the acceleration on this joint is likely to be noisy. If that's true, downstream applications won't want to try to predict the acceleration on these DOFs directly.
This records the marker error for each frame in this trial.
This records the residual of the inverse dynamics solution for each frame in this trial.
This records the residual of the inverse dynamics solution for each frame in this trial.
This is for allowing the user to pre-filter out data where joint velocities are above a certain "unreasonable limit", like 50 rad/s or so
If we're doing a lowpass filter on this pass, then what was the cutoff frequency of that filter?
If we're doing a lowpass filter on this pass, then what was the order of that (Butterworth) filter?
If we clipped background noise on the force plates this pass, then this is the cutoff we used for each plate
If we ran an acceleration minimizing smoother on this pass, then this is the regularization weight we used to track the original positions
If we ran an acceleration minimizing smoother on this pass, then this is the regularization weight we used to track the original forces
Used in:
Used in:
, ,