Constant rotational speed

May 25, 2009 at 10:35 AM


Id like to rotate an object around a joint at a certain speed. How would I calculate the force to apply?

At the moment what I do is apply a certain force every timestep, and if the speed of the object gets above a certain point I dont apply the force. This keeps it pretty constant but I dont think its the best way, plus the values are really wild and random depending on the mass and size of the object, and I always have to keep trying till I find the perfect value.

Ive seen some other physics engines have a motor-joint, but I havent looked at any code yet.


May 25, 2009 at 9:48 PM

Have you tried simply setting the Body's AngularVelocity field to a constant value in each Update()?

May 27, 2009 at 3:02 AM

I actually want to be able to adjust the strength and speed of the rotation, and the motor-joints Ive seen allow you to do that, so I was wondering if anyone knew what formula they used.

Im busy looking for some open-source physics engines that have motor-joints, and if I find something Il post it. But feel free to post any ideas in the meantime.

May 27, 2009 at 3:35 AM

I found this code

Its a c# port of BOX2D. Basically its a normal revolute joint, but you can enable a motor in it. Which is quite handy I think :)

It would be a good thing to put in the new code, if its not planned already, and it doesnt look too hard to integrate. Plus Box2D and Farseer are really similar.


May 27, 2009 at 4:24 AM

Doesn't a motor just apply torque to a revolute joint? It's the friction and other resistance that cause the rotation to end up constant. I'm not an expert, but if you think about driving a car, to stay the same speed you need to adjust the gas (amount of torque) until the torque is canceled out exactly by friction and other resistance. Rather than add a motor feature to joint itself, it might be better to add some helper functions to calculate the correct amount of torque needed to keep a particular body rotating at a constant speed.

May 27, 2009 at 1:07 PM

@robertdodd: If you apply some torque to the body and remove rotationaldrag. It will rotate at a constant speed until something hits it. At that point you just calculate the torque needed to get the same rotational speed again, based on it's current rotational speed.

As for the Box2DX project. We know that project very well and we do have plans where it's included. More info on this will come later in a post for itself.

@JeroMiya: You are right, but as for the motor feature, sometimes it's just easier and more logical to make a "motor" handle all the force/torque stuff. We are looking into features that will make it easier to use joints.

Jun 4, 2009 at 7:12 AM

Thanks for the replies. I managed to integrate the motor into the fixed joint, but not the 2-body joint. Somehow it wouldnt work properly, but Il try figure it out.

@Jeromiya: I just thought it would be easier to have the engine do all the work :)

Jun 5, 2009 at 9:50 AM

I did it!

I enabled Motors in the FixedRevoluteJoint and RevoluteJoint. Its almost the exact Box2DX code, just copy and pasted, so credit to them.

The joints work exactly the same as before, and if you want to enable the motor you call: Motor_Enabled = true; Motor_Speed = 2.0f; Motor_MaxTorque = 10.0f; with your own values :)

I put the 2 joints in the patches section, so if you want you can look over them and put them in the new release.

Im gonna see if I can do the PrismaticJoint too, because moving pistons would also be nice :)

Jun 5, 2009 at 1:07 PM

I wasn't trying to discourage the motor idea, I just meant to say basically that I thought the motor should be a separate class outside the joint that we attach to the joint. That way if people want a different kind of motor or to customize the existing motor, that's easier to do. Also, with the motor now integrated in the joint, you have another check for a bool "if(Motor_Enabled) { <handle motor> } which causes overhead for all of that type of joint, regardless of whether the motor is enabled. With a separate class, it doesn't cause overhead unless you use it.

Now, as long as we're providing helper sugar, I think we should provide some additional features (I don't know what we get from the Box2D code so some of this might be covered):

  • * able to define the shape and size of the acceleration curve. Provide a few built in choices (linear, cubic, logarithmic, parabolic, etc..)
  • * make the acceleration curve calculation a virtual function so it can be customized (I think this is less overhead than a delegate? anyone know for sure? If not, a delegate system would be cleaner). This will help tweak the wild variations from constant speed.
  • * motor senses current rotational acceleration/deceleration and factors that into the acceleration curve. So, for example, the motor may provide slightly more torque for an object that is decelerating fast than an object that is decelerating slow, even if the objects are both currently going the same speed (some speed less than the desired speed). An object that is accelerating (rolling down a hill maybe), may get little or no torque to better fit the accelerating curve. The motor would have to factor in how much acceleration is due to the motor itself.



Jun 5, 2009 at 1:20 PM

@robertdodd: Thats great. I'm very glad to see people helping in the additions to Farseer.

@JeroMiya: The Curve class in XNA actually does what you are asking. It even comes with an editor. Check it out and let me know. You can find it here -