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

Added projection values from camera when are not defined in the SDF #289

Merged
merged 9 commits into from
Feb 8, 2023

Conversation

ahcorde
Copy link
Contributor

@ahcorde ahcorde commented Nov 18, 2022

Signed-off-by: Alejandro Hernández Cordero ahcorde@gmail.com

🦟 Bug fix

Summary

This PR solves the camera projection matrix values not being reflected properly in /camera_info topic when the tag is not provided. The PR uses the projectionToCameraIntrinsic() from gz-rendering to get the camera intrinsics and update the sdf DOM object and /camera_info topic.

Depends on gazebosim/sdformat#1203

Checklist

  • Signed all commits for DCO
  • Added tests
  • 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)
  • While waiting for a review on your PR, please help review another open pull request to support the maintainers

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.

adityapande-1995 and others added 3 commits November 2, 2022 12:07
Signed-off-by: Aditya <aditya050995@gmail.com>
Signed-off-by: Alejandro Hernández Cordero <ahcorde@gmail.com>
@iche033
Copy link
Contributor

iche033 commented Nov 18, 2022

is this doing something similar to #281?

nvm, I see it targeted at that branch

cameraSdf->SetLensProjectionFy(intrinsicMatrix(1, 1));
cameraSdf->SetLensProjectionCx(intrinsicMatrix(0, 2));
cameraSdf->SetLensProjectionCy(intrinsicMatrix(1, 2));
}
Copy link
Contributor

Choose a reason for hiding this comment

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

remove this duplicate block? (same code as lines 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.

the code above is setting the intrinsic parameters this one is setting the projection parameters

Copy link
Contributor

Choose a reason for hiding this comment

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

ahh I see now 🙈

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm also confused about this. Is the conversion from projection to intrinsic matrix necessary here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Contributor

Choose a reason for hiding this comment

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

Okay, but note that there wouldn't be any way for users to know if the projection values were set by the user to override the values in <intrinsic> or if they were computed based on what's in <intrinsic>. If that's not important, then I'm good with this change. Since this is all very confusing, I would ask that you would add a detailed comment explaining why we're doing this and why the projectionToCameraIntrinsic is being used (i.e how Ogre2 projection matrix is not the same as the projection matrix from <projection>).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@azeey I added a comment here f4b7753

Copy link
Contributor

Choose a reason for hiding this comment

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

Thanks! I would suggest adding "Note that the matrix from Ogre via camera->ProjectionMatrix() has a different format than the projection matrix used in SDFormat. This is why they are converted using projectionToCameraIntrinsic. The resulting matrix is the intrinsic matrix, but since the user has not overridden the values, this is also equal to the projection matrix"

That's my understanding at least. If that's not correct, feel free to modify it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@azeey Added here 32a6241

Copy link
Contributor

Choose a reason for hiding this comment

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

LGTM! Thanks

@iche033 iche033 added the needs upstream release Blocked by a release of an upstream library label Nov 18, 2022
Base automatically changed from aditya/refactor_PR_265 to gz-sensors7 November 21, 2022 08:38
@ahcorde ahcorde self-assigned this Nov 21, 2022
@sea-bass
Copy link

Thank you for kicking this off! We just spent a few days debugging because of this, and when I came here to make an issue I encountered this PR 👍🏻

Signed-off-by: Alejandro Hernández Cordero <ahcorde@gmail.com>
Signed-off-by: Alejandro Hernández Cordero <ahcorde@gmail.com>
@scpeters
Copy link
Member

scpeters commented Dec 5, 2022

Depends on gazebosim/sdformat#1203

I believe this still needs an sdf13 prerelease

@scpeters
Copy link
Member

Depends on gazebosim/sdformat#1203

I believe this still needs an sdf13 prerelease

preparing for prerelease in gazebosim/sdformat#1212

@iche033
Copy link
Contributor

iche033 commented Dec 16, 2022

windows and homebrew builds look fine with the new sdformat 13.3.0-pre1 releease. I think ubuntu builds no longer pick up pre-releases?

@quentingllmt
Copy link
Contributor

Hello, we spent a day working on that too .. ;)
Could you please backport to fortress avec the PR is accepted ? Thanks !

@scpeters
Copy link
Member

scpeters commented Dec 20, 2022

I opened #304 from the tip of this branch using a special branch name along with gazebo-tooling/gzdev@b7e954c to test with prerelease packages on Ubuntu in our CI

@scpeters
Copy link
Member

scpeters commented Dec 20, 2022

I opened #304 from the tip of this branch using a special branch name along with gazebo-tooling/gzdev@b7e954c to test with prerelease packages on Ubuntu in our CI

reminder that we have a plan to simplify this process in gazebo-tooling/gzdev#65

@codecov
Copy link

codecov bot commented Dec 20, 2022

Codecov Report

Merging #289 (45c1761) into gz-sensors7 (d17d535) will increase coverage by 0.07%.
The diff coverage is 100.00%.

@@               Coverage Diff               @@
##           gz-sensors7     #289      +/-   ##
===============================================
+ Coverage        69.54%   69.61%   +0.07%     
===============================================
  Files               35       35              
  Lines             3805     3814       +9     
===============================================
+ Hits              2646     2655       +9     
  Misses            1159     1159              
Impacted Files Coverage Δ
src/CameraSensor.cc 79.88% <100.00%> (+0.51%) ⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

@scpeters
Copy link
Member

this branch was updated, so I merged those changes into #304 to update CI

@ahcorde
Copy link
Contributor Author

ahcorde commented Dec 22, 2022

@azeey and @iche033 CI looks better, I think the failure tests in Jammy are consisten and not part of this PR

Copy link
Contributor

@azeey azeey left a comment

Choose a reason for hiding this comment

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

Still needs an SDFormat release.

@iche033
Copy link
Contributor

iche033 commented Jan 27, 2023

@scpeters, should we do a sdformat 13.3 release for this? Looks like the builds in #304 with the pre-release look good?

@scpeters
Copy link
Member

scpeters commented Feb 6, 2023

@scpeters, should we do a sdformat 13.3 release for this? Looks like the builds in #304 with the pre-release look good?

sure, that sounds good

@iche033 iche033 mentioned this pull request Feb 7, 2023
7 tasks
@iche033
Copy link
Contributor

iche033 commented Feb 8, 2023

builds look good with the new sdformat 13.3.0 release, merging.

@iche033 iche033 merged commit 354dbb9 into gz-sensors7 Feb 8, 2023
@iche033 iche033 deleted the ahcorde/7/projection_matrix branch February 8, 2023 19:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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.

7 participants