gazebosim / gazebo-classic

Gazebo classic. For the latest version, see https://github.com/gazebosim/gz-sim
http://classic.gazebosim.org/
Other
1.17k stars 476 forks source link

Provide torque-speed curve #780

Open osrf-migration opened 11 years ago

osrf-migration commented 11 years ago

Original report (archived issue) by Jesper Smith (Bitbucket: jespersmith).


Real actuators have maximum torque and speed values that are independent(for example, electric motors have a linear relation)

It would be nice if a simple torque-speed curve can be given as an actuator limit instead of a maximum force and maximum velocity.

osrf-migration commented 11 years ago

Original comment by Brian Axelrod (Bitbucket: brianaxelrod).


I agree, that this would be very useful. I've had to write gazebo plugins to do exactly this in the past.

@hsu I haven't spent too much time looking at the gazebo source, what would be involved in implementing this properly in gazebo itself?

osrf-migration commented 11 years ago

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


Aside from the issues of choosing the actuator model and parameters, I think it could be implemented by binding a function to the JointUpdate event. There's an example of this in ODEJoint::SetDamping, from lines 1175 to 1179 when joint damping functions are set up.

osrf-migration commented 11 years ago

Original comment by Brian Axelrod (Bitbucket: brianaxelrod).


Is there documentation that explains what happens every gazebo update?

On JointUpdate would I simply be able to set max force every single update cycle depending on speed? this->SetParam(dParamFMax, _value)

osrf-migration commented 11 years ago

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


I don't think there is documentation about the gazebo update process. I looked at World::Update, which calls Model::Update on every model. Model::Update calls Joint::Update, which currently just triggers the JointUpdate event and returns.

Regarding your second question, that looks like it would work for ODE, though we may have to implement something different for each physics engine.

osrf-migration commented 10 years ago

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


@brianaxelrod Will it be possible for you to share your past plugin work on this? Or more detail on what was done in the past? That will be extremely helpful.

@jespersmith Do you have a real-world example and specification on the use case you have in mind?

Thanks!

osrf-migration commented 10 years ago

Original comment by Jesper Smith (Bitbucket: jespersmith).


@hsu We're not using a electric robot at the moment. For Atlas, there is a nice non-linear curve.

osrf-migration commented 10 years ago

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


@jespersmith I guess we can start by looking at the curves specified in the BDI private file repo for reference. Do you have any specific preference on which joint might be more interesting or important to model first?

osrf-migration commented 10 years ago

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


@acrane1970 Is it ok for us to try and implement torque-speed actuation for Atlas joints based on data from the robot hardware?

osrf-migration commented 9 years ago

Original comment by Jackie K (Bitbucket: jacquelinekay).


I'm working on a proof-of-concept plugin for this right now in branch actuator_plugin, in plugins/ActuatorPlugin.

The actuator plugin is a model plugin enforces a maximum torque based on the current velocity of the "actuated" joint. It sets up a callback on the WorldUpdateBegin event. In this callback, a maximum torque value is calculated from the torque-speed model, which is configurable by the user. The maximum torque value is enforced if the joint torque exceeds this value. I don't actually use Joint::SetMaxForce because it's buggy and doesn't work uniformly for each physics engine.

I also set up a data collection example in examples/stand_alone/actuator/main.cc. It spawns two models that are identical except one has an actuated joint and the other has a passive joint. Joint::SetForce is used to enforce a constant force value on each joint for a fixed number of timesteps.

Here are some plots. The maximum torque value for the actuator was set to 2, the maximum velocity was set to 20, and the power was set to 10 (arbitrarily chosen values that worked well together). The torque speed curve is calculated from torque = power/velocity.

actuator_pos_time.png actuator_vel_time.png actuator_torque_speed_passive.png actuator_torque_speed_actuated.png

Note that in the torque/velocity curve for the actuated joint, the initial flat part of the curve is 2--I was lazy with my joint axes, sorry folks. The plugin doesn't actually enforce a maximum velocity right now, since Joint::SetVelocity has some weird behavior. Feedback on that is welcome...

@hsu, @nkoenig: I'd like to pull request this work once it's finished, which Gazebo should I target? @scpeters suggested I pull request it into 4.1, since it's a DRCSim milestone, and make a design document for integrating an Actuator class into the physics library, perhaps for Gazebo 6. Using a plugin creates a lot of limitations for this concept, but I thought it would be good practice to prototype modularly and a plugin seemed convenient for that.

osrf-migration commented 9 years ago

Original comment by Jackie K (Bitbucket: jacquelinekay).


https://osrf-migration.github.io/gazebo-gh-pages/#!/osrf/gazebo/pull-request/1371/actuator-plugin-torque-speed-curve-for

I targeted default, since it seemed like the safe choice...

osrf-migration commented 9 years ago

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


osrf-migration commented 7 years ago

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