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

IMU custom_rpy tag parsing added #178

Merged
merged 8 commits into from
Dec 21, 2021

Conversation

adityapande-1995
Copy link
Contributor

@adityapande-1995 adityapande-1995 commented Dec 14, 2021

Signed-off-by: Aditya [email protected]

🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸

🎉 New feature

Closes #174

Summary

According to REP 145, an IMU can report orientation with respect to the world, or some given reference frame. The method SetOrientationReference enables this, but this cannot be set via sdf currently.
The orientation_reference_frame tag ( http://sdformat.org/spec?ver=1.9&elem=sensor#imu_orientation_reference_frame) exposes this, but it is ignored currently in the Load method for the IMU sensor. This PR aims to set reference orientation when the localization tag is set to CUSTOM and custom_rpy is set to some non zero angles.

Test it

I've added a test case, but if one wants to run it independently, you can use the following sdf snippet :

<?xml version='1.0'?>
<sdf version='1.6'>
 <model name='m1'>
  <link name='link1'>
    <sensor name='imu_sensor' type='imu'>
      <topic>imu_test</topic>
      <update_rate>1</update_rate>
      <imu>
      <orientation_reference_frame>
      <localization>CUSTOM</localization>
      <custom_rpy>1.570795 0 0</custom_rpy>
      </orientation_reference_frame>
      </imu>
      <always_on>1</always_on>
      <visualize>true</visualize>
    </sensor>
  </link>
 </model>
</sdf>

After first update, if the IMU orientation is (0 0 0) by default, it should be now (-1.570795 0 0) as the reference axis has been modified in the sdf.

Checklist

  • Signed all commits for DCO
  • Added tests
  • Added example and/or tutorial
  • Updated documentation (as needed)
  • Updated migration guide (as needed)
  • 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

🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸

@github-actions github-actions bot added the 🏯 fortress Ignition Fortress label Dec 14, 2021
@adityapande-1995 adityapande-1995 changed the title Imu custom_rpy exposed via sdf, added test case Imu custom_rpy exposed via sdf Dec 14, 2021
@adityapande-1995 adityapande-1995 changed the title Imu custom_rpy exposed via sdf IMU custom_rpy tag parsing added Dec 14, 2021
src/ImuSensor.cc Outdated Show resolved Hide resolved
@codecov
Copy link

codecov bot commented Dec 14, 2021

Codecov Report

Merging #178 (4848461) into ign-sensors6 (9c075d0) will increase coverage by 0.05%.
The diff coverage is 100.00%.

Impacted file tree graph

@@               Coverage Diff                @@
##           ign-sensors6     #178      +/-   ##
================================================
+ Coverage         75.96%   76.01%   +0.05%     
================================================
  Files                27       27              
  Lines              2754     2760       +6     
================================================
+ Hits               2092     2098       +6     
  Misses              662      662              
Impacted Files Coverage Δ
src/ImuSensor.cc 91.30% <100.00%> (+0.47%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9c075d0...4848461. Read the comment docs.

Copy link
Member

@scpeters scpeters left a comment

Choose a reason for hiding this comment

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

can you add another test case with a non-empty custom RPY parent frame?

src/ImuSensor.cc Outdated
_sdf.ImuSensor()->CustomRpy()));
}
} else {
ignerr << "This tag is not yet supported" << std::endl;
Copy link
Member

Choose a reason for hiding this comment

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

I'm not sure an error message is needed here, since ign-gazebo will handle any other types of <localization>.

You may consider a warning message if CustomRpyParentFrame() is not an empty string, since we don't currently support that use case.

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 !

Copy link
Member

Choose a reason for hiding this comment

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

thanks; I just pushed 4848461 to update the verbosity level used by the test so that the ignwarn message will show in the console output

Copy link
Contributor

Choose a reason for hiding this comment

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

since ign-gazebo will handle any other types of

@scpeters , how did you envision this being implemented?

The IMU system in ign-gazebo should have knowledge of the current spherical coordinates, and it also should have access to sdf::Imu::Localization, so I guess it could call sensors::ImuSensor::SetOrientationReference as needed.

An alternative approach, if we want to keep most of the frame-conversion logic in ign-sensors, would be to expose an API like sensors::ImuSensor::SetWorldFrameOrientation so that the Gazebo system just lets the sensor know what the world is using, and the sensor performs all the calculations. I like this option better because it keeps all the SDF parsing within the sensor class.

Also worth noting that we don't support world frames other than ENU right now, so we should be able to default to that for a long time.

Copy link
Member

Choose a reason for hiding this comment

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

I've added an example world with multiple IMU sensors with different Localization values in gazebosim/gz-sim@051f777

The IMU system in ign-gazebo should have knowledge of the current spherical coordinates, and it also should have access to sdf::Imu::Localization, so I guess it could call sensors::ImuSensor::SetOrientationReference as needed.

An alternative approach, if we want to keep most of the frame-conversion logic in ign-sensors, would be to expose an API like sensors::ImuSensor::SetWorldFrameOrientation so that the Gazebo system just lets the sensor know what the world is using, and the sensor performs all the calculations. I like this option better because it keeps all the SDF parsing within the sensor class.

can you describe the data types that you envision that sensors::ImuSensor::SetWorldFrameOrientation would use? I'm not sure exactly what you are proposing

Copy link
Contributor

Choose a reason for hiding this comment

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

humm ok I see there's a use case there. Then I guess the heading needs to be passed to the IMU as well

Copy link
Member

Choose a reason for hiding this comment

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

in that case does sensors::ImuSensor::SetWorldFrameOrientation(const Quaterniond &_rot, const WorldFrameEnumType _relativeTo = ENU); seem like a reasonable API?

Copy link
Contributor

Choose a reason for hiding this comment

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

So in that case, ign-gazebo would populate _rot with just the heading?

Copy link
Member

Choose a reason for hiding this comment

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

yeah, it could call SetWorldFrameOrientation(Quaterniond(0, 0, heading), ENU);

Copy link
Contributor

Choose a reason for hiding this comment

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

Cool, that sounds reasonable to me 👍

src/ImuSensor.cc Outdated Show resolved Hide resolved
@scpeters
Copy link
Member

looks good! don't forget to edit the commit message when squashing

@adityapande-1995 adityapande-1995 merged commit 8ae7167 into ign-sensors6 Dec 21, 2021
@adityapande-1995 adityapande-1995 deleted the aditya/imu_ref_orintation branch December 21, 2021 18:37
@osrf-triage
Copy link

This pull request has been mentioned on Gazebo Community. There might be relevant details there:

https://community.gazebosim.org/t/new-ignition-releases-2022-01-10/1228/1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🏯 fortress Ignition Fortress
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Exposing SetOrientationReference for IMU from sdf
4 participants