crashcourse kids
The Robot Challenge: Crash Course Kids #47.1
YouTube: | https://youtube.com/watch?v=0GMBJFqgHfc |
Previous: | Normal Stuff in Not-So-Normal Places: Crash Course Kids 46.2 |
Next: | Architecture Adventure: Crash Course Kids #47.2 |
Categories
Statistics
View count: | 250,928 |
Likes: | 1,003 |
Comments: | 0 |
Duration: | 04:27 |
Uploaded: | 2016-03-03 |
Last sync: | 2024-11-10 04:00 |
Citation
Citation formatting is not guaranteed to be accurate. | |
MLA Full: | "The Robot Challenge: Crash Course Kids #47.1." YouTube, uploaded by Crash Course Kids, 3 March 2016, www.youtube.com/watch?v=0GMBJFqgHfc. |
MLA Inline: | (Crash Course Kids, 2016) |
APA Full: | Crash Course Kids. (2016, March 3). The Robot Challenge: Crash Course Kids #47.1 [Video]. YouTube. https://youtube.com/watch?v=0GMBJFqgHfc |
APA Inline: | (Crash Course Kids, 2016) |
Chicago Full: |
Crash Course Kids, "The Robot Challenge: Crash Course Kids #47.1.", March 3, 2016, YouTube, 04:27, https://youtube.com/watch?v=0GMBJFqgHfc. |
Robots! They're everywhere. We use them for all kinds of things that we can't, or don't want to do. In this episode of Crash Course Kids, Sabrina shares a problem with us that can probably be solved by building an awesome robot. So let's take the robot challenge!
///Standards Used in This Video///
3-5-ETS1-1. Define a simple design problem reflecting a need or a want that includes specified criteria for success and constraints on materials, time, or cost.
Want to find Crash Course elsewhere on the internet?
Crash Course Main Channel: https://www.youtube.com/crashcourse
Facebook - https://www.facebook.com/YouTubeCrash...
Twitter - http://www.twitter.com/thecrashcourse
Tumblr - http://thecrashcourse.tumblr.com
Credits...
Producer & Editor: Nicholas Jenkins
Cinematographer & Director: Michael Aranda
Host: Sabrina Cruz
Script Supervisor: Mickie Halpern
Writer: Allyson Shaw
Executive Producers: John & Hank Green
Consultant: Shelby Alinsky
Script Editor: Blake de Pastino
Thought Cafe Team:
Stephanie Bailis
Cody Brown
Suzanna Brusikiewicz
Jonathan Corbiere
Nick Counter
Kelsey Heinrichs
Jack Kenedy
Corey MacDonald
Tyler Sammy
Nikkie Stinchcombe
James Tuer
Adam Winnik
///Standards Used in This Video///
3-5-ETS1-1. Define a simple design problem reflecting a need or a want that includes specified criteria for success and constraints on materials, time, or cost.
Want to find Crash Course elsewhere on the internet?
Crash Course Main Channel: https://www.youtube.com/crashcourse
Facebook - https://www.facebook.com/YouTubeCrash...
Twitter - http://www.twitter.com/thecrashcourse
Tumblr - http://thecrashcourse.tumblr.com
Credits...
Producer & Editor: Nicholas Jenkins
Cinematographer & Director: Michael Aranda
Host: Sabrina Cruz
Script Supervisor: Mickie Halpern
Writer: Allyson Shaw
Executive Producers: John & Hank Green
Consultant: Shelby Alinsky
Script Editor: Blake de Pastino
Thought Cafe Team:
Stephanie Bailis
Cody Brown
Suzanna Brusikiewicz
Jonathan Corbiere
Nick Counter
Kelsey Heinrichs
Jack Kenedy
Corey MacDonald
Tyler Sammy
Nikkie Stinchcombe
James Tuer
Adam Winnik
Okay, listen up people! I need your help. You're going to have to help me engineer my way out of a challenge. The challenge being, I kinda dropped my phone down a sewer.
I know, I know. I was walking down the street and it slipped out of my hands and went right into the storm drain. And, um, I'd kind of like it back. But that's where you come in because this is exactly the kind of problem that can be solved with the help of engineering.
You know that engineers design and build things, like machines, systems or structures, to help solve problems. And all kinds of problems, not just phones in sewers. How can we cross deep, dangerous canyons? How can we solve complicated math problems if we don't have a pencil and paper?
You can thank an engineer for solutions to all of those problems: hang-gliders, calculators, and the list goes on and on. So, now I need your help to unleash the power of engineering to fix my problem. So, how do we use the engineering process to get my phone back?
First, let's review the process. This is crucial.
One, define the problem. Okay, I need a way to retrieve my phone from a storm drain.
Two, consider solutions. There's more than one solution to any problem so we need to think through different options and choose the best one. Brainstorm time.
I can tie a rope to the drain and lower myself into the darkness. Or, I could use a fishing pole to retrieve it. Or, I could build a robot that would go down there for me and bring it back.
Now, I don't want to go down there. It's dark, and scary, and the potential for getting sewer water on me is way to high. Next.
What about using a fishing pole? I think my phone will be hard to pull up with a hook. Plus, I won't be able to see where I'm aiming the pole. It seems like this option isn't the best.
What's left? Oh, yeah! The coolest option. Robots are used to do tasks that people can't or don't want to do. And that means a whole lot of robots are being designed for this sort of thing. Not retrieving phones from storm drains, maybe, but flying down into caves, exploring the ocean floor, and even visiting other planets.
So, let's engineer a robot.
It'll have to be able to fly and be remote controlled. And, so I can see where it's going it'll need a little camera. And it'll need a suction cup to stick to the phone and carry it to my loving hands.
Now, next we need to build a prototype that we can use for testing. We need to test, or conduct trials, in order to ensure success. And for those trials to be really useful we have to isolate the variables.
So, what are the variables of our mission? We've got the depth of the sewer drain. That can't be changed so it's called a fixed variable. We also have the size and weight of the phone, which are more fixed variables.
Then, we have the pieces of our super cool robot: the propellers, the suction cup, the camera.
When we finally get to testing the robot, we need to isolate each of these variables and test them one at a time in pretend "missions." That way, we can see which variables affect how well our robot performs.
Like, maybe the robot can carry something the size of a pencil but it completely crashes when it tries to hang on to my phone. That would be a failure point.
But, we can find ways to science around that. If it can't lift something as heavy as my phone, maybe we can make the propellers bigger. Either way, we'll keep tweaking the variables until we get the outcome we're looking for.
Then it's all systems go. Hang on wet and smelly phone, here we come!
Today we had a challenge. We had to retrieve something from a deep place that we couldn't see. And we had to deal with various variables to find a solution. Variables like the depth of the drain, the weight of the phone and the strength of the propellers that made the robot fly.
Together we came up with a pretty awesome design solution. But, like I said before, there can be lots of different successful solutions. So, here's your challenge: Can you come up with your own solution? What would your robot look like? How would it get the job done and navigate the variables. Put your brain to work, and see what you can come up with.
As for me, this isn't the first jam that engineering helped me to get out of, and I'm sure it won't be the last.
I know, I know. I was walking down the street and it slipped out of my hands and went right into the storm drain. And, um, I'd kind of like it back. But that's where you come in because this is exactly the kind of problem that can be solved with the help of engineering.
You know that engineers design and build things, like machines, systems or structures, to help solve problems. And all kinds of problems, not just phones in sewers. How can we cross deep, dangerous canyons? How can we solve complicated math problems if we don't have a pencil and paper?
You can thank an engineer for solutions to all of those problems: hang-gliders, calculators, and the list goes on and on. So, now I need your help to unleash the power of engineering to fix my problem. So, how do we use the engineering process to get my phone back?
First, let's review the process. This is crucial.
One, define the problem. Okay, I need a way to retrieve my phone from a storm drain.
Two, consider solutions. There's more than one solution to any problem so we need to think through different options and choose the best one. Brainstorm time.
I can tie a rope to the drain and lower myself into the darkness. Or, I could use a fishing pole to retrieve it. Or, I could build a robot that would go down there for me and bring it back.
Now, I don't want to go down there. It's dark, and scary, and the potential for getting sewer water on me is way to high. Next.
What about using a fishing pole? I think my phone will be hard to pull up with a hook. Plus, I won't be able to see where I'm aiming the pole. It seems like this option isn't the best.
What's left? Oh, yeah! The coolest option. Robots are used to do tasks that people can't or don't want to do. And that means a whole lot of robots are being designed for this sort of thing. Not retrieving phones from storm drains, maybe, but flying down into caves, exploring the ocean floor, and even visiting other planets.
So, let's engineer a robot.
It'll have to be able to fly and be remote controlled. And, so I can see where it's going it'll need a little camera. And it'll need a suction cup to stick to the phone and carry it to my loving hands.
Now, next we need to build a prototype that we can use for testing. We need to test, or conduct trials, in order to ensure success. And for those trials to be really useful we have to isolate the variables.
So, what are the variables of our mission? We've got the depth of the sewer drain. That can't be changed so it's called a fixed variable. We also have the size and weight of the phone, which are more fixed variables.
Then, we have the pieces of our super cool robot: the propellers, the suction cup, the camera.
When we finally get to testing the robot, we need to isolate each of these variables and test them one at a time in pretend "missions." That way, we can see which variables affect how well our robot performs.
Like, maybe the robot can carry something the size of a pencil but it completely crashes when it tries to hang on to my phone. That would be a failure point.
But, we can find ways to science around that. If it can't lift something as heavy as my phone, maybe we can make the propellers bigger. Either way, we'll keep tweaking the variables until we get the outcome we're looking for.
Then it's all systems go. Hang on wet and smelly phone, here we come!
Today we had a challenge. We had to retrieve something from a deep place that we couldn't see. And we had to deal with various variables to find a solution. Variables like the depth of the drain, the weight of the phone and the strength of the propellers that made the robot fly.
Together we came up with a pretty awesome design solution. But, like I said before, there can be lots of different successful solutions. So, here's your challenge: Can you come up with your own solution? What would your robot look like? How would it get the job done and navigate the variables. Put your brain to work, and see what you can come up with.
As for me, this isn't the first jam that engineering helped me to get out of, and I'm sure it won't be the last.