Science, design and technology inside a mission that has to work.
At a glance
Students work as a team exploring the Solar System and every stage introduces a scientific or design problem, so coding, electronics, building and 3D modelling are not presented as separate exercises but become the tools the group uses to build a solution, test it and change it.
Programmes have been documented with year five primary and lower secondary students, including editions organised into thirty-hour modules.
The class does not start with a list of software to learn but with a problem to face, because the central question is what a mission needs in order to continue, which resources are required, which devices can be built and how a solution can be put to the test.
The design of the programme also includes a challenge around an autonomous system for producing oxygen, which enters a given edition only when time and equipment allow.
Students are not spectators at a demonstration, because they have to gather information, discuss a solution, divide it into parts, build, programme and test, while different teams can take on structure, programmed behaviour, 3D representation or the scientific side and then bring the work back together into a shared result.
The value of the programme lies exactly in the fact that no single tool already contains the solution.
A device or a structure is built from physical materials, a part of it can be programmed, an element can be modelled in 3D and the whole is then tested and changed, so the process shows clearly that a technical project does not arrive complete but goes through successive attempts.
I prepare the problem, hold the continuity between stages and introduce each tool at the moment it is needed for a precise step, and when a technical difficulty threatens to absorb all the time I reduce the complexity without taking the design decision away from the group.
The programme works on ideas from science, technology, mathematics and physics alongside coding, electronics, tinkering and 3D modelling, but the observable goals are more concrete, because they are about translating a problem into requirements, building a first solution, programming a behaviour, representing an element in three dimensions, comparing a proposal with its constraints and explaining to the group why a change should improve the project.
The design draws on project-based learning, tinkering, cooperative learning, moments of gamification, exchange between groups and iterative revision, but in practice this simply means that the class faces problems, shares out responsibilities, builds solutions, tests them, changes them and tells the other groups what it found out along the way.
What remains are prototypes, circuits, preparatory sketches, 3D models and successive versions of the same object, which are also the best way to document the programme. The available sources confirm that the activities took place but contain no formal evaluation of outcomes, so no measured improvements are reported.
The number of stages, the complexity of the prototypes and the balance between electronics, coding and 3D modelling change with the age of the group, the hours available and the school's equipment, while the context of the mission stays the same and holds the activities together.
Tell me the age, the hours available and the equipment the school already has.
