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 option to skip initial calibration and use zero offsets #72

Merged

Conversation

prashanthr05
Copy link
Contributor

@prashanthr05 prashanthr05 commented Jun 11, 2020

This PR addresses #67.

The idl files were autogenerated due to addition of parameter skipResetFTSensorOffset startWithZeroFTSensorOffsets to idl/wholeBodyDynamicsSettings/wholeBodyDynamicsSettings.thrift. The autogenerated files are also committed along with this PR.

Since by default the parameter skipResetOffset startWithZeroFTSensorOffsets is set to false (as per the regular workflow), only configuration related to simulation was modified by this PR. devices/wholeBodyDynamics/app/wholebodydynamics-icub-external-six-fts-sim.xml

@@ -942,7 +961,7 @@ bool WholeBodyDynamicsDevice::applyLPFSettingsFromConfig(const yarp::os::Propert
{
return false;
}

Copy link
Member

Choose a reason for hiding this comment

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

Suggested change

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Addressed in b495053

{
this->setFTSensorOffsetsToZero();
validOffsetAvailable = true;
ok = ok && true;
Copy link
Member

Choose a reason for hiding this comment

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

It is not really clear what is the point of this line.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I added that redundant code to debug and forgot to remove.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Addressed in b495053

if ( !(prop.check("skipResetOffset") && prop.find("skipResetOffset").isBool()) )
{
yWarning() << "wholeBodyDynamics: skipResetOffset bool parameter missing.";
yWarning() << "wholeBodyDynamics: setting skipResetOffset to the default value of false, please remember to resetOffset through the rpc port.";
Copy link
Member

Choose a reason for hiding this comment

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

This is misleading. On the real robot, you don't have to remember to call resetOffset .

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Noted. I will remove that line.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Addressed in b495053

@traversaro
Copy link
Member

Thanks! Minor comments: to be honest, the parameter name skipResetFTSensorOffset probably make sense to existing users that called resetOffets for thousands of times in their life, but I think it is misleading for new users, as it does suggest that the "FT Sensor offset reset" is skipped, while this option does exactly the opposite: is uses zero FT sensor offsets (so, "reset" offset) at the device startup, instead of performing calibration. For this reason, I think that calling something like startWithZeroFTSensorOffsets or similar (suggestions are welcome) would be more clear. Furthermore, also the description is not really clear: "This allows to skip manual calling of resetOffsets for removeing offsets on FT sensors". I think it would me more clear to first have a place were we state (also in the general description before this parameter) that at the beginning the device estimates the offset of the FT sensors, unless the option startWithZeroFTSensorOffsets is passed.

Furthermore note that a similar functionality (let user specify user-defined offsets, not just 0) is also provided in #45, so we should consider if the two options can coexist (probably yes, startWithZeroFTSensorOffsets can be an easy option to set all the FT sensor offset to zero (useful in simulation), while the option #45 can be used for more complex settings in which the offset need to be manually inserted.

@GiulioRomualdi @Giulero @gabrielenava @HosameldinMohamed

@prashanthr05
Copy link
Contributor Author

prashanthr05 commented Jun 11, 2020

I think that calling something like startWithZeroFTSensorOffsets or similar (suggestions are welcome) would be more clear.

Agreed. I think startWithZeroFTSensorOffsets is clear. But I will wait a bit to understand if we get some inputs from other users.

Furthermore note that a similar functionality (let user specify user-defined offsets, not just 0) is also provided in #45, so we should consider if the two options can coexist (probably yes, startWithZeroFTSensorOffsets can be an easy option to set all the FT sensor offset to zero (useful in simulation), while the option #45 can be used for more complex settings in which the offset need to be manually inserted.

I revisited that PR and noticed that. Indeed, it allows the user to add an FT_OFFSET group to specify the custom offsets. I hope we will not be crowding the source code or the user experience too much by adding a redundant feature (startWithZeroFTSensorOffsets).

However, if its agreed to have both the options so that they can be used without any confusion, I will rename the parameter to what is agreed upon. Otherwise, we can close this PR.

@traversaro
Copy link
Member

However, if its agreed to have both the options so that they can be used without any confusion, I will rename the parameter to what is agreed upon.

I agree that having both options make sense, especially for simulation users so that they do not need to add a complex FT_OFFSET group when they can just add a simple option.

@traversaro
Copy link
Member

cc @lrapetti @diegoferigo

@prashanthr05
Copy link
Contributor Author

prashanthr05 commented Jun 12, 2020

Agreed. I think startWithZeroFTSensorOffsets is clear. But I will wait a bit to understand if we get some inputs from other users.

I will proceed to rename the option with startWithZeroFTSensorOffsets, since there has not been any response so far.

@prashanthr05 prashanthr05 force-pushed the feature/bypass-resetOffset branch from b495053 to ef3b7f6 Compare June 12, 2020 14:29
@prashanthr05 prashanthr05 force-pushed the feature/bypass-resetOffset branch from ef3b7f6 to 68fef48 Compare June 12, 2020 14:33
@prashanthr05 prashanthr05 requested a review from traversaro June 12, 2020 14:35
CHANGELOG.md Outdated
@@ -4,6 +4,10 @@ All notable changes to this project will be documented in this file.
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).

## Unreleased
### Added
- Added 'skipResetOffset' to disable/enable bypassing of resetOffset rpc call for setting FT sensor offsets to zero. (See [!72](https://github.com/robotology/whole-body-estimators/pull/72)).
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
- Added 'skipResetOffset' to disable/enable bypassing of resetOffset rpc call for setting FT sensor offsets to zero. (See [!72](https://github.com/robotology/whole-body-estimators/pull/72)).
- Added 'startWithZeroFTSensorOffsets' to disable/enable bypassing of resetOffset rpc call for setting FT sensor offsets to zero. (See [!72](https://github.com/robotology/whole-body-estimators/pull/72)).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Addressed in 52813c1

@traversaro
Copy link
Member

Approved, but check the CHANGELOG suggestion.

@prashanthr05 prashanthr05 force-pushed the feature/bypass-resetOffset branch from 68fef48 to 52813c1 Compare June 12, 2020 15:00
@traversaro
Copy link
Member

Perfect!

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

Successfully merging this pull request may close these issues.

3 participants