While the video is very helpful to understand physics a little bit, the problem of the pins going under the floor is because the animator is calling for the Lower method, and the lower method is lowering the pins after they were created on the track, rather than above.
It would be helpful for future students to see that animation may also be responsible for something like that and not physics.
Cheers.
Thanks, I wanted to suggest just that. A little bit misleading video.
As a troubleshooting video, another lesson learned would be to first disable the Physics (UseGravity, IsKinematic).
To establish if that is the issue, before diving deeper into that area.
I’m still stuck on this one. I don’t understand what you mean by the animation causing the pins to fall through the floor. The Lower state in the Animator window has no keyframes, and it’s attached to the PinSetter. How does that cause the pins to fall through the floor?
Right now, my pins fall through no matter what I set the physics to. I tried using even extreme numbers on the project physics but there’s no difference.
Hey Mike,
If you go to the PinSetter and look at the animator, go into the Reset Substate machine and look in it.
It lifts the pins, renews the pins, and then lowers them.
Try to remove the lowering altogether, because at that stage the renew is putting the new pins at floor level and not above.
Either that or check height and change the LowerPins() to check and put the pins according to world coordinate, and not relative to starting point.
You can also make sure that the pins are spawning higher than the LowerPins script takes them to.
I hope this helps. 
Hi Daniel,
Thank you for your response. I used your last suggestion and changed the lower script so that it didn’t minus the distToRaise but I left that at zero. Now the pins fall to the floor and stay put.
Thanks again! Much appreciated. 
Glad you figured it out!
Another glitch that plagued me, is sometimes the pins would be raised to double the height, and use physics to fall to ground.
After much monkeying around, I recalled the tip to NOT put Function calls at the 0.0 timeframe event. Instead increase the timeline to 0.1 or so and add events there.
Otherwise Unity may do weird things like call the function twice.
I was about to ask exactly the same question after the video, because I wanted to go sleep, but without the EXACT solution I couldn’t! 
Ben, it would be a great extra for students in the future if you put a short comment right after the video with this solution.
I found that it is important to watch out for transitions in and out of a state since the transition duration and transition time may cause Unity to repeat that state in order to give some cushion in between states, especially if your animation is rather short.
I toyed with the Interruption Source setting inside the transition to stop an animation with an event from being repeated over and over and thus either spawning too many pin sets or moving them repeatedly upwards or downwards which caused my pins to wobble from the impact of being lowered beyond the surface of the box collider.
I also found it useful to follow Daniel’s advice and let gravity pull the pins downward. I had to raise my Physics Sleep Threshold to stop the pins from wobbling on impact with the floor. I dunno exactly how lowering the Physics Default Contact Offset helps, but it did.
Yeah, I tended to forgive the gaff because I thought it was interesting to go through the Physics settings.
I didn’t pick up on the actual defect until later, because I was so busy trying to take in all the Physics settings. It was funny because the first thing I thought when I knew we were doing the Renew() method was that I better make sure that I use the same distance in the y direction as the Lower() method - and then I did something completely different because I was following the lecture.
I figured this out as soon as the video started. It’s a bit of an obvious place to look, especially if you’re a fan of play tuning while you go. I’m not sure if the instructor is getting sloppy, or whether he’s making some of these mistakes deliberately to demonstrate a point. This is going to affect the ratings a bit when I’m asked again to review this course.
After checking the manuals, here’s how I arrived at my solution:
In the Animator Inspector, for each transition, set the variables to the following:
-Exit Time = 1
-Fixed Duration = false (Exit Time = 1 is now a complete animation cycle, not 1 second)
-Transition Duration = 0 (Go quickly from one state to the next)
-Transition Offset = 0
-Interruption Source = Next State
My reasoning tells me that this makes each state iterate once and move on right to the next. It works in my game.
Also, instead of moving the Pins object up in RenewPins(), I instead move each individual pin up with a foreach statement. This is because LowerPins() also uses that method instead of moving the whole set down.
I came to forum to post exact this: that the “problem” was that the substate Reset, uses a Lower motion after the Renew motion. You just need to instantiate the pins higher (with the same offset of the Lower motion).
But I`m still wondering if @ben made all this video, not showing the real problem on porpuse, just to explain all these physics parameters
Hello there,
The problem - in my case- is not about the animator. It is just about the positioning of the pin setter. Ä°f it is a little bit above the floor or precisely on it, while renewing pins they act as they just left the pinsetter and triggering de TriggerOnExit function and destroying themselves. Lowering the pinsetter below the floor solved the problem for me!
I will be inserting a video before this later in the week, to apologies for solving the wrong problem and to point to what the issue is.
If I have just seen this before I wasted so much time and effort. Embarrassing that I noticed your solution just after I posted that same discovery (I bumped into the issue only later on so never scoped the posts for this lecture).
I also picked up on this being the actual problem a couple of minutes into the video. IMHO the whole video is extremely misleading and drags you down a path of incorrectly messing about with physics settings that shouldn’t be touched - especially when you are learning and have little idea about what the ramifications are.
Please consider redo-ing this video entirely.
Still no extra video present. This was a very frustrating problem to deal with. I was watching the whole video wondering when you were gonna figure out it wasn’t a physics issue 
I really wish I could fix this but it’s buried in history.
Moving forward we are fully prototyping all games before teaching them in future content to avoid such issues.
Thanks for speaking up, and for forgiving us.