Background

The Mars Rover: Landing Challenge Unit will challenge your students to build VEXcode GO projects to solve a problem. This Unit introduces students to using the Eye Sensor on the front of the Code Base in a challenge, inspired by the process scientists use while attempting to land spacecraft, like the Mars 2020 Perseverance rover. Students will code the Code Base to detect an obstacle, then stop driving to indicate an obstacle was found on the landing site.

NASA’s Mars 2020 Mission

NASA’s Mars 2020 Mission addresses high-priority science goals for Mars exploration: life, climate, geology, and humans. But before the Perseverance rover can begin its mission gathering rock and soil samples on the surface, the rover needs to safely land on the Red Planet.

According to NASA, only about 40% of missions ever sent to Mars (by any space agency) have been successful. The entire process of Entry, Descent, and Landing will take only minutes, but the spacecraft carrying the Perseverance rover needs to slow down from almost 20,000 km per hour (~12,500 miles per hour) to zero and find an open, flat area to land. The martian surface is full of obstacles — massive impact craters, cliffs, cracks and jagged boulders. Unpredictable winds can also stir up further complications.

To help ensure a safe landing, the Perseverance rover will take images while descending and compare those images to the maps. It quickly can decide if that area was determined to be hazardous by scientists, and make adjustments to land in an open area. Watch the animation below to better understand the rover's decision process using descent photos.

In this Unit, students will be coding the Code Base to detect obstacles at the landing sites on their Fields to help ensure a safe landing for the rover.

What is a sensor?

A sensor is, in essence, a device that helps a robot to understand the world around it. It does this by collecting and reporting data about its environment, which can then be used in a project to make the robot make decisions, or perform certain behaviors. This sequence can be thought of as a Sense → Think → Act decision loop.

In this Unit, the Code Base will be using the Eye Sensor to detect objects on the Field to help clear the area for a safe rover landing. The project students create carries out this loop as the Eye Sensor on the Code Base will Sense the presence of an object, then the VEXcode GO commands Think to make a decision based on whether the Eye Sensor detects an object or not. Then the Code Base will Act and stop driving based on the presence of the object.

What is the Eye Sensor?

The Eye Sensor is a sensor that can determine three things - the presence of an object, its color, and the brightness of an object or surface. In this Unit, the Eye Sensor is used to detect an object so that it can be cleared from the landing area. The data reported by the Eye Sensor can be seen in the Monitor Console, which offers students a visual representation of what the robot is 'seeing,' and can be used to help them make the connection between the sensors and the behaviors of the robot. For more information about using the Monitor Console in VEXcode GO, see this VEX Library article.

The Eye Sensor on the Code Base - Eye Forward build is located on the front-facing side, as shown in the image below. The Eye Sensor can be used to detect the presence or absence of an object, as well as its color or brightness level. 

The Eye Sensor uses infrared light to detect objects. Light-colored objects reflect infrared light and are detected more easily by the Eye Sensor. Dark-colored objects absorb infrared light and the Eye Sensor does not detect them as well. During the Unit, use white or light-colored paper for the obstacles to ensure that the Eye Sensor will be able to detect these objects.

In this Unit, the Eye Sensor will be used to detect when an object is present in the path of the Code Base. The position of the Eye Sensor on the Code Base means that it can only detect objects directly in front of it. Be mindful of this when you are placing your Code Base and obstacles with your students so that the materials are setting students up for success. 

For more information about the Eye Sensor and how it works, see the Coding with the VEX GO Eye Sensor VEX Library article.

What is VEXcode GO?

VEXcode GO is a coding environment that is used to communicate with VEX GO robots. Students use the drag and drop interface to create VEXcode GO projects that control their robots actions. Each block’s purpose can be identified using visual cues such as its shape, color, and label. For more information on how to work with VEXcode GO, see the VEXcode GO Section of the VEX Library.

The blocks in VEXcode GO represent robot commands that are used to create a project in VEXcode GO. Below is a list of the main blocks used during this Unit.

VEXcode GO Blocks	Behaviors
	The {When started} block begins running the attached stack of blocks when the project is started.
	The [Drive] block moves the Drivetrain forward or reverse forever.
	The [Turn for] block turns the Drivetrain for a given distance.
	The [Forever] block repeats any blocks contained inside the ‘C’ forever.
	The [Wait] block waits for a specific amount of time before moving to the next block in a project.
	The [Wait until] block waits for the condition inside of it to report TRUE before moving to the next block.
	The <Found object> block reports if the Eye Sensor detects an object.
	The [Stop driving] block stops the Drivetrain.
	The [Set bumper color] block sets the color of the LED Bumper.

How does the [Wait until] block work with the Eye Sensor? 

In this Unit, students will use the Eye Sensor on the Code Base to detect obstacles in the landing area of the Mars rover. To code this, they will use the [Wait until] block in a project. The [Wait until] block is a Control block that repeatedly checks a condition to control the flow of a project. A project will not move to the next block until the condition in the [Wait until] block reports as true. In this Unit, the [Wait until] block is used with the <Found object> block as the condition - so that it will wait until the Eye Sensor detects and object, and the condition of the <Found object> block is true - to move on to the next block in the project. 

The [Wait until] blocks can be used in conjunction with non-waiting blocks, like the [Drive] block in this Unit, so that the Code Base can drive forward until the Eye Sensor detects an object. Watch the animation below to see the [Wait until] block being used to stop the robot from hitting an obstacle.

To see the project flow in real time as your robot is running, watch the Highlight Feature in VEXcode GO. At the beginning of the project, the green highlight will appear around the [Wait until] block until the condition is true. The green highlight will appear to skip the non-waiting blocks (in this case the [Drive] block) because these commands are quickly executed. 

In this Unit, students will use a combination of waiting blocks, like the [Wait until] block, and non-waiting blocks, like the [Drive] block, in their projects to complete the Lab activities and challenges. To learn more about waiting and non-waiting blocks in VEXcode GO, read this VEX Library article. 

Preparing for Open-Ended Challenge in this Unit

In this Unit, students will be asked to use what they have learned previously to create a project to solve a challenge. Because it is important to regularly challenge students to problem-solve and apply the skills that they have been learning in a new way, we encourage you to challenge your students and use these strategies to build resilience and help guide them through the challenge. Here are a few suggestions to help students as they experiment with their projects: 

Give feedback without giving the solution - Making errors while working through a challenge is expected and encouraged. “Errors in learning can create opportunities, [and] can help realize connections.”¹ Creating a familiar problem-solving process with your students can help them learn how to identify a problem and move forward when they make an error, thereby minimizing disruption and frustration. Try using the following problem-solving cycle with your students to help them troubleshoot their projects and come up with their own solutions. 

• Describe the Problem
  • Ask the student to explain what is wrong. Students should be able to relate the error back to the shared goal or the challenge at hand.
    • How is the Code Base moving in their project? How should the robot be moving? 
• Identify When and Where the Problem Began
  • Ask the student when they first noticed the problem.
    • What part of the project was being executed?
  • If students are having difficulty determining where in the project the error is, encourage them to use the Project Stepping feature in VEXcode GO. The visual cues provided with the Project Stepping feature can be used to help students troubleshoot their project by having the ability to see the blocks being executed one at a time. This will give them a better visual of which blocks may be causing the error, so debugging can become a more targeted and efficient process. For more information on how to use the Project Stepping feature, see the Stepping Through a Project in VEXcode GO VEX Library Article. 
• Make & Test Edits
  • As students find an error, they should make edits to their project. Students can test the project with each edit made. If the project is successful, then they can move onto the next step in the problem-solving cycle. If the project is not successful, they can go back to the beginning of the process and try again.
• Reflect
  • Ask students to think about the error they made and overcame during the process.
    • What was the mistake? What did you learn from this mistake? How can it help you when coding the Code Base next time?
  • Encourage students to recognize their mistakes and what they learned from the process to help encourage a growth mindset. A strong emphasis on a growth mindset can help students to learn when and how to persist and also when to ask for help.² If students can see their process as a precursor to new learning, then they can use the steps here to further their own learning as well as furthering the learning of their classmates. As students come across these issues and reflect upon their errors, encourage them to share their errors and process with fellow students. In this way, students can become “learning resources for one another.”³

Clear the Landing Area (Lab 2) is designed to be an open-ended exploration that will ask your students to persevere to solve a challenge. In this Lab, we introduce loops with the [Forever] block and ask students to experiment with using loops in their project to have the Code Base drive to and detect all the obstacles on the landing area (GO Field). If using loops in a project is new for your students, it may take several iterations of their projects to use loops effectively. Use the suggestions outlined in this section to prepare students for the trial and error process, and to help them troubleshoot their projects to achieve the goal of the challenge. The Facilitation section of Play Part 1 and 2 contain additional instructional supports for guiding students through the Lab 2 challenge. Having a plan for how you will provide support for the problem-solving and trial and error that is required in this Lab can help you meet the individual needs of your students.

See the Building Resilience in STEM Labs VEX Library article for more information on how effective feedback can help students build resilience and a growth mindset while working through STEM Labs.

¹ Hattie, John, and Shirley Clarke. Visible Learning: Feedback. Routledge, Taylor & Francis Group, 2019.

²  Ibid.

³ Ibid, p. 121