In this collaborative project, student teams each take on a component of the Mars Sample Return mission in order to construct and code a model of a device capable of sending Martian rocks to Earth. Groups can use multiple coding languages simultaneously to allow all levels of coders to participate.
- Consider limiting groups to 2-4 students to ensure that all students are actively engaged, if materials allow for it.
- This project can be tailored to include as many teams as the classroom requires, with suggested team objectives highlighted below. Feel free to explore this as a project for a small group of students, wherein they explore each objective, or instead as a collaborative project for numerous groups, each with one objective that fits into the larger mission goal.
- Devices such as Micro:bit and Cubit allow for students to switch between multiple languages, such as block coding and python. This may be helpful for addressing student differentiation within groups and the class as a whole.
One of the most significant scientific advancements on the Perseverance Mars rover was that, unlike its predecessor, the Curiosity rover, which drilled holes, Perseverance can collect core samples. These rock cores, each just several centimeters long, will allow NASA scientists to explore internal rock structures as they exist on Mars, without reducing them to powder. But collecting the core samples is only the first step for the future of Mars exploration. While the scientific tools onboard Perseverance are advanced, they still are limited compared to the complexity of facilities here on Earth. Thus, the question was asked: How can we bring those samples back home for analysis? The answer is the upcoming Mars Sample Return mission.
This fleet of spacecraft, developed by both NASA and the European Space Agency (ESA), will utilize the Perseverance rover, backup sample recovery helicopters, a lander, and orbiters working together to bring Mars samples back to us.
One of the first steps in this process is to retrieve the samples collected by Perseverance with its coring tool. Collecting these samples and bringing them to a stationary lander will allow for samples to be readied for launch back to Earth. Mission architecture could have the Perseverance rover (or future helicopters, as a backup) deliver the samples to our sample retrieval lander. This specific lander would be the first ever mission to bring along a rocket, called the Mars Ascent Vehicle. The lander would transfer the samples into the rocket for launch off of the Martian surface. While returning material from Mars has been impossible in the past, this rocket was specifically created to house our Martian core samples. This small rocket will carry the samples to an orbiter above the surface for redirection back to scientists eagerly waiting for the first arrival of samples sent from another planet.
- Introduce the objectives of the mission by exploring the Mars Sample Return mission. As with many missions to other worlds, the process includes a multitude of teams with diverse backgrounds to pool their expertise. Therefore, for this mission to be successful, student groups will need to not just solve the problem assigned to them, but do so in a way that will fit into the solutions created by other teams.
- Assign or have students pick from a list of objectives required to make the Mars Sample Return mission successful. Some suggested objectives can include:
- Sample loading into rocket
- Power and energy
- Systems check
- Launch the return rocket
- Rover to lander hand-off* (see Step 3)
- Have students design a means to code their microdevices to reach their objective. How will they know the code is successful? What devices will they require to represent successful operations? Remember that student choice and availability of supplies should drive the final product. Consider framing the challenge as a “representative model.” That is to say, the rocket doesn’t need to launch, we just need confirmation that it is ready via successful coding and interface with an external device. Students should be free to explore how to represent their design, but some examples using common devices are provided below to assist with brainstorming.
- Sample loading into rocket: code a servo or motor that will allow incoming samples to be properly loaded into the return rocket. This may also include a physical or digital counter to keep track of how many samples have been received.
- Power and energy: Solar energy will need to be collected to power the sample return lander. Code a light sensor capable of signaling that it is receiving enough energy to power the station.
- Communications: In order to be certain that the lander can send and receive signals to and from Earth, we need to have active communications. This could include coding a radio receiver and/or transmitter that indicates when a message has been sent or received. This can include an audio signal too, using a speaker, although this may present a distraction in the classroom.
- Systems check: Before any launch, the mission should have an internal checklist to verify everything is ready to go. Students can code a manual input (buttons) or on-screen input (text prompt) to confirm all systems are working.
- Launch the return rocket: Once the system has confirmed everything is in working order, it’s time to launch our newly collected Mars rocks back home. Students can code the final operation via external inputs such as buttons, levers, etc. to initiate the launch countdown.
- *Rover to lander hand-off: If you have a device with the capabilities, code a distance sensor that is capable of detecting when the rover has reached the sample return station. On Mars, the rover needs to safely approach the station, so consider sounds and/or lights that indicate the right distance has been reached.
- With each student group confident in their individual code, have them determine how they will integrate their individual tasks into an integrated mission. Depending on your equipment, this can take many forms. For example, kits such as Mission Design Labs have a central hub that multiple students can connect to simultaneously. Others, such as Cubit, have ports that devices can connect to, although multiple Cubits may be needed to have enough ports for each group. Raspberry Pi’s, combined with breadboards, present the most flexibility on space, but will also require clear communication about which group is using which GPIO (General Purpose Input/Output).
- Provide ample time for revision and modification as constraints present themselves. Likely, the combined codes will not all fit together seamlessly. For students exploring more complicated coding, focus can be on the written progression of how each objective is confirmed or rejected. For groups with mixed coding levels, such as groups being split between block coding and python, consider a setup where devices can be physically connected to each other and each group can demonstrate their objective(s) one at a time.
- Upon successful launch of the core samples, have students reflect on the engineering process. This should include the complexity and tradeoffs of having multiple teams, each with different goals, highlighting the importance of teams communicating early and often.
- Encourage students to reflect on the process both as a team working on a single objective, then as a team trying to integrate with a larger whole.
- What challenges were present in the coding requirements for each team?
- How, if at all, did they change once the teams came together?
- How did integration of all the components take place?
- Did everyone need to make revisions or only certain teams?
- What other limits affected the overall success (number of ports on devices, availability of components, etc.)?
- As a summative assessment for the class, all components of each group should be able to integrate into a larger whole. Be sure to give students multiple opportunities to demonstrate the final success of the mission objectives.
- Individual groups can also be assessed using the engineering rubric.
- Refer to the engineering rubric.
- Incorporate peer reviews for the design and code of the microdevices as part of the assessment to promote student cross-communication.
- Consider extending the challenge to include how it is that we will communicate with the mission while here on Earth. This can include programming a device capable of sending written messages or detecting signals of light, depending on the types of devices available and student coding knowledge.
- Students can also code the sample collection process by building their own game in scratch.
Build a Light Detector Inspired by Space Communications
In this advanced programming activity, students will construct a light-wavelength detector to model future technology for communicating with spacecraft.
Time 2+ hours
Robotics: Making a Self-Driving Rover
In this challenge, students must program a rover to get from point A to point B on a map without driving across any of the craters located between the two points.
Time 2+ hours
Robotics: Creating a Roving Science Lab
In this challenge, students will program a rover to use a color sensor on several rock samples, allowing them to simulate how the Mars Curiosity rover uses its ChemCam instrument to analyze light emitted from geological samples on Mars.
Time 2+ hours
Make and Code a Light-Powered Device
In this challenge, you will build and program a light-powered device that can move to collect as much light as possible while not overheating.
Time 2+ hours
Code a Mars Rover Driving Game
Use Python to create a game inspired by the way NASA explores Mars with rovers.
Time 30-60 minutes