SetForce/SetTorque in class ODELink / Point of application of forces and torques

[osrf-migration]

Original report (archived issue) by Johannes Meyer (Bitbucket: johmeyer).

---

I posted this issue a while ago in the old Trac system on code.ros.org (see here). As there was no reaction until now and it does not only affect the simulator_gazebo package for ROS, I repost it here:

I am using the released version 1.6.16 of ros-fuerte-simulator-gazebo.

The gazebo_ros_force plugin calls the SetForce() and SetTorque() methods to apply a wrench to a given link in Gazebo, which is forwarded to dBodySetForce/dBodySetTorque in ODELink.cc. According to the ODE API documentation the method dBodySetForce is "mostly useful to zero the force and torque for deactivated bodies before they are reactivated". I wonder if the lines should be replaced by AddForce()/AddTorque() or AddRelativeForce()/AddRelativeTorque(), what seems to be much more useful to me. Additionally, the result of SetForce/SetTorque calls is totally undetermined unless the exact plugin execution order is known.

The following related problem affects Gazebo itself, not only the gazebo_plugins package. Perhaps I should rather report it on Bitbucket?

I stumbled accross the fact, that ODE's dBodyAddForce/dBodyAddRelForce functions apply the force at the body's center of gravity, not at its origin, which led to a faulty simulation of aerodynamic drag and propulsion in our hector_quadrotor_controller package (see http://ode-wiki.org/wiki/index.php?title=HOWTO_damping#Aerodynamic_Drag for reference). IMHO this should be documented more clearly in the API documentation, because its not what I would have expected. Additionally, I think AddForce() is used incorrectly in the VehiclePlugin that comes with Gazebo in this case.

Note that dBodyAddForceAtRelPos() also adds forces relative to the center of mass, too, not relative to the origin of the body.

[osrf-migration]

Original comment by John Hsu (Bitbucket: hsu, GitHub: hsu).

---

Updated ros-pkg ticket.

Proposing making sure Link::SetForce, Link::SetTorque, Link::AddForce and Link::AddTorque) sets/accumulates force/torque at Link origins, I agree that seem to be more intuitive. Objections?

When settled, I'll update doxygen comment to be more clear on what's going on as well.

Thanks, John

[osrf-migration]

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

---

• changed state from "new" to "on hold"

Until 2.0

[osrf-migration]

Original comment by Ian Chen (Bitbucket: Ian Chen, GitHub: iche033).

---

• changed state from "on hold" to "open"

[osrf-migration]

Original comment by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

---

After trying out all the functions, I think their documentation should be something like this:

      /// \brief Apply a force at the link's CoG for one time step.
      /// \param[in] _force Force expressed in the world frame.
      public: virtual void AddForce(const math::Vector3 &_force) = 0;

      /// \brief Apply a force at the link's CoG for one time step.
      /// \param[in] _force Force expressed in the link's frame (not its
      /// inertial frame).
      public: virtual void AddRelativeForce(const math::Vector3 &_force) = 0;

      /// \brief Apply a force at a given position for one time step.
      /// \param[in] _force Force expressed in the world frame.
      /// \param[in] _pos Position expressed in the world frame.
      public: virtual void AddForceAtWorldPosition(const math::Vector3 &_force,
                  const math::Vector3 &_pos) = 0;

      /// \brief Apply a force at a given position for one time step.
      /// Note that force and position are expressed in different frames.
      /// \param[in] _force Force expressed in the world frame.
      /// \param[in] _pos Position expressed in the link's frame (not its
      /// inertial frame).
      public: virtual void AddForceAtRelativePosition(
                  const math::Vector3 &_force,
                  const math::Vector3 &_relPos) = 0;

[osrf-migration]

Original comment by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

---

If I may add a couple of functions which would be nice to have for the force/torque GUI, something like:

      /// \brief Apply an impulse to the body.
      /// \param[in] _force Force value in N.
      /// \param[in] _time Time interval in s.
      public: virtual void ApplyImpulse(const math::Vector3 &_force, const double &_time) = 0;

• I think the name is pretty clear. Maybe it could take only an impulse argument in Ns, but I think separating force and time is friendlier.

      /// \brief Add a persistent force to the body.
      /// \param[in] _force Force value in N.
      public: virtual void AddPersistentForce(const math::Vector3 &_force) = 0;

• This would be a force that gets added at every time-step indefinitely, perhaps only cancelled by SetForce(0)

[osrf-migration]

Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

• set component to "physics"

[osrf-migration]

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

---

• set version to "all"

[osrf-migration]

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

---

• changed state from "open" to "new"