Angular rotation for stick
Closed this issue · 15 comments
I'll bring this up to the design meeting. I'll discuss briefly the physics and then we can decide if you would like to implement the rotation of the balls.
Discussed in the 6/4/20 design meeting.
We would like to move forward with this proposal as the "Stick" behavior. Once it is implemented, we may re-evaluate the scaffolding of this feature.
@brandonLi8 please reverse the order of the nodes on the ABSwitch, and put "Slip" on the left since that is the default behavior.
It was also suggested that @brandonLi8 @veillette and @jonathanolson will spend an hour collaborating on this.
I've been thinking about this for a while now.
I did a surf around the internet for inelastic 2D collisions. Please see:
https://www.youtube.com/watch?v=Bq2QHY4AFLE
https://www.youtube.com/watch?v=p19i0gk3uFE
https://www.youtube.com/watch?v=p19i0gk3uFE
https://www.youtube.com/watch?v=Yvibaywc5D8
https://www.ux1.eiu.edu/~cfadd/1150/07Mom/Inelastic.html
In every one of these videos/articles, they go through the calculations of finding the final velocity for a perfectly inelastic collision in 2D. In all videos (without exception), they all mention that the Balls will stick together and none of them mention any rotation and do the calculation with conservation of linear momentum, as one would expect.
Although I defer to the rest of the team when it comes to the physics, I still don't quite understand this interaction.
From what I've learned, newton's third law for torques states that internal torques for the system of two balls are equal and opposite (like newton's third law for internal forces) along the plane of contact, and thus, from an outside perspective the two balls don't appear to rotate. I did a quick google search and found this, https://physics.stackexchange.com/a/354529, which states:
the torques [only] cancel out if and only if the forces are applied along the line connecting the particles
which is exactly this case.
Additionally, I don't see how the balls "would have to rotate to conserve rotational momentum". Before the collision, both balls are Not rotating, and have 0 rotational momentum. Therefore, before the collision the system has 0 rotational KE. If the balls are rotating afterwards, where did the rotational momentum come from? Where did the rotational kinetic energy come into the system of balls?
For now, I don't think I want to go through the head aches of thinking about how this would be implemented. Not only would there be a significant change in the model, there would also likely be some scaffolding of this feature in the view. In my opinion, rotation is beyond the scope of this simulation, which is about the conservation of linear momentum and it is not worth it to go through this.
@brandonLi8 , I looked at the videos you posted.
These videos are typical of undergraduate college physics. They gloss over the rotation because the students would not know how to handle such complications.
In general, in 2-D and 3-D, a collision between two non-spherical objects (even a "slip" collision) would lead in general to an internal rotation. The videos you show do not demonstrate this because the details of the collisions (such as points of contacts, shape of colliding objects, etc) matter in determining the rotation of the objects. The principle of linear conservation of momentum is still valid but it does not inform you on the state of rotations of the objects. In essence, that's the reason why these videos never mention rotation.
For the 2D case, if two disk-like objects collide during a slip collision, then there will be not torque imparted on the disks. When designing the simulation, Mike Dubson chose disks for this very reason.
However, if the force during the collision is a sticky collision (say two disks with velcro colliding with one another), where the force on the disks during the collision is not necessarily normal to the plane of contact of the balls, then there should be in general a rotation that is generated.
You may want to ask Mike Dubson, on why the Flash simulation never implemented the sticky scenario. My guess is that he probably had thought about all the implications that it would entail.
The request for the completely inelastic collision in 2D (that is the sticky scenario) came from a user that probably thought it would be as simple as what is shown in the explanation videos you posted. The reality is that it is a bit more complicated.
There are essentially two steps about implementing sticky collisions with rotation.
(1) enable the velocity to change at every time step according to v=v_CM +omega times r
where omega and r will be attributes of the balls that can easily calculated during "ballistic motion"
(2) determine the omega and r value during a collision.
I would not try to implement a fully consistent solution ( say two sticky balls colliding with a third ball) as this gets to far afield.
I can help if you would like to get started.
Thanks @veillette.
I understand that the force on the balls isn't normal to the plane of contact. You outlined this in your original comment of this issue. My point, as outlined above, is even if this is the case, I still don't think (but willing to be convinced) that the Balls should rotate:
From what I've learned, newton's third law for torques states that internal torques for the system of two balls are equal and opposite (like newton's third law for internal forces) along the plane of contact, and thus, from an outside perspective the two balls don't appear to rotate.
...
Additionally, I don't see how the balls "would have to rotate to conserve rotational momentum". Before the collision, both balls are Not rotating, and have 0 rotational momentum. Therefore, before the collision the system has 0 rotational KE. If the balls are rotating afterwards, where did the rotational momentum come from? Where did the rotational kinetic energy come into the system of balls?
@brandonLi8
Maybe my explanation wasn't very clear. When i mean that the disk rotates, i do not mean that they would rotate around their own center. Rather the balls would rotate around the center of mass of the two balls that stick together.
I tried to find a good visual online but I haven't found one yet.
The simulation below, (when turning off gravity)
https://www.myphysicslab.com/engine2D/collision-en.html
shows that in 2D, any kind of collisions will generate rotation of the blocks (even when if they never stick together)
The second simulation is one with an attractive force (the mutual gravitational force) between spherical ball, which to some extent can be seen as similar as the sticky balls.
https://www.myphysicslab.com/engine2D/mutual-attract-en.html
It is not quite the same as our case, but you can the the rotation of the balls around the center of mass after they stick together.
Thanks @veillette.
I did some investigation into this because I wanted to be sure that this was correct before implementing.
I wasn't understanding how the Balls had any angular momentum before the collision and didn't understand how the Balls would rotate afterwords because of this.
However, I thought about this more and realized that it was better to think about this in the center of mass's reference frame.
I started up the sim (2 balls in explore 2D, with inelastic stick)
and added this piece of code to each step:
const a = ball1.position.minus( this.ballSystem.centerOfMass.position ).crossScalar( ball1.velocity.minus( this.ballSystem.centerOfMass.velocity ).timesScalar( ball1.mass ) )
const b = ball2.position.minus( this.ballSystem.centerOfMass.position ).crossScalar( ball2.velocity.minus( this.ballSystem.centerOfMass.velocity ).timesScalar( ball2.mass ) )
console.log( a + b );
where a + b would be the total angular momentum of the 2 balls relative to the center of mass of the 2 balls.
This yielded
-0.018749999999999996
-0.018749999999999996
-0.01875000000000005
-0.01875000000000001
-0.018749999999999996
-0.018749999999999975
-0.01874999999999998
-0.01874999999999996
-0.01874999999999997
(collision occurred)...
0 (9)
I confirmed that a collision with "slide" conserved the total angular momentum of the 2 balls relative to the center of mass of the 2 balls.
As far as the implementation goes...
In your equations:
R_subA and R_subB are the position of the balls relative to the center of mass (as shown in the code sample above).
This, your steps for implementation don't make sense to me:
There are essentially two steps about implementing sticky collisions with rotation.
(1) enable the velocity to change at every time step according to v=v_CM +omega times r
where omega and r will be attributes of the balls that can easily calculated during "ballistic motion"
(2) determine the omega and r value during a collision.
Specifically " r will be [an] attribute of the balls that can [be] easily calculated during ballistic motion."
Since r is the position of the balls relative to the center of mass of the 2 balls, and the ball is rotating around the center of mass, r is changing as the ball is rotating. So it's not as simple as calculating and storing a changing r value at the point of collision and stepping the velocity via the equation, since it changes on each step.
We also wouldn't be able to reference the center of mass (as i did in the code sample above) as there could be more than 2 balls.
This makes me think that it might be better to add the 2 balls to a data structure that represents the 2 stuck balls.
Additionally, if the velocity of the center of mass of the ball is changing (in your equation above), there must be some acceleration (Speaking in terms of the reference frame of the origin).
Currently, the position of the balls are stepped like:
ball.position.plus( ball.velocity.times( dt ) );
but this only works assuming acceleration is 0. Now that there is acceleration, we would have to use some calculus to compute the position at each step. So how would we calculate the linear acceleration relative to the origin? I'd also think that the linear acceleration relative to the origin is also changing, which complicates it even more (but I'm not sure if it does).
Note to self: use the parallel axis theorem to compute moment of inertia of balls (shperes) rotating around another axis.
In #107, I'm attempting a solution with a data structure that represents the 2 stuck balls.
I thought about it, and attempted to address the acceleration that I described above. Omega shouldn't be accelerating, meaning alpha is 0 and the only source of acceleration is the centripetal acceleration. Working in the center of mass reference frame, the centripetal acceleration is v^2 / r.
Since this is the only acceleration, I attempted to step the position using a kinematic.
However, there is still some math that is incorrect:
As you can see, the center of mass changes path, which is incorrect.
How does the acceleration of a ball in the center of mass reference frame convert to its acceleration relative to the origin?
It occurred to me that it would be much better to think of that polar in the center of masses coordinate frame. This eliminates the need to think about acceleration since alpha is 0. We can then convert back when the calculations are done.
So I went ahead and did this:
As you can see, the path of the center of mass is straight and the velocity of the center of mass is constant. I also confirmed that the angular momentum (relative to the com) of the 2 balls was constant before and after the collision through console.log statements.
Wooo!
Edit: I now also check with assertions that linear and angular momentum are conserved at all points (before and during the rotation). See https://github.com/phetsims/collision-lab/blob/CompositeStuckBalls/js/common/model/InelasticRotationEngine.js for implementation details.
Now that I've implemented a working prototype in a branch, we need to start thinking about merging this into master.
I have a few questions for @arouinfar and the design team.
- Are we supporting rotations of more than 2 balls? Currently, rotations will not work for more than 2 balls and getting it to work will require a lot more work to support this. I'm not sure what learning goals having 3 balls would cover and the implementation would be more complicated because we would have to consider all 3 (or more) balls in the rotation. My recommendation would be to set the number of balls to 2 and disable the number picker that changes the number of balls when it is perfectly inelastic and sticky.
EDIT: now that I'm thinking about it, I have an idea of how to implement this, though I don't want to spend the time to do it unless we need it.
-
What happens when one of the balls in the rotating stuck balls cluster hits the border? I would assume both balls stop moving and have 0 velocity, but I'm not sure and I wanted to double check.
-
What happens when the user sets up a rotation collision (like in the video above), then pauses the sim and changes the elasticity. Should the balls continue rotating? Or should they stop rotating and collide off of each other based on their current velocity and position like it would normally do?
Edit: the behavior in master is that when the elasticity changes, they stop rotating.
From design meeting 6/25/20:
It was decided to make the range for elasticity [5, 100] for Explore 2D and add a separate screen for perfectly inelastic collisions in 2D.
The new screen will limit the balls to 2 and have several pre-defined states. It was also decided to remove the ball index labels and draw a connecting line along the line of impact when the Balls are rotating.
I said in the design meeting that the easiest option to make the rotation look more realistic was to draw a connecting line along the line of impact.
I would like to rescind that. I think rotating the labels is much easier. In fact I did it with about 5 lines of code (locally, not pushed):
It was indicated that the we were going with the easiest in terms of the implementation. So I'm going to do this instead of the connecting line when I implement the 4th screen.
I've changed the elasticity range to 5-100 for Explore 2D and moved the stick-slip ABSwitch to the 'Inelastic' screen. I've also implemented the rotating labels and added different presets to the inelastic screen.
Other decisions for the inelastic screen will be tracked in #114 so I think this issue can be closed.