FRC Physics Presentation Feedback

One problem we face every year is getting the team’s freshmen involved in engineering discussions when they haven’t yet learned the basic physics necessary to have an informed opinion. This year for the first time I’m presenting an overview of high school physics so the whole team has a baseline understanding. It also covers the basics of DC motors, gears, belt/chain, and pneumatics, because understanding how they work is critical to designing successful mechanisms. And at the end I touch on the iterative design process just because I don’t think it can be mentioned enough.

I’d love to get feedback on my presentation from some real physics teachers since I’m just a MechE grad student with no real education training. Is there anything important missing? Or something you’d present differently? Obviously there’s a verbal portion to the presentation that you’re not seeing, but the slides cover all the basics. Thanks in advance :slight_smile:

FRC Physics 101.pptx (4.6 MB)

P.S. – if you like the presentation and want to present it for your own team, feel free to use or change it however you like


I have only just downloaded the PowerPoint, and haven’t read any of it yet. However, your exceptional use of graphics on the 3rd slide describing vectors makes me want to give this an immediate 11/10 review!


Quick note: what looks like a good overview/refresher to an expert does not make a good intro to a novice. I am doing a fairly quick look at the presentation and giving “gut reaction”. I apologize in advance if it seems too blunt! :innocent: Your students will be better off having this intro, and then being given an opportunity to do related hands-on activities, than they would be without it.
That said…

Vectors: How many dot and cross products do students do on the team? If the answer is “not many”, then probably don’t need to burden freshmen with this. In my school most calculus students never see cross products.

Distance, Velocity and Acceleration: derivatives and integrals? Velocity is the derivative of position equation (vector), not distance (scalar). Displacement (change in position vector) is integral of velocity… But, unless freshmen are going to be working on the theory behind PID, rates of change are better for an intro. Also, the graph is showing area, but the area which may cause students to think the area represents the labels.

Force: no errors, but what is a force for? What does a force potentially cause? If the push and pull in the graphic were toward each other would we expect a different result? Newton’s Laws are fundamental, and confusing. There are SO many misconceptions that need to be addressed between assigning “vector” status and defining the unit. …Ah, I see more force stuff later on.

Angular, etc.: Stick to RPM. Motors use RPMs in their graphs. Students can conceptualize that rotation can have displacement, speed, and acceleration without needing polar coordinate systems.

So, I’m going to stop there. I admire you trying to give a primer on everything a student could ever need from physics to do well in FRC. However, this is not going replace hours of hands-on experience (per topic). Imagine being a freshman, watching this presentation and then being asked to figure out whether a robot’s wheels will slip or not. That problem encompasses understanding of motor output from a voltage, maximum torque for wheel size, static friction vs tangential force, etc., etc. There is a difference between having a baseline understanding and having had an introduction to equations. Students can correctly use equations their whole lives without real understanding.

In closing (sorry for the long post), freshmen do NOT need to know everything in order to participate in the iterative design process for FRC. They need to have the desire to participate, and the support to succeed. Part of the iterative process should be researching and learning what is necessary to accomplish your goals, as well as sharing with teammates who have questions.

I like this chart from


Overall, looks super awesome, absolutely better to have something like this than not.

Whenever I try to teach something to FRC students, unlike a real teacher, my goal is often simply to move students away from the state where “I don’t know what I don’t know”, and into being able to confidently say “I do not know X”.

Concretely, this usually involves:

  1. Announcing a concept exists
  2. Providing a quick picture or example illustrating the general idea
  3. Introducing enough vocabulary such that if a student needs to know, they can ask intelligent questions (to mentors or to google).

Some other specifics:

The biggest comment I’d have is I’m not certain whether a vector-first introduction is your biggest “bang for the buck”. Unless your students are already coming in with an intuitive understanding of vector quantities. IMO it’s better to start with all 1D equations (and just draw pictures to illustrate the assumptions). These can be manipulated more with simple algebra, no vector nomenclature trickery, which is more likely the skills students will be walking in the door with.

I’d be sure to explicitly talk through the “perpendicular vector as shorthand for rotation” and the right-hand rule orientation associated with it. It’s used in a few diagrams, and will likely be foreign to most freshman?


Consistent usage of bold letters or vector hats/arrows (a la \dot{\vec{p}} = m\vec{v}) could help drive understanding of vector vs. scalar quantities throughout the presented equations (again, I’m assuming freshmen won’t be able to properly assume what’s vector and what’s scalar). Alternatively (per above), re-order to introduce vectors as late as possible, and keep conversations in 1D until absolutely necessary.

But, otherwise, content looks pretty slick!

1 Like

While I agree with just about everything that @Zook had to say, I prefer the following chart a little bit better. It comes from the agile design process for software development. Any type of development can use this. Note that research is somewhere between plan and design.

The other huge benefit to this chart is that it gets people into the mindset of multiple cycles of development as opposed to one.

Thanks for your suggestions so far! To respond to a few points:

The reason I made sure to include vectors and dot/cross products is because last year we had a major mistake where a pneumatic cylinder that was supposed to extend the intake exerted its force very nearly inline with the radius it was acting upon, so it generated almost no torque even though it had a large force and radius. I want to make sure that doesn’t happen again, so I wanted to make clear which products are dots (bigger when parallel) and which are crosses (bigger when perpendicular). Other than that, I’m not really planning on making vector math that big of a deal.

Good note. I was planning on glossing over the right-hand rule for determining cross-product direction, just because I didn’t think it was that important for what we’re doing (it’s usually pretty clear in FRC cases). I will be sure to mention rotation vectors to avoid confusion though.

My plan was to quickly explain derivative = rate of change, integral = change over time. Obviously I’m not going to be teaching calculus in an hour or two, but I think it’s important to understand the relationships between displacement, velocity, and acceleration

I tried to organize it where I introduced the quantities first then explained how they relate to each other. Now that I’m looking at it though, that probably doesn’t make a lot of sense

I wanted to talk about radians and rad/s to show the conversion from linear to angular quantities (e.g. if the wheel is spinning this fast how fast is the edge moving). That basically needs to be done in radians. For stuff like motor curves I’m only talking in rpm

Of course not, and that wasn’t the goal. The goal is that when we go to decide how the robot will look that everyone can understand the general concepts instead of feeling out of their depth.

Thanks for your notes so far, looking forward to more helpful suggestions :smile:

Looks like a great overview.

We usually talk about the battery as a power source just before reviewing motor basics. The current / voltage drop constraint brings in the “why” to motor / gearing selection.


As a High School physics teacher, I’m going to give a general response to this overview.

The first questions I have: what is the goal of this presentation?
If it’s to give students all the physics they need to understand the mechanics of an FRC robot, I think it misses the mark. It’s too much too fast. or to put it another way, You cover an ocean width of content but at only about 2 cm of depth. You’re intro students would get lost after about 10-15 minutes.

My suggestion:
Break this up into multiple presentations/lessons. Start with having them describe the motion of a drive train. Define the motion through kinematics. Once they have that down, then bring in forces as the cause of a change in motion. once forces are defined you can then branch off into pneumatics, motors and energy. I would suggest not bringing in the heavier math content (dot products, sine, cosines and trig etc) until later on. You have time for that when in comes up in the build or a contrived example. These complex questions can be more easily understood when you have a concrete example to touch and look at.


The goal is that the whole team should have a baseline understanding of the physics behind the robot. It isn’t go get everyone to a level where they can actually start designing things. We still have a lot of training afterwards on how everything works on the robot and how things get designed. This presentation is so that when we are teaching why gussets should be taller in the direction they’re being bent, we don’t first have to cover what torque is.

With that in mind, do you still have the same concerns?

I think the issue is with “baseline”. Baseline can be zero. It can be a conceptual physics level… trigonometry level… Using that term seems to imply that once you have presented the material, the students will understand it, and be able to use it toward some next step.

I have been teaching physics for 17 years. Every year I need to remind myself that no matter how much CORRECT material I present/prove/demonstrate to them, unless I tease out their misconceptions and get them to see how those misconceptions do not line up with reality, I am wasting my time.

Don’t show students that an equation can support a diagram and an expected numerical answer. Show students that the equation can help describe an observation, and predict future observations. Because you want this to all center on FRC, pull up some videos of interesting robot behaviors and ask students to explain what they see using their prior conceptions. Ask them if they think there is any way to predict how fast a ball will be launched. Ask them to explain why they think a tall robot shouldn’t start/stop too abruptly. Ask students to explain what they THINK the words they are using mean. Once you get them at a point where they say “I’m not sure”, then you present new information.

*By the way, this method is way harder to facilitate… but so much more challenging and fun for the students.


Core thing I’ll challenge you to analyze as your own homework: Is a presentation on vectors the only way to prevent that issue in the future? And is it the best? Why or why not?

My general intuition after seven years of mentoring is that kids remember almost nothing we try to teach them “ahead of time”, and learn better and are more engaged when they’re learning things as they need them. In my experience, I can tell the kids about a particular physics concept in a lecture or workshop over and over and their eyes will glaze over, they won’t remember it the next day. But when I say “today we’re designing this mechanism, you need to know X and Y in order to make it strong/fast/etc enough, let’s do the calculation together” they’re completely engaged and will remember it next time. This has been true not just for me, but also for the other mentors and many student captains over the years, so I don’t think it’s just that I’m an unusually dry lecturer.

I’ve gotten some mileage out of covering a few key physics concepts very briefly during our summer workshops (say 1 slide/5 min out of an hour-long lesson), which are for returning members who’ve been learning as they go and are hungry to understand a little more of why we do things certain ways. But we’ve just about entirely stopped doing lectures and workshops for new members, and moved to “just in time” lessons that directly, immediately guide them on the next step of their projects.

It sounds like you’re dissatisfied with just-in-time physics instruction, and your motivation for this powerpoint is to move away from it. Is there a particular reason for this? Has your team had bad experiences with just-in-time lessons that are motivating you to go in this direction?


+1 to what @snichols said. Just in time learning is really good.

To support this idea, I would add an overview slide which you has hyperlinks to specific topics in your presentation. That way, you can really easily jump to a specific topic to discuss when need be. Eventually, team members will get curious enough to ask, “What’s in the rest of the slides?” That’s when you can start introducing them to more topics without motivation.


That is a very comprehensive collection of physics concepts that are illustrated very well.

Does the whole team really have to have a baseline understanding of physics behind the robot? How deep or superficial does each team member’s understanding have to be for them to be able to do well in the different roles they have chosen? Will students who are “not good at math” be intimidated/discouraged if they are presented with a lot of math they wouldn’t normally encounter for a few years?

I would suggest splitting the material into something like the following and present it to the team members who need it, over several years.

  • FRC Physics 101 - presents physics concepts in qualitative terms only with no or very little math like your “Gears Summary” slide and the first “Pneumatics” slide
  • FRC Physics 201 - focuses on basic physics principles with only algebra level math, no calculus
  • FRC Physics 301 - includes more advanced concepts like rotational acceleration, including some basic calculus concepts

I have had experiences similar to what @snichols described where it was more effective to anticipate what principles/concepts a group of team members are going to need for an imminent task and spoon-feed them only that. This approach has even worked well with the FLL teams I have mentored. In those instances, I have only presented the principles/concepts in a qualitative way. Many of the students are busy and typically would have difficulty fitting in a physics course in addition to their normal classes, robotics and other extra-curricular activities.

Edited to add: The photos in slide 20 need to be distributed around the page.

PS: slide 30 shows that you are a cultured man :wink:

1 Like

Thanks for all the feedback given so far. I really appreciate it. If you’ll allow me to push back a bit though, I think there is a good reason why we tend to push a bit harder on the hard math/science concepts than you seem to be recommending.

High school here starts in 10th grade, so the students I’m calling “freshman” are actually only have 3 years on the team. From what I understand, they learn a bit of physics in middle school, but most of it starts in 10th grade. This presentation is for all of the robot side of the team (as opposed to the community side), basically all of whom have chosen to focus their education on some STEM subject. Since the students have at most 3 years on the team, it usually goes something like:

  • year 1 – learn the basics, contribute some ideas, basic jobs around the shop
  • year 2 – start directly contributing to the robot design
  • year 3 – leadership: captain, sub-team leads, mechanism leads, etc

My goal with this presentation was to have each group get something different out of it. For the year 1 students, they’d get an overview of the basic physics and immediately see why its useful, even if they don’t know how to do it themselves. Then as they spend most of their first year learning they’ll get a better idea of how to do the math themselves. For the year 2 students, they get a review of the basic physics that they saw how to use last semester, and begin to understand the more advanced concepts (motors, pneumatics, etc). When it comes time to actually start designing things, they’ll have the equations in the back of their minds as they’re learning from their peers. For the year 3 students, it clarifies some of the more advanced stuff they might have heard about while learning to design the previous year but not fully understood, and goes over the iterative design process to help them guide the team successfully.

I was wrong in saying the goal was to give everybody a base of knowledge. I don’t expect everyone to come away from the presentation with all of its contents memorized. But I want to make sure everyone at least knows about the basic physics concepts (even if they can’t yet use them themselves), and that by the end of their time on the team most students should understand the more advanced concepts. This is just the beginning, with most of the actual learning taking place throughout the training and season.

The pictures are animated to show the motors one at a time. In fact, the whole presentation is animated to unhide one line at a time to avoid wall-of-text syndrome

1 Like

On slide 18, when mentioning the inefficiency, I think it would improve it to mention that the missing energy goes to heat.


Speaking of heat, I believe you should add something to you’re motor section about stalling and how that can “release the magic smoke.” Knowing how to prevent that can be important.

1 Like

I second this approach. I do something similar with my “Intro to Mechanisms” slide decks.

  1. I have one that gives a very simple overview of all the core mechanisms we use (i.e. what is a winch, what does a winch look like, here’s a bunch of videos showing different things you can use a winch for), which is intended to give newbies some ideas so they’ll be able to contribute to brainstorming.
  2. I have another that goes into more details of the pros/cons, physics, math, JVN Calc, CAD examples, etc. I use these for our summer workshop deep dives, and refer back to them during the year when kids are ready to sit down and design something and have questions.

Even the first one, which was basically “here’s a bunch of videos, food for thought for when you start brainstorming tomorrow” got the feedback that it was an information overload and kind of overwhelming. I think we sometimes overestimate the value of showing kids things we don’t expect them to understand yet, some will find it motivating but others will tune out or find it discouraging.


I taught college freshman physics for one year, plus six years of FRC mentoring (and a significant number of informal courses within my workplace, ranging from *nix shell scripting to geographic projections). What you have here appears to be good stuff, but I suggest turning it “inside out”. Here, Robotics is the inspiration, so I suggest starting with practical FRC problems and turning that into what the class delivers. That is, start with a problem. E.G. Why did my robot fall over when my top heavy robot accellerated or turned too quickly? Use that question to show how low the CoG must be to keep the robot upright. Lots of other cases - how do I get across the field quickly? Why is this robot so sluggish?

On the cross product, I usually like to show this with the second vector beginning at the END of the first, rather than having a common origin. This has two great advantages: in explaining torque, it is physically what is going on - 𝜏=rxF means that torque at the origin of r when F is applied at the end of r. It also makes the right hand rule easier to visualize: line up your right palm with r and bend your fingers towards the palm to align with F, torque is the direction of your raised thumb. Second, (once combined with the right hand rule), it is clearer that axb=-bxa. Later: more like the pics on slides 9 and 10. I also like to make it clear that the right hand rule is a convention rather than reality; If you were to use the left hand rule consistently, physics would work out the same (at FRC scale, anyway).

General order of presentation: I like to start with things that are well understood by most people and then moving to things fuzzily understood, and finally into those which most people are clueless or have misunderstanding: Start with distance and time* then speed and acceleration [and maybe jerk]. Then mass vs force [Newton’s laws here], followed by work [where you start out with motion and force in the same direction, then antiparallel, and finally generalize to the dot product], energy, and power. So far, everything can be point masses. Only then add angular distance, speed, acceleration, torque [cross product here], and the free body diagram.
Before getting into gears and belts and chains, cover levers. Go back to torque, then point out how useful a lever is, and finally explain these are specialized applications of the lever.

I’ve taken the “iterative design process” (engineering process) to a separate presentation. My best experience teaching the engineering process to young people has been to start with “What is the difference between science and engineering?” (tabloid answer: science asks why things happen like they do, engineering figures out how to solve a problem.) Then, cover the scientific process (which is a review for most high school students) and why it works for science. Then, consider engineering, how it’s different, and why the same process would not apply. Then, show how important it is to define the problem before designing a candidate solution, and then get into build, test, and iterate. THEN, get into strategic analysis - what are the strategic costs/benefits of a certain action (example, raising the elevator holding a game piece) takes 10 seconds, 5 seconds, 2 seconds, 1 second, half a second , or a fifth of a second? What’s the benefit of a 99%/95%/90%/80%/65%/50% reliable intake?

* OK, it turns out no one understands time, but the intuitive understanding of time works pretty well until you hit relativistic or quantum effects. Outside of designing the deep intermals of control electronics,I can’t think of any case where this has mattered in an FRC game so far.


I would say my review would be, decide who the target audience of the presentation is, and then cater it the way you want. Everyone else’s experience as mentors and teachers will be different based on demographics, students, etc.

For example, for your freshman to contribute, is it more important that they understand that the longer the rectangle of your drivetrain the harder it is for them to turn in an agile way or is it important that they understand the representation of forces intuitively so they know why the rectangle is bad?

The answer to that question is how you should cater your presentation? There will be some freshman that are going to be super into the math pieces, and will love seeing real life present itself in the form of equations. There will be others that are more intuitive thinkers, less mathematical in nature.

I think from the FRC perspective, as a mentor, its on us to realize that both of those students can and should contribute to the FRC design process equally. There is most definitely room for both types of learners, and they will both be able to contribute equally positively to the team.