New video: Solving Kinematic Constraints #22
Replies: 48 comments 4 replies
|
To model a realistic door opening, keep the two hinge constraints and replace the vertical motion constraint with a rotational one by prescribing the angle, e.g, 𝑞_3=𝜔𝑡+𝜃_0, so the door rotates about the fixed hinge with one degree of freedom. For a doorknob, define its position using body offsets (a,b), giving 𝑥_k = q_1+a cos q_3-b sin q_3 and y_k = q_2 + a sin q_3 + b cos q_3, and constrain it to follow a desired hand path (x_h(t),y_h(t)). However, since the system only allows one additional independent constraint beyond the hinge, the most consistent approach is still to drive the motion through a single parameter like the door angle, with the knob naturally following its circular path about the hinge. |
|
I think if we wanted to consider the constraints on the door using the door knob, the easiest way would be to create a system where we push the door outward. I tried modeling this in julia, |
|
Based on my research it looks like one of the driving factors might be...you cannot move the knob strictly horizontally without the hinge also moving, unless the door's angle Suggested update: #have angle rotate Here is suggested animation: anim = @Animate for i in 1:length(time_steps) gif(anim, "door_push.gif", fps=20) Let me know @jordanbollacke if this works. |
|
To model a door attached to a hinge, the only constraints required to properly constrain the door to rotational movement are the hinge constraints. Using q[1] - W/2cos(q[3]) - T/2sin(q[3]) - mx and q[2] - W/2sin(q[3]) + T/2cos(q[3]) - my, the door becomes a 1 degree of freedom system where motion is limited to be purely rotational about the hinge. If you wanted to account for someone pushing on the door handle then a third constraint would need to be added that describes the motion of the door due to the speed of the door knob, q[1] + W/2cos(q[3]) + T/2sin(q[3]) - (knob_x0 + knob_speed*p). This constraint prescribes the x-position of the knob tip as a linear ramp in time, where knob_x0 is the initial knob position and knob_speed is the rate at which it moves outward. |
|
Similar to everyone else I maintained the hinge as a constrained point and then used the motion of the angle created by the door knob swinging to be able to describe my overall equation. When you do this based on my research on how to do this you will get the following (adjusting for coordinate location to be to the door knob). In my attached code you will find the problem assuming the door knob is on the right side of the door half way down. With this assumption we assume the following: Angular Velocity: Euler's Equation then gets updated to include a moment of inertia which would be Io = 1/2 m* This does not include a dampening feature which would be friction from the hinge but might be interested to see how it will change to include this. 
|
|
To model a realistic door, keep the two hinge constraints and prescribe the door's rotation directly (q_3=ωt+θ_0), giving it a single degree of freedom. for the doorknob, define its position using local offsets from the door body, but constraining it to a specific hand path would add an extra constraint that the system cannot support. Therefore, the simplest and most consistent method would be to drive the motion solely through the door angle, with the knob following its circular path around the hinge. |
|
I added the doorknob to the simulation; it is the red ball. the trace of the doorknob motion is shown in red. multiple door positions are shown below: I gave the knob local offset |
|
Hi, I like the addition of the knob placement in this plot. While it is a simpler case, it shows that because the door is constrained about a single hinge (revolute joint), the door knob will of course follow this path, as it is a rigid body attached to the door. As your equations show, it is described by an offset from the center of the door. |
|
I also found it easier to represent and describe in cylindrical coordinates. I found it really interesting that you chose to add a body to the to the door and describe that motion |
|
In reviewing the kinematic equations for the door, it’s clear that transitioning from a 0-DOF system to a force-driven one requires careful constraint management. Most of the current models assume a fixed hinge and a prescribed angular velocity, q3 = w*t + theta_0, which effectively drives the motion. To model the doorknob position (xk, yk) relative to the center of mass (q1, q2) with a door width W and thickness T, we can use the following transformation: xk = q1 + (W/2)*cos(q3) - (T/2)*sin(q3) yk = q2 + (W/2)*sin(q3) + (T/2)*cos(q3) If we try to constrain the doorknob to a specific hand path while the hinge is already fixed, the system often becomes over-constrained. This is likely why some solvers return "NaN" or "Singular Jacobian" errors; the door would technically have to "stretch" to satisfy both the hinge position and a non-circular hand path simultaneously. To improve stability, we could implement a constraint that drives only the x-position of the knob as a function of time p: |
|
I modified the original 0-DOF door kinematics by replacing the third constraint, which originally prescribed the door motion directly, with a doorknob-based constraint while keeping the two hinge constraints fixed. In the updated model, the generalized coordinates become (q=[x_1,;y_1,;\theta_1,;\phi]), where (\phi) represents knob rotation. The new third constraint prescribes the vertical position of the knob in the ground frame, (y_1 + x_H\sin\theta_1 + y_H\cos\theta_1 - f(t)=0), so the door is driven through the knob location rather than through the body center, and a fourth constraint, (\phi-\phi_d(t)=0), prescribes the knob rotation. This keeps the system fully constrained while making the formulation closer to how a real door is operated: motion is enforced at the hinge and through the knob instead of by directly prescribing only the door angle. |
|
The original door model is a 0‑DOF inverse kinematics system because hinge constraints fix the door position and an additional time‑dependent constraint defines the motion. To allow free opening, the driving constraint is removed, leaving a 1‑DOF joint. |
|
In the lecture, the door's motion is prescribed by constraining the center of mass directly with |
|
To change the constraints on the opening door, I would make the motion less fully prescribed and instead allow the door to rotate based on an input at the handle or hinge. Right now, if the system is 0-DOF, the motion is already fixed, but changing the constraints could let the motion depend on how the force is applied, which would make it closer to a real physical system. For the door knob, a possible constraint equation could relate the position of the hand or knob to the circular path of the door as it rotates about the hinge. In other words, since the knob stays a fixed distance from the hinge, its motion must follow an arc. So the constraint would enforce that the knob always remains that same radius away from the hinge while the door opens. This way, the motion of the knob is directly tied to the rotation angle of the door. |
|
The motion of the door can be described defining the door angle as q3=ωt+θ0q_3 = omega t + theta_0q3=ωt+θ0. This definition guarantees that the door just rotates about the hinges in the theta direction. The equations for the position of the door knob can be written with respect to the location of the center of gravity as: yk = q2 + (W/2)*sin(q3) + (T/2)*cos(q3) These equations show the knob following a circular path around the hinge. Modifying the system otherwise may result in overconstraining the system - something like forcing the path follow a path that isn't circular. That would imply that the system isn't rigid. |
|
If I were to modify the constraints on the door-opening model, I would shift away from a setup where the motion is completely enforced and instead allow the rotation to result from an applied interaction. In its current 0‑DOF form, the door’s rotation is predetermined, meaning the simulation only computes the forces required to satisfy that motion. A more realistic representation would be to keep the hinge constraints that fix the door’s position in space but remove the imposed rotational law, allowing the door angle to evolve based on an applied force or torque at the hinge or handle. This change better reflects how doors behave in practice, where motion arises from how the door is actuated rather than being prescribed. |
|
After going through the video and reading through everyone’s posts, I’m seeing a pretty consistent theme that the original setup is a fully constrained (0-DOF) system where the motion is basically forced, not solved for. The vertical constraint on the center of mass works mathematically, but it doesn’t really match how a door actually opens. If I were to change the constraints, I would keep the two hinge constraints the same (since those correctly fix the door to rotate about a point), and then replace the vertical motion constraint with something tied to the doorknob instead. A few people mentioned prescribing the angle directly (like To do that, I defined the knob position using the rigid body transformation from the door frame to the global frame: Then instead of prescribing motion at the center of mass, I set the knob to move outward in the x-direction like: This leads to the constraint: This is what I implemented in my code, where the hinge equations stay the same and the third equation is replaced with this knob-driven motion. One thing I noticed (and a few others mentioned too) is that if you try to force the knob to follow something that isn’t consistent with the door rotating about the hinge, the system breaks pretty quickly. That helped it click for me that the knob is already constrained by the rigid body motion, so you really only get one extra constraint to drive the system. Anything beyond that and you’re basically over-constraining it. |
|
After looking over other people’s posts, it does seem that over-constraining the system becomes a problem when the knob path is not compatible with the hinge rotation. Do you think this happens because the door knob constraint is forcing the system to follow a motion path that conflicts with the rigid body motion of the door itself? It also made me think about biomechanics models where joint constraints may not fully match natural human movement so you end up with unrealistic values. |
|
Rather than a 0-DOF system where the motion is completely prescribed and the forces exist to enforce, we could alter the constraints of the scenario to represent a realistic situation with constraints and from a doorknob. This scenario would boil down to 1-DOF. To portray the scenario more clearly, the doorknob functions as the initial input. If it is rotated enough, the locking mechanism will release, and allow the door to swing about its hinge (torque). The hinge and the doorknob each allow 1-DOF. There are two axis in this scenario, one with the door about its hinge, and the other with the doorknob about its own axis. The motion of the doorknob directly influences the motion of the door meaning that the DOF are coupled together, reducing DOF of the system to 1-DOF total. To effectively couple the two together and determine kinematic equations for the system, the location of the doorknob relative to the door/hinge will be necessary. In this scenario you would end up with a constraint equation for a fixed hinge, a constraint equation which limits rotational DOF like tilting and twisting, the coupling constraint, and the doorknob locking constraint. |
|
The video made it clear that this door example is a 0-DOF system, meaning the motion is completely prescribed and the forces just exist to enforce that motion (inverse dynamics). The original setup uses hinge constraints plus a motion constraint on the center of mass, but that doesn’t really reflect how a real door is opened. A more realistic approach would be to drive the motion through the door knob instead. I would still keep the hinge constraints the same since they correctly define the rotation of the door. Then, instead of constraining the center of mass, I’d define the knob’s position based on the door’s angle and apply a constraint that moves the knob, like pulling it outward at a constant speed. One important thing I noticed is that you have to be careful not to over-constrain the system. The knob is already tied to the door through rigid body motion, so adding too many constraints can make the system inconsistent. Overall, changing how the constraint is applied (center vs. knob) doesn’t change the DOF, but it does change how the motion is enforced and interpreted physically. |
|
When opening the door, the constraints would change from prescribing the vertical motion of the center of mass to prescribing the rotational motion about the hinge. Instead of using a driving constraint like R_1y=2t we can directly prescribe the door angle as a function θ_1=ωt where ω is the constant angular speed of the door. This becomes the new driving constraint added to the system. The hinge constraints would remain the same because the hinge location is still fixed to the ground. The only change is the motion input used to drive the mechanism. A constraint equation can also be created using the door knob position. Since the knob location is offset from the door center by (xH, yH) its position in global coordinates is: |
|
In reviewing the kinematic equations for the opening door, I would change the constraints by driving the motion through the door knob instead of the door's center of mass or angular motion directly. Since the hinge already fixes the door at one point, it provides two constraints, so only one more independent constraint is needed to fully define the motion of this 0-DOF system. The knob position can be written relative to the door’s center of mass as xk=q1+(W/2)cos(q3)−(T/2)sin(q3) and yk=q2+ (W/2)sin(q3)+ (T/2)cos(q3), where q1 and q2 are the center of mass position and q3 is the door angle. A possible knob constraint would be to prescribe only one component of the knob’s motion, such as C3(q,p)=q1+ (W/2)cos(q3) - (T/2)sin(q3) - (xk0+ vp) = 0, where xk0 is the initial knob position, v is the pulling speed, and p represents time. I would avoid prescribing both the x- and y-positions of the knob unless the hand path matches the knob’s circular path around the hinge, because otherwise the system could become overconstrained and cause solver errors. |
|
For the opening door problem, I would keep the hinge constraints the same because they correctly force the door to rotate about a fixed point. Instead of setting the motion at the center of mass, I think it makes more sense to set the motion through the doorknob since that is how a real door is opened. If the knob is located at a fixed position offset from the door center, its position can be written as: x_k = x_1 + x_Hcos(θ) - y_Hsin(θ) and y_k = y_1 + x_Hsin(θ) + y_Hcos(θ). A possible knob constraint equation would be C(q,t) = x_1 + x_Hcos(θ) - y_Hsin(θ) - (x_0 + vt) = 0. This forces the doorknob to follow a set path, which causes the door to rotate about the hinge. I also think you should not to over constrain the system by setting the x and y motion of the knob unless the path exactly matches the motion of the door. |
|
For the opening door, the system is fully constrained (0-DOF) — the hinge fixes rotation to one axis and the motion is prescribed, so the solver works backwards to find the forces enforcing that motion (inverse dynamics). To change the constraints, you'd swap the prescribed angular motion for a different kinematic condition — for example, adding a door stop would introduce a unilateral constraint (θ ≤ θ_max), and adding a door knob introduces a latch constraint that must be satisfied before the door can move at all. For the knob specifically, you can model it as a two-phase constraint: while the knob is unturned, the latch position s is fixed (Φ_latch = s − s₀ = 0, 0-DOF, pure inverse dynamics); once the knob is rotated past a threshold angle φ > φ_release, that constraint is released and the door is free to swing, transitioning the system to a 1-DOF forward dynamics problem driven by whatever force is applied to the door. |
|
One way to change the constraints on the opening door system would be to allow more degrees of freedom. In the original example, the door behaves like a rigid body rotating about a fixed hinge, so the hinge constraint forces the motion to follow a circular path around the hinge point. This creates a 0-DOF multibody system because the motion is entirely defined by the constraint equations. To modify the constraints, we could allow the hinge to slide vertically, include a spring-damper hinge, add flexibility in the frame, or allow the door to both translate and rotate like a sliding door. |
|
This discussion helped tie together many of the core ideas from the course, especially how Lagrangian mechanics, generalized coordinates, and energy methods provide a unified framework for modeling complex systems. Looking back, it’s clear how concepts like least action, constraints, linearization, and damping all build on one another rather than standing alone. I also appreciated the emphasis on connecting the math to physical intuition through simulations, animations, and phase plots. Those tools made it much easier to interpret stability, energy flow, and system behavior without relying solely on equations. Overall, this discussion reinforced how powerful and flexible the Lagrangian approach is, especially for systems that would be difficult to analyze using traditional force‑based methods. It was a helpful way to step back and see how everything fits together. |
|
In the door opening example, we’re looking at a classic inverse dynamics problem where the motion is totally dictated by our constraints, making it a 0-DOF system. To change how the door opens, we could move away from a simple linear path and instead prescribe a rotational driving constraint. By setting the door's orientation coordinate to a function of time—something like theta(t) = omega * t—we force the door to swing at a constant angular velocity. This replaces the "pushing" motion with a more natural pivoting motion centered on the hinges. Modeling the doorknob adds a cool layer of detail to the kinematic equations. Since the knob is a fixed point on the rigid body of the door, its position is defined by the door's center of mass plus a local offset. We can write the position of the knob as x_k = x_cm + r * cos(theta) and y_k = y_cm + r * sin(theta), where r is the distance from the center of mass to the handle. If we wanted to simulate a person's hand actually pulling the knob along a specific trajectory, we would set these knob coordinates equal to a prescribed path, like x_hand(t) and y_hand(t). However, as the classmate’s post mentioned, we have to be careful with "over-constraining" the system. Since the hinges already lock down the door’s translation, adding a specific hand path as a constraint might conflict with the circular arc the door is forced to take. The most robust way to handle the doorknob in an MBD sense is to let the door's rotation be the primary "driver" and treat the doorknob's position as a dependent variable that we track for visual verification or for calculating the specific forces a hand would need to apply to maintain that rotation. |
|
I think the door knob constraint makes it a little more complicated versus when you just pick the door angle directly. Since the knob is attached to the door, its position depends on the hinges location and its angle. If the hinge is fixed at (xh, yh), then the knob postion could be written like: Xk = Xh + Wcos(theta) W is the distance from the hinge. And if we wanted to constrain the knob to a certain path: Xh + Wcos(theta) = Xtarget(t) = 0 We need to make sure the knob stays at a fixed distance from the hinge, following a circular path with the hinge at its center. If we are pushing the knob, the constraint probably has to make sure the knob's path is physically possible for a real door. |
|
The original door problem is a 0-DOF system, meaning the motion is completely prescribed by the constraint equations. The hinge constraints keep the door attached to a fixed point, while another constraint controls how the door opens. Instead of prescribing the motion through the center of mass, a more realistic approach would be to drive the motion using the doorknob. The hinge constraints would remain the same because they correctly force the door to rotate about the hinge. One common way to describe the door motion is by directly prescribing the angle q3 = ωt + θ0. This forces the door to rotate at a constant angular speed. However, the motion can also be driven through the knob position instead of directly controlling the angle. If the knob is located at a fixed offset from the center of the door, its global position can be written as xk = q1 + xHcos(q3) - yHsin(q3) and yk = q2 + xHsin(q3) + yHcos(q3). Here, q1 and q2 represent the door position, q3 is the door angle, and xH and yH are the local offsets of the knob from the door center. A possible constraint equation for opening the door with the knob could be q1 + xHcos(q3) - yHsin(q3) - (x0 + vt) = 0. This forces the knob to move along a prescribed path, which causes the rest of the door to rotate naturally about the hinge. One important thing to consider is avoiding over-constraining the system. Since the knob is already attached to the rigid door, forcing both the x- and y-motion of the knob can create impossible motion unless the path perfectly matches the circular motion of the door. Because of this, it is usually best to prescribe only one independent knob constraint while letting the remaining motion follow from the rigid body geometry. |
|
I would keep the hinge constraints because they are what physically attach the door to the wall and force the door to rotate about one fixed point. The part I would change is how the opening motion is prescribed. Instead of directly controlling the center of mass, I think it makes more sense to describe the motion through the doorknob, since that is where a person would actually apply the motion. The knob can be treated as a point fixed on the rigid body. Its global position depends on the hinge location, the distance from the hinge to the knob, and the door angle. If the hinge is located at where W is the distance from the hinge to the knob. From there, a constraint could be added by comparing the knob position to a desired motion path. For example, if the knob is being guided by some target path, the constraint would force the knob location to match that target. The important part is that the target motion has to agree with the fact that the door rotates about the hinge. The knob cannot just move in any random straight-line path because it is attached to the door. Its motion should follow the arc created by the rotation. If the knob path is prescribed in a way that does not match the hinge motion, the system could become inconsistent or over-constrained. Overall, I think using the doorknob is a more realistic way to drive the motion, but the hinge still controls the actual allowable movement of the door. |
|
Using the hing fixed point to prescribe the path of the doors angle as the main constraint using the equation theta(t) = wt + theta_o. Then the doorknob position can be obtained from the offset from the hinge. as the door rotates the knob will follow a circular path. This seems to be the cleanest setup since the doors motion is controlled by a single angle, while the knobs position just comes naturally from the geometry of the system. Below is a graph for the position of each component and the angle of the door. |
|
The video showed that the door mechanism is a 0‑DOF system, meaning its motion is fully prescribed and the forces simply enforce that motion, making it an inverse‑dynamics problem. The original setup drives the door by constraining the center of mass, but a more realistic model would apply the motion through the door knob instead while keeping the hinge constraints the same. In that case, the knob’s position would be defined from the door’s angle, and a driving constraint would move the knob, such as pulling it outward at a constant speed. The most robust MBD approach is to let the rotational motion be the primary driver and treat the knob’s motion as a dependent quantity used for visualization or for computing the forces required to maintain the prescribed rotation |
|
I think that the most surprising part of this entire course was learning that by reducing any arbitrary system to a system of constraint equations, you could evaluate the positions through just the Newton-Rhapson method. It makes a lot of sense fundamentally, and really goes to show how fast these systems can get out of hand and reach into non-analytical solution territory. |
|
To change how the door opens, I would mainly change the motion constraint instead of the hinge constraints. The door opens because the center of the door is forced to move upward over time and keeps the system at 0-DOF. If instead the rotation is applied directly, like setting the angle as a function of time, the door would open without needing that vertical translation constraint. For using the door knob, a constraint can be made based on the knob’s position. The knob can be defined as a fixed offset from the door’s body frame, and its position can be written using the door’s position and angle. Then you could constrain that knob point to move along a specific path or with a specific velocity. Forcing the knob to move would make the door naturally rotate about the hinge to satisfy the constraints, even though no forces are specifically applied. |
and others
Uh oh!
There was an error while loading. Please reload this page.
Solving Kinematic Constraints
In this video, I revisit building the kinematic equations for the opening door. This type of 'Multibody Dynamic' simulation is a 0-DOF system i.e. the motion is completely prescribed and the forces exist to enforce the motion, inverse dynamics. Project_01 was a classic dynamic problem where motion depends upon changing applied forces.
How would you change the constraints on opening the door? Can you create a constraint equation for using the door knob?
All reactions