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

Implement dofs, get / set joint control mode in Ignition Gazebo, refactor PID #104

Merged

Conversation

diegoferigo
Copy link
Member

@diegoferigo diegoferigo commented Dec 17, 2019

This PR adds the following capabilities to robots simulated in Ignition Gazebo:

  • Gather the number of DoFs
  • Set and get the control mode
  • Refactor PID support based on the new control mode selection

Fixes partially #65

@diegoferigo diegoferigo force-pushed the feature/controlmode_and_dofs branch 2 times, most recently from 8dcba75 to 551bd20 Compare December 17, 2019 17:17
@@ -71,6 +74,8 @@ class gympp::gazebo::IgnitionRobot : public gympp::Robot

bool setJointPosition(const JointName& jointName, const double jointPosition) override;
bool setJointVelocity(const JointName& jointName, const double jointVelocity) override;
bool setJointControlMode(const JointName& jointName,
const JointControlMode controlMode) override;
Copy link
Member

Choose a reason for hiding this comment

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

Not a big problem for the simulation runtimes, but for real robot runtimes it may be useful to be able to set also a first reference when you switch control mode. If there is the possibility of setting the joint position setpoints synchronously with the joint control mode, then there is no problem.

Copy link
Member Author

Choose a reason for hiding this comment

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

Excellent catch @traversaro. Right now is not possible to set the new reference synchronously (nor before changing control mode).

I see two solutions:

  1. Make this a warning to allow users to set a reference before changing control mode:

    if (jointControlMode(jointName) != JointControlMode::Position) {
    gymppError << "Cannot set the position target of joint '" << jointName
    << "' not controlled in Position" << std::endl;
    return false;
    }

  2. Get the current joint positions before switching to Position mode and use them as a reference. In this way, if there's a small delay between the switch of the control mode and the setting of the first reference, the PIDs are already in working state.

Do you have any comment on these two, or a third preferable option?

Copy link
Member

Choose a reason for hiding this comment

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

Get the current joint positions before switching to Position mode and use them as a reference. In this way, if there's a small delay between the switch of the control mode and the setting of the first reference, the PIDs are already in working state.

In some cases, this is not going to work (for example, if you do that on a KUKA robot with RSI, the controller will fault due to the difference between the current reference and the current position, that are different due to static error).

Do you have any comment on these two, or a third preferable option?

To be honest, I am not enthusiastic of either solution (mainly because it is not clear for the user) for me, it is ok to just take note of this problem, and understand how to solve it in the future.

Copy link
Member Author

Choose a reason for hiding this comment

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

In some cases, this is not going to work (for example, if you do that on a KUKA robot with RSI, the controller will fault due to the difference between the current reference and the current position, that are different due to static error).

I didn't get something. How could the user provide a reference more precise than the current state read by sensors? In any case there will be a mismatch, right?

Copy link
Member Author

Choose a reason for hiding this comment

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

Opened a new issue to track this #107

Copy link
Member

Choose a reason for hiding this comment

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

I didn't get something. How could the user provide a reference more precise than the current state read by sensors? In any case there will be a mismatch, right?

We can discuss f2f, but basically in general the reference is different from the measured one if there is static error. If the static error is not negligiible, switching the reference from the old reference to the new reference creates a discontinuity.

@@ -333,6 +325,11 @@ bool IgnitionRobot::valid() const
return true;
}

size_t IgnitionRobot::dofs() const
{
return jointNames().size();
Copy link
Member

Choose a reason for hiding this comment

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

Just to know, are we tracking somewhere that the joint contained in jointNames has 1 and only 1 DOFs?

Copy link
Member Author

Choose a reason for hiding this comment

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

There are a lot of asserts in the code, not here specifically. I think we're well covered, but we should document (yet another thing to remember) that we only support 1 DoF joints.

Copy link
Member

Choose a reason for hiding this comment

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

(yet another thing to remember)

Yet another thing for which to open issues. : )

Copy link
Member Author

Choose a reason for hiding this comment

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

I converted an old issue to collect all these links to TODO(cument) stuff #37

Copy link
Member

@traversaro traversaro left a comment

Choose a reason for hiding this comment

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

Small curiosity, why you need to update git?

@diegoferigo
Copy link
Member Author

Small curiosity, why you need to update git?

I am still puzzled to be honest. Have a look at this log:

Working directory is '/__w/gym-ignition/gym-ignition'
/usr/bin/git version
git version 2.17.1
Deleting the contents of '/__w/gym-ignition/gym-ignition'
The repository will be downloaded using the GitHub REST API
To create a local Git repository instead, add Git 2.18 or higher to the PATH
Downloading the archive
Writing archive to disk
Extracting the archive
/bin/tar xz -C /__w/gym-ignition/gym-ignition/e090103a-f92c-498f-8f07-a099e700ab8b -f /__w/gym-ignition/gym-ignition/e090103a-f92c-498f-8f07-a099e700ab8b.tar.gz
Resolved version robotology-gym-ignition-2a4ad9f

It downloads the tarball, instead of creating a local git repository. For the python versioning we use setuptools-scm that, by reading the git history, creates a PEP440 compliant release. If there's no git repo, it fails to get the version:

Traceback (most recent call last):
File "setup.py", line 166, in
'./**/*.config',
File "/venv/lib/python3.6/site-packages/setuptools/init.py", line 145, in setup
return distutils.core.setup(**attrs)
File "/usr/lib/python3.6/distutils/core.py", line 108, in setup
_setup_distribution = dist = klass(attrs)
File "/venv/lib/python3.6/site-packages/setuptools/dist.py", line 448, in init
k: v for k, v in attrs.items()
File "/usr/lib/python3.6/distutils/dist.py", line 281, in init
self.finalize_options()
File "/venv/lib/python3.6/site-packages/setuptools/dist.py", line 740, in finalize_options
ep.load()(self)
File "/venv/lib/python3.6/site-packages/setuptools/dist.py", line 747, in _finalize_setup_keywords
ep.load()(self, ep.name, value)
File "/__w/gym-ignition/gym-ignition/.eggs/setuptools_scm-3.3.3-py3.6.egg/setuptools_scm/integration.py", line 17, in version_keyword
dist.metadata.version = get_version(**value)
File "/__w/gym-ignition/gym-ignition/.eggs/setuptools_scm-3.3.3-py3.6.egg/setuptools_scm/init.py", line 150, in get_version
parsed_version = _do_parse(config)
File "/__w/gym-ignition/gym-ignition/.eggs/setuptools_scm-3.3.3-py3.6.egg/setuptools_scm/init.py", line 113, in _do_parse
"use git+https://github.com/user/proj.git#egg=proj" % config.absolute_root

@diegoferigo diegoferigo merged commit c9de481 into robotology:devel Dec 19, 2019
@diegoferigo diegoferigo deleted the feature/controlmode_and_dofs branch December 19, 2019 14:11
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.

2 participants