Constructing a Can Sized Sat With Steering - CanSat 2025

This project documents the development and launch of two functionally identical CanSat satellites, RocketMan and StarMan, engineered by a Lithuanian high school team under the RMSM initiative. Both CanSats were designed to be launched to an altitude of approximately 1.5 km and perform autonomous data collection, orientation estimation, telemetry transmission, and active landing trajectory control.

The primary mission objective was to perform CNN-based terrain classification and mapping using aerial images taken during descent. This required an onboard Raspberry Pi to process environmental data and camera feeds in real-time using a lightweight convolutional neural network (CNN) model. Due to computational and power limitations, careful optimizations had to be made in model architecture and sensor sampling.

The secondary mission aimed to implement steerable descent using a Ram-Air–type parachute. Data from a GPS receiver and IMU sensor were fused to dynamically adjust servo motor positioning, pulling control lines of the parachute to alter descent trajectory toward a pre-defined landing zone. A servo-driven pulley system provided a differential of up to 14 cm between the lines, resulting in significant heading correction.

Sensor suite: dual BMP280 barometric/temperature sensors, an ICM20948 IMU, GPS (L76K or ATGM366H), and a Raspberry Pi Camera v3.

Microcontroller platform: Raspberry Pi Zero W/2W selected for its performance-to-size ratio.

Power system: Two 3000 mAh Li-ion batteries connected in parallel, with step-up converters and capacitive buffering for stability.

Power monitoring: INA219-based wattmeter for real-time voltage and current sensing.

Communication: Dual 433 MHz telemetry modules (HT03-V2.3 or E220-400T 22D) with omnidirectional antennas and ground station amplification.

Descent control: A continuous-rotation MG90S servo motor controlled the parachute’s steering lines for mid-flight directional adjustment.

The entire system was tested under resource constraints — weight, budget (under €200 per unit), processor power, and thermal handling. Components were mounted inside custom 3D-printed PLA/PETG chassis designed for modularity and repairability. Thermal and mechanical challenges such as overheating and electrical contact instability were resolved through selective polling, strategic placement of capacitors, and flexible mechanical mounts.

This Instructable will walk through:

1. Designing sensor and power interfaces using I2C, UART, and PWM
2. Integrating power-safe logic for Li-ion operation
3. Building steerable parachute mechanics
4. Developing a full telemetry pipeline from airborne platform to ground station

We will limit our conversation to exclude CNN algorithms since that is a huge topic for another day. But first, let's outline what we plan to do:

Main Goal: Use a camera and an AI model (a Convolutional Neural Network or CNN) to identify and map features of the ground below, like forests, roads, and fields, while falling from the sky.

Second Goal: Use GPS and motion sensors to figure out where the CanSat is and then steer a special type of parachute to guide the CanSat toward a specific landing spot. This is done with a small motor (servo) that pulls on parachute cords.

Design Limits:

1. Weight: Each CanSat had to weigh under 350 grams.
2. Power: Two 3000 mAh lithium batteries provided power, giving about 4.6 hours of operation.
3. Budget: Each unit was built for under €200.

Success Measured By:

1. Sensors collecting accurate data (position, orientation, energy use, etc.)
2. Good communication with the ground station via radio
3. Ability to control where it lands within 10 meters of the target
4. All systems working without failure

Peripherals Overview

Each CanSat included several sensors and parts:

1. Two BMP280 sensors for measuring air pressure and temperature
2. An IMU (Inertial Measurement Unit) to measure orientation and motion
3. A GPS module to track location
4. A small camera to take pictures
5. A wattmeter to monitor power usage

All the sensors except for the GPS and radio communicated using the I2C protocol, which allows multiple devices to share the same two wires. The GPS and radio used UART, a different communication method. Since the Raspberry Pi Zero W only has one built-in UART port, we had to get creative and use a trick called "bit-banging" to simulate a second UART connection for the GPS.

The onboard computer, a Raspberry Pi Zero W, was chosen for its small size and relatively strong computing power. It could run both the AI mapping software and control the sensors.

Two different radio modules were used for wireless communication:

1. RocketMan used an HT03-V2.3 radio.
2. StarMan used an Ebyte E220-400T module.

Both radios worked on the 433 MHz frequency and were connected to custom-built antennas. The expected range for communication was about 1.7 kilometers.

To make all the parts work together, we had to carefully plan how everything was wired and powered.

Data Communication:

1. I2C lines were split off to allow easy troubleshooting in case of issues.
2. Only one UART port was available, so the GPS communication was simulated using extra GPIO pins.

Power Supply:

1. Power came from two lithium-ion batteries connected in parallel.
2. A special diode was used to protect against reverse polarity.
3. A switch and a voltage regulator ensured stable power.
4. 5V lines powered the Pi, GPS, servo, and radio.
5. 3.3V lines powered the sensors.

Power Monitoring:

1. A wattmeter (INA219) was used to track how much energy the CanSat was using.
2. Two capacitors (2200μF and 470μF) were used to smooth out sudden changes in power draw, especially when the servo motor was active.

The CanSat systems were programmed entirely in Python. This language was chosen for its balance of flexibility, speed of development, and compatibility with Raspberry Pi platforms. Python allowed for rapid prototyping and testing, while still supporting structured, modular code for each part of the mission.

Code Structure

The software was structured using a hybrid of functional and object-oriented programming. Each module or subsystem was organized into a dedicated Python file, where the logic followed three major phases:

1. Initialization – Setting up hardware interfaces, loading constants, and checking system health
2. Execution – Performing the module’s main function (e.g., reading sensors, calculating positions, sending data)
3. Shutdown – Cleaning up, stopping sensors, or saving final states for safe shutdown or reuse

Some parts, like the BMP sensor class, used full object-oriented design for easier scaling and modularity. This helped ensure every sensor instance was isolated and could be swapped or disabled without affecting the rest of the system.

Radio Module

The radio was controlled using a dedicated class that handled UART serial communication. It implemented:

1. A log() function to send data over UART, echo to the terminal, and write to local storage
2. Simple error handling: if the radio module failed to start, the CanSat would continue logging data locally
3. Line-based telemetry every second using comma-separated values (CSV), keeping transmission minimal and parse-friendly

The ground station worked on the same principle, with one thread listening and another transmitting. If a command needed to be sent (like reboot), it was handled via this two-way link. If signal was lost, the radio would retry connection, and only the latest data would be sent after reconnecting, to keep telemetry current.

GPS System

Because Raspberry Pi has only one reliable UART port (used for the radio), GPS communication was handled using a software-emulated serial interface (bit-banged UART) via the pigpio library.

1. A background thread continuously read GPS messages (NMEA sentences)
2. The $GPGGA and $GNGGA messages were parsed to extract time, latitude, longitude, and altitude
3. If the GPS failed to initialize, the rest of the system continued running without blocking

Servo Control and Parachute Steering

The continuous-rotation servo was controlled using PWM signals. The system used calibration data to convert angle commands into motor runtime:

1. Clockwise motion at PWM = 1300 µs (approx. 5/3π rad/s)
2. Counter-clockwise at 1700 µs (approx. 2π rad/s)
3. Neutral (stationary) at 1500 µs

Using the current location (GPS) and orientation (IMU), the flight computer calculated the heading difference to the target zone, and determined how long the servo should run in each direction to adjust the parachute.

These constants were stored in a config.py file so the target location or max deflection could easily be adjusted.

As the CanSat approached the final 50–100 meters of descent, the control system switched into a precise landing mode. Calculations used:

1. The Madgwick filter to smooth and interpret IMU data for accurate heading
2. The Haversine formula to compute the direction and distance to the target

Sensor Handling and Fail-Safes

Every sensor had dedicated error handling:

1. If a BMP280 sensor failed, the system would continue using the remaining one
2. If both BMPs worked, their readings were averaged
3. Any GPS failures would result in empty data being logged but not block the mission

This level of modularity ensured that even in partial system failure, the CanSat could still complete most of its objectives.

The design focused on using off-the-shelf parts to save time and money. Most of the body was 3D printed using PLA or PETG plastic.

Differences Between the Units:

1. RocketMan had a side-mounted sensor platform to better fit the larger HT03 radio.
2. StarMan had a simpler, central layout with the Ebyte module.

Assembly:

1. The body was split into a main frame and a top lid.
2. There was a dedicated space for the batteries that could be accessed quickly before launch.
3. Sensors were attached using metal rods and printed brackets.

Challenges:

1. Vibration sometimes caused power loss. We fixed this with spring contacts and backup capacitors.
2. Some sensors produced heat, so we had to slow down how often we read them to avoid incorrect readings.
3. The Raspberry Pi also got hot, so we optimized the code to reduce processor load.

To guide the CanSat during descent, we used a Ram-Air style parachute (like those used in paragliding). It was designed using free software called SingleSkin (see our config files)

Specs:

1. 7 air pockets
2. 28 lines
3. Surface area: about 0.1 square meters
4. Fall speed: about 6–7 meters per second

Materials:

1. Lightweight nylon fabric for the parachute
2. Thread and string from construction supplies for the lines

How It Works:

1. Two control lines are wound in opposite directions around the servo's pulley.
2. Turning the servo unwinds one line and winds the other, changing the parachute’s shape and direction.

RocketMan and StarMan serve as proof that complex aerospace-inspired systems can be developed using accessible materials and open-source tools—even in a high school setting. Through the integration of machine learning, real-time sensor fusion, and basic mechanical control, this project demonstrated how a CanSat can be more than just a data logger—it can be an intelligent, self-guided platform.

Despite time limitations, lack of full-scale flight testing, and academic pressure, the team managed to complete two nearly identical CanSats that could navigate, collect environmental data, and transmit it back to a ground station in real time. While the steering capabilities were only validated in theory and bench tests, the groundwork has been firmly laid for future enhancements or mission iterations.

This project pushed boundaries in a student-led context and showcased how curiosity, teamwork, and technical learning can combine into something that flies—not just physically, but as an idea worth sharing. The hope is that this Instructable can inspire others to build their own versions, test their limits, and bring more DIY aerospace projects to life.