Skip to content
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

Merged
merged 14 commits into from
Nov 14, 2022

Conversation

hidmic
Copy link
Contributor

@hidmic hidmic commented Jul 27, 2022

🎉 New feature

Summary

This patch adds an EnvironmentalData component that can hold a DataFrame 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

  • Signed all commits for DCO
  • Added tests
  • Added example and/or tutorial
  • Updated documentation (as needed)
  • Updated migration guide (as needed)
  • Consider updating Python bindings (if the library has them)
  • codecheck passed (See contributing)
  • All tests passed (See test coverage)

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.

@hidmic hidmic added the MBARI-LRAUV Sponsored by MBARI-LRAUV project: https://github.com/osrf/lrauv label Jul 27, 2022
@hidmic hidmic mentioned this pull request Jul 27, 2022
22 tasks
@chapulina chapulina added enhancement New feature or request 🌱 garden Ignition Garden labels Jul 27, 2022
@chapulina chapulina added the needs upstream release Blocked by a release of an upstream library label Jul 27, 2022
@hidmic hidmic force-pushed the hidmic/environmental-data branch from 2740c0e to 10a679d Compare August 3, 2022 18:38
@hidmic hidmic marked this pull request as ready for review August 3, 2022 18:38
@hidmic hidmic requested a review from chapulina as a code owner August 3, 2022 18:38
@hidmic hidmic requested a review from caguero August 3, 2022 18:43
@chapulina chapulina added 🌱 garden Ignition Garden and removed 🌱 garden Ignition Garden labels Aug 6, 2022
/// \brief Private data class for EnvironmentalDataLoader
class EnvironmentalDataLoaderPrivate
{
public: QString dataPath;
Copy link
Contributor

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?

Copy link
Contributor Author

@hidmic hidmic Aug 9, 2022

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()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: Add function delimiters.

Copy link
Contributor Author

@hidmic hidmic Aug 9, 2022

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);
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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?

Copy link
Contributor Author

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.

@hidmic hidmic force-pushed the hidmic/environmental-data branch from 267150c to 16072a7 Compare August 9, 2022 20:15
@chapulina chapulina removed the 🌱 garden Ignition Garden label Aug 10, 2022
@chapulina
Copy link
Contributor

Removed the Garden label because we're past feature freeze ❄️ .

This PR can either be merged into main and backported to gz-sim7 after the stable release, or retargeted to gz-sim7 and merged after the stable release (i.e. October).

Copy link
Contributor

@caguero caguero left a 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);
Copy link
Contributor

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?

@hidmic
Copy link
Contributor Author

hidmic commented Aug 18, 2022

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(
Copy link
Contributor

@arjo129 arjo129 Aug 22, 2022

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What if two instances are loaded?

@arjo129 last component wins, there can only be one component of a given type per entity (and we always target the world entity). See here then here.

Copy link
Contributor

@arjo129 arjo129 left a 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;
Copy link
Contributor

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?

Copy link
Contributor Author

@hidmic hidmic Sep 5, 2022

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.
Copy link
Contributor

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in 36c444d.

Copy link
Contributor

@arjo129 arjo129 left a 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
Copy link
Contributor

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

Copy link
Contributor Author

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))
Copy link
Contributor

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?

Copy link
Contributor Author

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.

@arjo129
Copy link
Contributor

arjo129 commented Sep 5, 2022 via email

@hidmic
Copy link
Contributor Author

hidmic commented Oct 17, 2022

Pending on gazebosim/gz-common#460.

@hidmic hidmic changed the base branch from main to gz-sim7 October 17, 2022 20:30
@hidmic hidmic requested a review from mjcarroll as a code owner October 17, 2022 20:30
@hidmic
Copy link
Contributor Author

hidmic commented Oct 17, 2022

Re-targeting to Garden.

@nkoenig nkoenig mentioned this pull request Oct 18, 2022
7 tasks
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]>
@hidmic hidmic force-pushed the hidmic/environmental-data branch from 9534e89 to 7f38d57 Compare November 11, 2022 22:50
@hidmic
Copy link
Contributor Author

hidmic commented Nov 14, 2022

Alright, CI is finally mostly green. Test failures on Windows are unrelated. @arjo129 @caguero may I ask you to do a final review?

@hidmic hidmic requested review from caguero and arjo129 and removed request for chapulina November 14, 2022 19:15
Copy link
Contributor

@caguero caguero left a 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!

@hidmic hidmic merged commit 2d19f93 into gazebosim:gz-sim7 Nov 14, 2022
@hidmic hidmic deleted the hidmic/environmental-data branch November 14, 2022 23:08
@Crola1702
Copy link
Contributor

Hi @hidmic @caguero

We're having a build regression on gz-sim7 debbuilder

Reference build: https://build.osrfoundation.org/job/gz-sim7-debbuilder/184/

Log output:

CMake Warning at /usr/share/cmake-3.16/Modules/CMakeFindDependencyMacro.cmake:47 (find_package):
  By not providing "Findgz-common5-io.cmake" in CMAKE_MODULE_PATH this
  project has asked CMake to find a package configuration file provided by
  "gz-common5-io", but CMake did not find one.

And then

CMake Error at /usr/share/cmake/gz-cmake3/cmake3/GzConfigureBuild.cmake:73 (message):
  -- BUILD ERRORS: These must be resolved before compiling.
Call Stack (most recent call first):
  CMakeLists.txt:231 (gz_configure_build)


CMake Error at /usr/share/cmake/gz-cmake3/cmake3/GzConfigureBuild.cmake:75 (message):
  -- 	Missing dependency [gz-common5] (Components: profiler, events, av, io)
Call Stack (most recent call first):
  CMakeLists.txt:231 (gz_configure_build)


CMake Error at /usr/share/cmake/gz-cmake3/cmake3/GzConfigureBuild.cmake:77 (message):
  -- END BUILD ERRORS

I think it could be caused by io component added in this PR

@hidmic
Copy link
Contributor Author

hidmic commented Nov 15, 2022

@Crola1702 looks like the io component in gz-common5 was not built/released.

@nuclearsandwich
Copy link

@Crola1702 looks like the io component in gz-common5 was not built/released.

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request MBARI-LRAUV Sponsored by MBARI-LRAUV project: https://github.com/osrf/lrauv needs upstream release Blocked by a release of an upstream library
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

8 participants