Classroom Activity
Mars Sample Return Coding Challenge
Overview
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.
Materials
Management
- 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.
Background
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.
Credit: NASA/ESA/JPL-Caltech/GSFC/MSFC | Watch on YouTube
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.
This illustration shows a concept for multiple robots that would team up to ferry to Earth samples of rocks and soil being collected from the Martian surface by NASA's Mars Perseverance rover. Image credit: NASA/JPL-Caltech | + Expand image
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.
Procedures
- 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
- Communications
- 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.
A motor is connected to an on/off switch. Image credit: NASA/JPL-Caltech | + Expand image
A microcontroller is connected to a three-LED board. Image credit: NASA/JPL-Caltech | + Expand image
A microcontroller is connected to three individual LEDs and a sound board module. Image credit: NASA/JPL-Caltech | + Expand image
A microcontroller is connected to a button switch. Image credit: NASA/JPL-Caltech | + Expand image
- 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.
Individual components are connected to a microcontroller through a MakeON Station board. Image credit: NASA/JPL-Caltech | + Expand image
Discussion
- 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.)?
Assessment
- 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.
Extensions
- 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.
