Reproduction Steps
I am trying to use HingeConstraint.ActuatorType = Servo to make an arrow that toggles between two positions: up and down.
To do this I am using a script to set the TargetAngle.
There is no combination of AngularResponsiveness, AngularSpeed, and MaxTorque that I can use that doesn’t create “fish tailing” around the target angle. I.e. if the Target Angle = 0, the system will continually over and undershoot that target forever.
I think the control system here is underdamped.
I don’t think the current implementation is working as designed, since I can’t think of a mechanism where the current behavior would be desired.
Expected Behavior
I want Roblox Servos to work like stepper motors.
Actual Behavior
The control system never converges on the TargetAngle. See test model.
Issue Area: Engine Issue Type: Other Impact: High Frequency: Constantly
In researching whether there was a work around, I encountered another user who had the same problem and hacked around it using the TweenService. I don’t want to do that because it will spam property updates (guaranteed ordered and delivered) over the wire. I want this is sync using lossy physics updates.
There’s a theme of bugs around the new constraint types where they are all generally undamped. This is obviously bad for performance reasons and end users can’t fix it in a performant way, so some engine work here is required.
There is a simple fix for this problem.
Short answer:
Increase the density of the “Mover” part to 50, and it should solve the problem.
Long answer:
Your model attaches two bodies with huge mass ratio together with joints. Notice that the sum of the mass of the “LightPart” and the rest of the "part"s are about 700 and the mass of the Mover block is just 2. It turns out that this is a difficult problem to handle in general. We are looking into finding a long term solution for problems of this sort, i.e. creating constraints between small and large masses. However, for the time being keep in mind that bodies that are connected together with joints are more accurately simulated if they have similar masses.
The correct approach to get the behavior that you need is to use the more appropriate CylindericalConstraint. This constraints has two degrees of freedom, and allows you to have a Prismatic like constraint and Hinge like bahavior at the same time. See the attachment for how you can use this constraint in your example. Using the CylindricalConstraint you can get rid of the mover body (which was the root of the issue ) altogether. Hope that helps via-CylindricalConstraint.rbxm (8.8 KB)
From a product perspective, it seems much better to have the smallest possible set of joint/constraints and let users compose them in Studio and have them magically work.
I guess there is a tension between whether the developer needs these parts to be physically simulated (hard) vs merely animated (easy?)
Since the “mover” part in my system is fixed in position via a rigid constraint to an anchored part (the “Base” part), it is counter-intuitive to me that its density should matter.
This system also seems easier in a lot of ways compared to other systems I have seen Roblox solve, like scissor linkages. I thought our new solver had basically gotten its arms around problems like these. The only technical solution I can think of is to increase the simulation frequency for joints between mismatched part masses, the downside being you could unknowingly create a lot of performance-heavy joints.
How do car wheels work? It seems like small part/big part connections would be the most common case and that it would be very rare to have two equally sized things connected with a motor/prismatic constraint.
Generally, cars require wheel hubs, which are what the wheels are actually attached to, so that there can be a spring (and prismatic/cylindrical) between the hub and car body. I’ve never really had problems with the wheels & hubs being significantly lighter than the car body (the springs don’t really care), although I usually end up increasing the wheel density by a couple orders of magnitude while tuning. (I leave the hubs alone.)
The motors don’t seem to have any issue with that.
@Shedletsky I took a look at your report. @mileniux89 made 2 excellent suggestions, both of which should work. The root cause is indeed the mass ratio, which as they said is just a difficulty of any numerical solver. Unfortunately there’s nothing we can do other than advise you to decrease the mass ratio, though I’d go for a cylindrical constraint my self.
