This repository was archived by the owner on Nov 28, 2025. It is now read-only.
Topic/state integrator#70
Open
NoelieRamuzat wants to merge 13 commits into
Open
Conversation
added 9 commits
August 19, 2019 17:53
To be plugged before the device if integration of the control is needed: Only for control in Velocity and Acceleration for now. Check the size of the signal to separate two cases: with and without a control on the freeflyer. The integration of the freeflyer works as an odometry predictive system.
Use device.cpp from sot-core. Add yaml files to create the device for the test. Set the input control of the integrator to -0.5 m/s (velocity) for every joints. Plug the output stateSOUT_ of the integrator to the input control of the device. The control type of the joints on the hardware side (in device) is in position. At the end of the loop the output of the device (motor control) correspond to the limits of the joints in position (as expected, the velocity control push the joints to their limits). In the test a freeflyer is given and integrated as an odometry system.
Replace signal controlTypeSIN by setter : with strings or ints (for addcommand)
…eeflyer Add entry signal for freeflyer (freeFlyerSIN), add a variable to define controlType of the Freeflyer (controlTypeFF_) with setter. Add two output signals for freeflyer one for Euler angles (freeFlyerPositionEulerSOUT_) and the other for quaternions (freeFlyerPositionQuatSOUT_). Change the computation of the Euler angles to assure their range to be [-pi:pi]x[-pi/2:pi/2]x[-pi:pi].
Store the values as SoTControlType instead of using strings. First integration (acceleration) of freeflyer changed to normal integration not rollPitchYaw (mistake). Add command to define the type of one joint.
Contributor
|
I'll try to understand your issue with the flags in the afternoon. |
NoelieRamuzat
marked this pull request as ready for review
July 31, 2020 09:09
jmirabel
reviewed
Aug 4, 2020
Co-authored-by: Joseph Mirabel <josephmirabel@gmail.com>
This file contains hidden or 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
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 participants
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.
Add a simple integrator to be used with the generic-device entity of sot-core (see PR #136 ).
It uses pinocchio::urdf::buildModelFromXML to retreive the size of the position/velocity/acceleration vectors. Perhaps can be done in another way to remove the dependency to urdfDOM.
Because of this dependency, I had the same issue than the number #1106 in pinocchio and have do add :
in the CMakeLists.txt.
I have issues with the python tests so it is a draft for now.