Propagate return values alongside the data #495
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… remote client if a specific field data is correct or not. Increased protocol version number
|
This change looks ok to me. |
drdanz
added a commit
that referenced
this pull request
Jun 3, 2015
Propagate return values alongside the data
|
now getEncoders() returns false and yarpmotorgui does not open anymore... please test before merge! (and add a test case on the return values in the test suite...) UPDATE: it was found that icub-main was not updated to the last version. Do we need to increase the tweak number? Or increase the run-time check on the wrapper/control board protocol? |
This was referenced Jun 4, 2015
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Each value broadcasted inside the stateExt port is paired with a boolean flag telling if the value is valid or not.
The flag will be set to true if the corresponding getXXX function in the remote device driver was succesful or false otherwise.
In this way if the user application tries a getMotorAcceleration and the robot/simulator does not implement this function (or it fails somehow) the return value in the user application will be false.
Right now, since all broadcasted values are always available the return value was always true but I think this is not correct.
This will re-establish the same behaviour of the former version of yarp without the stateExt.