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

fix: adds gazebo gravity vector to the gravity calculation #177

Merged

Conversation

rickstaa
Copy link
Contributor

@rickstaa rickstaa commented Oct 8, 2021

This pull request makes sure that the gravity calculation uses the gravity vector that comes from the Gazebo simulation.

In the old version the default value set in the model_base.h class was used (i.e. [0, 0, -9.81]) while gazebo uses the following gravity vector [0, 0, -9.8000000000000007].

std::array<double, 7> gravity(const franka::RobotState& robot_state) const {
return gravity(robot_state.q, robot_state.m_total, robot_state.F_x_Ctotal, {0, 0, -9.81});
}

This is because the gravity_earth argument is not used.

auto g = this->model_->gravity(this->robot_state_);

Other todos

  • Update documentation.

rickstaa added a commit to rickstaa/panda-gazebo that referenced this pull request Oct 26, 2021
This commit adds a temporary gravity compensation hotfix for the
controllering the `franka_gazebo` simulation (see
frankaemika/franka_ros#160). Can be removed if
frankaemika/franka_ros#177 is merged.
Copy link
Contributor

@gollth gollth left a comment

Choose a reason for hiding this comment

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

Thank you for this improvement @rickstaa, definitely makes sense!

I could imagine use cases, though, where you want to provide custom directions/strengths for the gravity vector. For example one might want to simulate their controller if the robot is in free space. For that the gravity in Gazebo would be set to zero. The Master Controller of the real robot always compensates the gravity by ~9.81 m/s^2, which the controller of such user would need to account for.

Other use cases from the top of my head:

  • Simulation of the Robot mounted non-tabletop, say on a wall
  • Simulation of the robot on different places with different strengths of gravity vectors (poles, equator...)

To encompass these use cases as well, we need a way to specify if franka_hw_sim should use the gravity vector from Gazebo or a custom one.

My suggestion would be to make this configurable by ROS parameter. When the parameter is set, then this would be taken as gravity vector. If it is missing, then we could read it from Gazebo. This would also make a good default IMO.

If you agree with this approach, I would like to ask you to implement this. For reference you can have a look at FrankaHWSim::readParameter() (probably the place, where this logic belongs as well):

https://github.com/frankaemika/franka_ros/blob/develop/franka_gazebo/src/franka_hw_sim.cpp#L334-L380

franka_gazebo/src/franka_hw_sim.cpp Outdated Show resolved Hide resolved
@rickstaa rickstaa force-pushed the fix_gazebo_gravity_compensation branch 4 times, most recently from 87a7864 to f35b14a Compare November 3, 2021 14:06
@rickstaa
Copy link
Contributor Author

rickstaa commented Nov 3, 2021

Thank you for this improvement @rickstaa, definitely makes sense!

I could imagine use cases, though, where you want to provide custom directions/strengths for the gravity vector. For example one might want to simulate their controller if the robot is in free space. For that the gravity in Gazebo would be set to zero. The Master Controller of the real robot always compensates the gravity by ~9.81 m/s^2, which the controller of such user would need to account for.

Other use cases from the top of my head:

* Simulation of the Robot mounted non-tabletop, say on a wall

* Simulation of the robot on different places with different strengths of gravity vectors (poles, equator...)

To encompass these use cases as well, we need a way to specify if franka_hw_sim should use the gravity vector from Gazebo or a custom one.

My suggestion would be to make this configurable by ROS parameter. When the parameter is set, then this would be taken as gravity vector. If it is missing, then we could read it from Gazebo. This would also make a good default IMO.

If you agree with this approach, I would like to ask you to implement this. For reference, you can have a look at FrankaHWSim::readParameter() (probably the place, where this logic belongs as well):

https://github.com/frankaemika/franka_ros/blob/develop/franka_gazebo/src/franka_hw_sim.cpp#L334-L380

I like your suggestion. I will add it to this pull request.

CHANGELOG.md Outdated Show resolved Hide resolved
@@ -331,7 +336,7 @@ void FrankaHWSim::writeSim(ros::Time /*time*/, ros::Duration /*period*/) {

void FrankaHWSim::eStopActive(bool /* active */) {}

bool FrankaHWSim::readParameters(const ros::NodeHandle& nh, const urdf::Model& urdf) {
auto FrankaHWSim::readParameters(const ros::NodeHandle& nh, const urdf::Model& urdf) -> bool {
Copy link
Contributor Author

@rickstaa rickstaa Nov 23, 2021

Choose a reason for hiding this comment

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

Automatically applied by clang-tidy.

Copy link
Contributor

Choose a reason for hiding this comment

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

the const in the for loop can stay, however the trailing return types, look just look ugly imo. We currently use clang-tidy 7 in the CI. There are lots of things that could be fixed with a newer version of clang-tidy, however there are other lints like modernize-use-trailing-return-type or readability-function-cognitive-complexity that you do not want to have. Therefore, we currently stick to clang-tidy 7.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Strange that the extension does not pick up the right clang-tidy config. I reverted the clang-tidy changes manually.

Copy link
Contributor

Choose a reason for hiding this comment

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

It is because we include modernize* and readability*, so if new checks appear they will be included by default. Thats why you need to choose the correct clang-tidy version, so just use clang-tidy 7.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah over overlooked that in your previous answer. I'm on clang-tidy 10.

ros::NodeHandle model_nh,
gazebo::physics::ModelPtr parent,
const urdf::Model* const urdf,
std::vector<transmission_interface::TransmissionInfo> transmissions) {
std::vector<transmission_interface::TransmissionInfo> transmissions) -> bool {
Copy link
Contributor Author

@rickstaa rickstaa Nov 23, 2021

Choose a reason for hiding this comment

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

Automatically applied by clang-tidy. I can remove the automatic clang-tidy changes if you want.

@@ -200,7 +205,7 @@ void FrankaHWSim::initFrankaModelHandle(
" joints were found beneath the <transmission> tag, but 2 are required.");
}

for (auto& joint : transmission.joints_) {
for (const auto & joint : transmission.joints_) {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Automatically applied by clang-tidy.

Copy link
Contributor

Choose a reason for hiding this comment

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

There is a space between the auto and the &. Actually this should not pass the CI 🤔

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah, that's strange.

I also noticed that the clang-tidy vscode doesn't take that rule into account when formatting. This can of course be a bug with the extensions and not the .clang-tidy config. If it is a bug in the extension it will probably be fixed when the C++ extension adds clang-tidy support (see microsoft/vscode-cpptools#2908).

@rickstaa
Copy link
Contributor Author

@gollth, @marcbone I implemented the requested changes and rebased on the develop branch. I used g_vector for the gravity ROS parameter, but I can change it to your liking.

@rickstaa rickstaa force-pushed the fix_gazebo_gravity_compensation branch 3 times, most recently from 5f6cacd to e49dc35 Compare November 23, 2021 13:35
@gollth
Copy link
Contributor

gollth commented Nov 23, 2021

I vote for gravity_vector for clarity, other than that, LGTM

@rickstaa rickstaa force-pushed the fix_gazebo_gravity_compensation branch from e49dc35 to 211ff3d Compare November 23, 2021 17:21
This commit adds the 'gravity_vector' ROS parameter. This parameter can be
used to set the gravity vector used in the FrankaHWSim. If the 'g_vector'
parameter is not set the gravity vector will be retrieved from Gazebo.
@rickstaa rickstaa force-pushed the fix_gazebo_gravity_compensation branch from 211ff3d to 53a9be0 Compare November 23, 2021 17:21
@rickstaa
Copy link
Contributor Author

Great I updated the code to reflect that change.

@rickstaa rickstaa requested a review from gollth November 23, 2021 17:22
@gollth gollth merged commit 4fc4042 into frankaemika:develop Nov 24, 2021
@rickstaa rickstaa deleted the fix_gazebo_gravity_compensation branch November 24, 2021 15:43
@rickstaa
Copy link
Contributor Author

Thanks a lot for merging this!

marcbone pushed a commit that referenced this pull request Mar 15, 2022
…o develop

* commit 'bcd58208ce0b003e6621ad211139b2e9b545fecb':
  add catkin_install_python to CMakeLists.txt to generate proper shebang headers
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants