Support printing sdf poses in degrees and allow snapping to commonly used angles#689
Conversation
|
The API changes from this PR have been captured by #708. |
2a2b58c to
983362f
Compare
Codecov Report
@@ Coverage Diff @@
## sdf12 #689 +/- ##
==========================================
+ Coverage 90.57% 90.70% +0.13%
==========================================
Files 78 78
Lines 12336 12439 +103
==========================================
+ Hits 11173 11283 +110
+ Misses 1163 1156 -7
Continue to review full report at Codecov.
|
Signed-off-by: Aaron Chong <aaronchongth@gmail.com>
Signed-off-by: Aaron Chong <aaronchongth@gmail.com>
…Param Signed-off-by: Aaron Chong <aaronchongth@gmail.com>
Signed-off-by: Aaron Chong <aaronchongth@gmail.com>
Signed-off-by: Aaron Chong <aaronchongth@gmail.com>
Signed-off-by: Aaron Chong <aaronchongth@gmail.com>
Signed-off-by: Aaron Chong <aaronchongth@gmail.com>
Signed-off-by: Aaron Chong <aaronchongth@gmail.com>
Signed-off-by: Aaron Chong <aaronchongth@gmail.com>
Signed-off-by: Aaron Chong <aaronchongth@gmail.com>
Signed-off-by: Aaron Chong <aaronchongth@gmail.com>
Signed-off-by: Aaron Chong <aaronchongth@gmail.com>
Signed-off-by: Aaron Chong <aaronchongth@gmail.com>
Signed-off-by: Aaron Chong <aaronchongth@gmail.com>
Signed-off-by: Aaron Chong <aaronchongth@gmail.com>
Signed-off-by: Aaron Chong <aaronchongth@gmail.com>
Signed-off-by: Aaron Chong <aaronchongth@gmail.com>
Signed-off-by: Aaron Chong <aaronchongth@gmail.com>
Signed-off-by: Aaron Chong <aaronchongth@gmail.com>
Signed-off-by: Aaron Chong <aaronchongth@gmail.com>
…treamer by default Signed-off-by: Aaron Chong <aaronchongth@gmail.com>
Signed-off-by: Aaron Chong <aaronchongth@gmail.com>
Signed-off-by: Aaron Chong <aaronchongth@gmail.com>
|
1400948 reverts all unnecessary changes made to old tests due to the experimental nature of handling parsing since the start of sdf12, specifically by https://github.com/ignitionrobotics/sdformat/pull/589/files As of now, the behavior of getting strings from values will all reside in
Apologies for all the back and forth regarding modifying old tests. As of 1400948 we should be good to go and no longer have to worry about changes in behavior, unless another type requires its own value-to-string method. |
There was a problem hiding this comment.
I was struggling to understand what ToString behavior is with floating point numbers since we are now changing behavior again. Here's what I've come up so far to summarize the current behavior.
- If the element is set by the user, the string value used by the user is printed verbatim when
ToStringis called (except for Poses whose behavior depends on thePrintConfigsetting). - Sometimes, if the element is set by the user, the value is read by the libsdformat and converted to a binary representation. When
ToStringis called, the binary representation is converted back to a string. - If the element is not present, but a default element is added by libsdformat, the string value is read from the default attribute of the element's description, converted to a binary representation, and converted back to a string.
I then used the following file to test the behavior.
<sdf version="1.9">
<world name="default">
<model name="M1">
<link name="L1">
<visual name="v1">
<material>
<diffuse>0.15 0.6 0.8</diffuse><!-- (1) String printed verbatim. Type: color -->
<render_order>0.15</render_order><!-- (2) Converted to binary then to string. Type: float -->
</material>
<transparency>0.15</transparency><!-- (2) Converted to binary then to string. Type: double -->
</visual>
<sensor name='camera' type='camera'>
<pose>-1.06 0.090912 0 0 0 3.14</pose> <!-- (1) String printed verbatim. Type: pose -->
<camera>
<horizontal_fov>1.40</horizontal_fov> <!-- (2) Converted to binary then to string. Type: double -->
<clip>
<near>0.15</near><!-- (2) Converted to binary then to string. Type: double -->
</clip>
<distortion>
<center>0.15 1.4</center> <!-- (1) String printed verbatim. Type: vector2 -->
</distortion>
</camera>
</sensor>
</link>
<joint name="j1" type="revolute">
<parent>world</parent>
<child>L1</child>
<axis>
<xyz>0.12 0.34 0.56</xyz> <!-- (1) String printed verbatim. Type: vector3 -->
</axis>
</joint>
</model>
<!--<magnetig_field> (3) Default string converted to binary then to string. Type: vector3 -->
</world>
</sdf> Output from ign sdf -p
<sdf version='1.9'>
<world name='default'>
<model name='M1'>
<link name='L1'>
<visual name='v1'>
<material>
<diffuse>0.15 0.6 0.8 1</diffuse>
<render_order>0.150000006</render_order>
</material>
<transparency>0.14999999999999999</transparency>
<geometry/>
</visual>
<sensor name='camera' type='camera'>
<pose>-1.06 0.090912 0 0 0 3.14</pose>
<camera>
<horizontal_fov>1.3999999999999999</horizontal_fov>
<clip>
<near>0.14999999999999999</near>
<far>100</far>
</clip>
<distortion>
<center>0.15 1.4</center>
</distortion>
<image>
<width>320</width>
<height>240</height>
</image>
</camera>
</sensor>
</link>
<joint name='j1' type='revolute'>
<parent>world</parent>
<child>L1</child>
<axis>
<xyz>0.12 0.34 0.56</xyz>
<limit>
<lower>-10000000000000000</lower>
<upper>10000000000000000</upper>
</limit>
</axis>
</joint>
</model>
<gravity>0 0 -9.8</gravity>
<magnetic_field>6e-06 2.3e-05 -4.2e-05</magnetic_field>
<atmosphere type='adiabatic'/>
<physics type='ode'>
<max_step_size>0.001</max_step_size>
<real_time_factor>1</real_time_factor>
<real_time_update_rate>1000</real_time_update_rate>
</physics>
<scene>
<ambient>0.4 0.4 0.4 1</ambient>
<background>0.7 0.7 0.7 1</background>
<shadows>true</shadows>
</scene>
</world>
</sdf>
My observation is the behavior is inconsistent between double types and vector* types. Would it be possible to eliminate this inconsistency?
src/PrintConfig.cc
Outdated
| this->GetRotationSnapTolerance() == _config.GetRotationSnapTolerance()) | ||
| if (this->RotationInDegrees() == _config.RotationInDegrees() && | ||
| this->RotationSnapToDegrees() == _config.RotationSnapToDegrees() && | ||
| this->RotationSnapTolerance() == _config.RotationSnapTolerance()) |
There was a problem hiding this comment.
Should we check for PreserveIncludes now that that's merged?
There was a problem hiding this comment.
Added in b541f34, thanks for spotting that!
|
Many thanks for testing it extensively, @azeey! 🙇
This is related to #689 (comment), in order to avoid that change (returning However if we decide to keep the changes in behavior (returning string/default-string that was set), we would need the aforementioned test to return This will affect this observation,
|
This is due to the different implementations of
if we remove the template specialization for |
|
Thanks for the explanation. Eric has created #790 to address the inconsistency. I have tested this PR against all other ignition libraries and had no failures, so I'll go ahead and approve. |
azeey
left a comment
There was a problem hiding this comment.
There are a couple of unresolved conversations. Otherwise LGTM. Thanks for your patience.
|
|
||
| ////////////////////////////////////////////////// | ||
| extern "C" SDFORMAT_VISIBLE int cmdPrint(const char *_path) | ||
| extern "C" SDFORMAT_VISIBLE int cmdPrint(const char *_path, |
Signed-off-by: Aaron Chong <aaronchongth@gmail.com>
Signed-off-by: Aaron Chong <aaronchongth@gmail.com>
…arse booleans into true/false, instead of 1/0 Signed-off-by: Aaron Chong <aaronchongth@gmail.com>
|
I noticed the recent merge for Ideally we would expect the sanitization for I couldn't find any persuasive solutions to this without breaking more stuff. I would suggest we move on with the merge, however keep an eye out for the next release of Let me know what you think. |
…ng instead of default PrintConfig Signed-off-by: Aaron Chong <aaronchongth@gmail.com>
that sounds good to me |
Signed-off-by: Aaron Chong <aaronchongth@gmail.com>
Signed-off-by: Aaron Chong <aaronchongth@gmail.com>
| element->AddAttribute(attribute->Name(), "string", "", 1, ""); | ||
| element->GetAttribute(attribute->Name())->SetFromString( | ||
| const std::string attributeName(attribute->Name()); | ||
| if (attributeName == "type") |
There was a problem hiding this comment.
what if a plugin uses the type attribute?
we are observing some ign-gazebo test failures of the triggered_publisher test, and that plugin uses attributes with name type:
There was a problem hiding this comment.
😄 I had just started writing a similar response here:
This broke plugins downstream on ign-gazebo. Loading a plugin like this:
<plugin filename="ignition-gazebo-triggered-publisher-system" name="ignition::gazebo::systems::TriggeredPublisher">
<input type="ignition.msgs.Empty" topic="/in_1"/>
<output type="ignition.msgs.Boolean" topic="/out_1">
data: true
</output>
</plugin>
Results in an assertion when the SDF is loaded:
173: Error [Param.cc:768] Unknown parameter type[ignition.msgs.Boolean]
173: Exception [Param.cc:81] SDF ASSERTION
173: Invalid parameter
173: In function : Param
173: Assert expression : this->dataPtr->ValueFromStringImpl( this->dataPtr->typeName, _default, this->dataPtr->defaultValue)
I'm testing a temporary fix
|
This pull request has been mentioned on Gazebo Community. There might be relevant details there: https://community.gazebosim.org/t/new-ignition-releases-2022-04-13-fortress-edifice/1367/1 |
🎉 New feature
Related to #646
Summary
Support options in printing,
snap-to-degressmust be larger than 0, less than or equal to 360.snap-tolerancemust be larger than 0, less than 360, and less thansnap-to-degrees.For example,
Printing options,
Behavior changes
Paramwill be type dependent, at the moment typeposeuses a separate process than the rest of the types, and in the future, other types can adopt similar patterns to handle specific parsing behaviors. See https://github.com/ignitionrobotics/sdformat/blob/aaron/snapping-rotation-printouts/src/Param.cc#L980-L1010Paramconstructor, for example this test that needed to be modified, 8b4f471#diff-441337ac422044f4e471bad3d5d6d322f315bf1dd94cace33cd62e4c50072b3eR233Checklist
codecheckpassed (See contributing)Note to maintainers: Remember to use Squash-Merge