-
Notifications
You must be signed in to change notification settings - Fork 59
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
Conversation
Signed-off-by: Aditya <[email protected]>
Signed-off-by: Aditya <[email protected]>
custom_rpy
tag parsing added
Signed-off-by: Aditya <[email protected]>
Signed-off-by: Aditya <[email protected]>
Codecov Report
@@ 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
Continue to review full report at Codecov.
|
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.
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; |
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'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.
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 !
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.
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
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.
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.
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'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 tosdf::Imu::Localization
, so I guess it could callsensors::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 likesensors::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
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.
humm ok I see there's a use case there. Then I guess the heading needs to be passed to the IMU as well
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.
in that case does sensors::ImuSensor::SetWorldFrameOrientation(const Quaterniond &_rot, const WorldFrameEnumType _relativeTo = ENU);
seem like a reasonable API?
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.
So in that case, ign-gazebo
would populate _rot
with just the heading?
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, it could call SetWorldFrameOrientation(Quaterniond(0, 0, heading), ENU);
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.
Cool, that sounds reasonable to me 👍
Signed-off-by: Aditya <[email protected]>
Signed-off-by: Aditya <[email protected]>
Signed-off-by: Aditya <[email protected]>
Signed-off-by: Steve Peters <[email protected]>
looks good! don't forget to edit the commit message when squashing |
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 |
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 theLoad
method for the IMU sensor. This PR aims to set reference orientation when thelocalization
tag is set toCUSTOM
andcustom_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 :
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
codecheck
passed (See contributing)Note to maintainers: Remember to use Squash-Merge
🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸