-
Notifications
You must be signed in to change notification settings - Fork 434
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
--[BE] - SensorAttributes/Managers refactor Part 1 #2502
Conversation
6eab72b
to
b22de05
Compare
52b14cc
to
a2bbbe5
Compare
99e44bc
to
6b449eb
Compare
…fulfill this role.
This code will be removed when SensorSpecs are removed.
… to user_defined.
d9d788a
to
a471ac3
Compare
cab7613
to
29f0d22
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like a good step toward the planned design. 👍
Added some thoughts about next steps mostly.
// TODO : Rename attributes to appropriate name and register | ||
// Build name using more than just spec uuid? | ||
std::string newAttrHandle = sensorSpec->uuid; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably need some de-duplication system for unique naming. Spec will go away, so this doesn't need to be tied to that field. Naming could be a part of registering if it doesn't come from a filename for example.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, postCreateRegister calls preRegisterObjectFinalize below, which does this (makes sure the name is unique - uuid becomes uuid_XXXX where XXXX is a unique number.
void SensorAttributesManager::setValsFromJSONDoc( | ||
AbstractSensorAttributes::ptr attribs, | ||
const io::JsonGenericValue& jsonConfig) { | ||
// TODO support loading values from JSON docs for each type of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would be good to have 1 default for each sensor type, maybe in test_assets? Or programmatically created and added like prims.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I planned on doing that in the 2nd PR.
Motivation and Context
This PR is the first part of the Sensor refactor effort, responsible for enabling the creation of Sensor-type-specific Attributes from provided SensorSpecs, such that the attributes themselves will be used to create the Sensors (which will be implemented in Part 2).
Specifically, this PR provides the following :
How Has This Been Tested
Locally c++ tests pass. New tests were added to test the valid creation and data content of Attributes from SensorSpecs.
Types of changes
Checklist