Feature #2449
Modify existing types to completely represent the information available through Kinect2
Status: | Resolved | Start date: | 11/27/2015 | |
---|---|---|---|---|
Priority: | Normal | Due date: | ||
Assignee: | J. Wienke | % Done: | 100% | |
Category: | Type Proposal | |||
Target version: | Robotics Service Bus - rsb-0.13 |
Description
I use the sandbox:rst.tracking.TrackedPosture3DFloat datatype datatype to publish kinect skeletons. I make two proposals:
- regarding stable:rst.kinematics.Posture3DFloat
Since the kinect also offers a joint rotation (which, as far as I know, represents the global rotation of the bone connecting it to it's parent in a coordinate system, where the y-axis is aligned with the bone) it would be cool if this information could be transmitted.
- regarding sandbox:rst.tracking.TrackedPosture3DFloat
There are several skeleton tracking systems out there and they all different sets of names of skeletons etc. It would be helpful to include such info inside the data type so only the datatype and the definition by the tracking system is required to understand the data. At the moment the software publishing the data also plays a role since it defines the order of the joints transmitted.
Associated revisions
Added name and rotation to rst.kinematics.Posture3DFloat
fixes #2449
Signed-off-by: Johannes Wienke <jwienke@techfak.uni-bielefeld.de>
History
#1 Updated by J. Wienke over 7 years ago
- Status changed from New to In Progress
- Assignee set to J. Wienke
- Target version set to rsb-0.13
- Can we use a constraint that the lengths of both repeated fields must match in case the second one is used?
- Since the joints are actually represented in
Posture3DFloat
, to my mind, it would make more sense to have the repeated field for the joint names there. Even if we do not track, someone might still give names to such entities.
#2 Updated by J. Wienke about 7 years ago
ping?
#3 Updated by M. Goerlich about 7 years ago
- File 0001-Added-name-and-rotation-to-rst.kinematics.Posture3DF.patch added
Both ideas sound fine. I searched for more information about constraints but their does not seem to be a real language behind this, is it?
By now i just added:
// @constraint(len(.rotation) = len(.position)) // @constraint(len(.name) = len(.position))
Since repeated fields are unused if the length is zero you would actually have to use some "or" keyword. Is there anything planned for this? If I could just use the word "or" i would write something like:
len(.rotation) = 0 or len(.rotation) = len(.position)
#4 Updated by J. Wienke about 7 years ago
M. Goerlich wrote:
Both ideas sound fine. I searched for more information about constraints but their does not seem to be a real language behind this, is it?
Not yet ;)
Since repeated fields are unused if the length is zero you would actually have to use some "or" keyword. Is there anything planned for this? If I could just use the word "or" i would write something like:
[...]
That would be ok. Just add parens to clarify the conditions.
#5 Updated by M. Goerlich about 7 years ago
- File deleted (
0003-add-rotation-to-rst.kinematics.Posture3DFloat.patch)
#6 Updated by M. Goerlich about 7 years ago
- File deleted (
0004-Add-name-of-posture-element.patch)
#7 Updated by M. Goerlich about 7 years ago
- File deleted (
0001-Added-name-and-rotation-to-rst.kinematics.Posture3DF.patch)
#8 Updated by M. Goerlich about 7 years ago
Sorry for the long delay. I modified the constraints as mentioned before.
#9 Updated by M. Goerlich about 7 years ago
- Status changed from In Progress to Resolved
- % Done changed from 0 to 100
Applied in changeset rst-proto|01e1e2beaa19fa2a85ba457c60ec6ce3ee19831a.