-
Notifications
You must be signed in to change notification settings - Fork 275
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
Add EnvironmentalData component #1616
Conversation
2740c0e
to
10a679d
Compare
/// \brief Private data class for EnvironmentalDataLoader | ||
class EnvironmentalDataLoaderPrivate | ||
{ | ||
public: QString dataPath; |
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.
Could you document these members?
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.
Done in 16072a7
} | ||
} | ||
|
||
EnvironmentalDataLoader::EnvironmentalDataLoader() |
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.
Nit: Add function delimiters.
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.
Done in 16072a7
{ | ||
if (this->dataPtr->needsUpdate) | ||
{ | ||
std::lock_guard<std::mutex> lock(this->dataPtr->mutex); |
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.
Should we move this lock before the if
above?
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.
@caguero that's the point of using an atomic boolean: avoid unnecessary mutex locking on every simulation step.
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.
Ah, I didn't realize needsLoad
was atomic. Then you can move the lock
after setting needsLoad
to false, right?
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.
@caguero Yes and no. No in the general case, as you could potentially race with another thread to reach the lock. Yes in this particular case as we know there won't more than one thread exercising this execution path (IIRC there's just one thread stepping the simulation).
I went for the generally correct case out of habit. We can move it out of the lock if you want.
267150c
to
16072a7
Compare
Removed the This PR can either be merged into |
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.
Looking good, just waiting for CI to be happy after releasing common
.
{ | ||
if (this->dataPtr->needsUpdate) | ||
{ | ||
std::lock_guard<std::mutex> lock(this->dataPtr->mutex); |
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.
Ah, I didn't realize needsLoad
was atomic. Then you can move the lock
after setting needsLoad
to false, right?
It doesn't look like CI will pass. I'll go ahead and cherry-pick this to our custom branch for the time being. We can come back and merge this once CI stabilizes again. |
try | ||
{ | ||
using ComponentT = components::EnvironmentalData; | ||
auto component = ComponentT{common::IO<ComponentT::Type>::ReadFrom( |
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.
My understanding is that each world can have only one data frame file. What if two instances are loaded?
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.
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.
Just a few clarifications I wanted to ask about.
FrameT frame; | ||
|
||
/// \brief Spatial reference for data coordinates. | ||
ReferenceT reference; |
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.
I assume CoordinateType::SPHERICAL
means we use lat-long. On the other hand LOCAL
frame makes no sense here. GLOBAL
and ECEF
also makes sense, however I don't know if we want to support ECEF
right away?
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.
@arjo129 I'll start by saying that I chose to use gz::math::SphericalCoordinates
as a reference only because it was convenient. Regarding coordinate system types, what I gather from its implementation is that LOCAL
is a rotation away (that specified by heading offsets in spherical coordinates) from GLOBAL
. In any case, no code should have to deal with these coordinate systems explicitly. It's just how the data coordinates are expressed.
I assume
CoordinateType::SPHERICAL
means we use lat-long.
It means the data uses lat-lon coordinates. Code may as well be using global cartesian coordinates. As long as the conversion gets carried out before looking up the frame (see DVL code for an example), it'll be fine. Same for ECEF
.
using FrameT = common::DataFrame<std::string, T>; | ||
using ReferenceT = math::SphericalCoordinates::CoordinateType; | ||
|
||
/// \brief Instantiate environmental data. |
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.
Knit: There's a bit of whitespace at EOL issue here. Should be caught when running make codecheck
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.
Done in 36c444d.
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.
Sorry as I work through my sensor implementation I spotted something else.
@@ -0,0 +1,89 @@ | |||
/* | |||
* Copyright (C) 2019 Open Source Robotics Foundation |
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.
Knit: License header should be 2022
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.
Done in ebe9d63.
const gz::sim::UpdateInfo &, | ||
gz::sim::EntityComponentManager &_ecm) | ||
{ | ||
if (!std::exchange(this->dataPtr->loaded, true)) |
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.
Is there a reason we implement PreUpdate
when we probably could get away with doing this in Configure
?
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.
@arjo129 it used to be that way. Thing is, we can't query the world SDF (root) path until it's fully loaded, and that has to wait for all world plugins (including this one) to load and configure.
Oh well then it's fine.
…On Mon, Sep 5, 2022 at 8:14 PM Michel Hidalgo ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In src/systems/environment_preload/EnvironmentPreload.cc
<#1616 (comment)>:
> +//////////////////////////////////////////////////
+void EnvironmentPreload::Configure(
+ const Entity &/*_entity*/,
+ const std::shared_ptr<const sdf::Element> &_sdf,
+ EntityComponentManager &/*_ecm*/,
+ EventManager &/*_eventMgr*/)
+{
+ this->dataPtr->sdf = _sdf;
+}
+
+//////////////////////////////////////////////////
+void EnvironmentPreload::PreUpdate(
+ const gz::sim::UpdateInfo &,
+ gz::sim::EntityComponentManager &_ecm)
+{
+ if (!std::exchange(this->dataPtr->loaded, true))
@arjo129 <https://github.com/arjo129> it used to be that way. Thing is,
we can't query the world SDF (root) path until it's fully loaded, and that
has to wait for all world plugins (including this one) to load and
configure.
—
Reply to this email directly, view it on GitHub
<#1616 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEEMQCSUKRQZN5UF4C3QRDV4XPY7ANCNFSM54ZZQFOQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Pending on gazebosim/gz-common#460. |
Re-targeting to Garden. |
Signed-off-by: Michel Hidalgo <[email protected]>
Signed-off-by: Michel Hidalgo <[email protected]>
Signed-off-by: Michel Hidalgo <[email protected]>
Signed-off-by: Michel Hidalgo <[email protected]>
Signed-off-by: Michel Hidalgo <[email protected]>
- Resolve paths relative to SDF parent path - Avoid template instantiation in plugins Signed-off-by: Michel Hidalgo <[email protected]>
Signed-off-by: Michel Hidalgo <[email protected]>
Signed-off-by: Michel Hidalgo <[email protected]>
Signed-off-by: Michel Hidalgo <[email protected]>
Signed-off-by: Michel Hidalgo <[email protected]>
Signed-off-by: Michel Hidalgo <[email protected]>
Signed-off-by: Michel Hidalgo <[email protected]>
Signed-off-by: Michel Hidalgo <[email protected]>
9534e89
to
7f38d57
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 good to me!
We're having a build regression on gz-sim7 debbuilder Reference build: https://build.osrfoundation.org/job/gz-sim7-debbuilder/184/ Log output:
And then
I think it could be caused by |
@Crola1702 looks like the |
@Crola1702 and I looked at this together, the dependency on libgz-common5-io-dev wasn't added to the debian build dependency data for this package which caused the regression. gazebo-release/gz-sim7-release#18 should resolve that. |
🎉 New feature
Summary
This patch adds an
EnvironmentalData
component that can hold aDataFrame
worth of user-defined data for plugins to leverage. Additionally, preload and (interactive) load plugins are included.Needs gazebosim/gz-common#402.
Test it
Reviewers may try the loader GUI plugin manually.
Checklist
codecheck
passed (See contributing)Note to maintainers: Remember to use Squash-Merge and edit the commit message to match the pull request summary while retaining
Signed-off-by
messages.