The engineering becomes much more interesting when the requirements get specific. The system needs environmental sensors operating simultaneously, local data storage, Wi-Fi connectivity, a display, a camera, audio capabilities, battery and solar power, and enough modularity that the primary microcontroller can still be removed and used independently. All of it needs to fit within the physical constraints of a 10 cm × 10 cm × 10 cm CubeSat.
That is the challenge we have been working through while developing a CubeSat platform for hands-on programming and AI education. The goal isn't simply to make the components fit. It is to create a hardware platform that remains understandable, serviceable, expandable, and practical for repeated educational use.
Starting With the Learning Experience
The CubeSat is part of a broader educational concept combining C/C++ programming, AI literacy, and space-themed hands-on learning.
The hardware therefore has a different job than a conventional demonstration board. Students should be able to write software that interacts with real physical systems rather than limiting exercises to output in a browser or terminal.
The platform was designed around several types of interaction:
- temperature, humidity, and atmospheric pressure measurement
- acceleration and movement sensing
- air-quality sensing
- camera input
- voice recognition and audio output
- an onboard OLED display
- local microSD data logging
- Wi-Fi communication
- battery and supplementary solar power
That creates opportunities for programming exercises involving sensor acquisition, data analysis, logging, conditional logic, visualization, and communication.
It also creates a much harder hardware-design problem.
Designing Around a 10 cm Cube
A standard 1U CubeSat is approximately 10 cm on each side. For our educational design, those dimensions became a useful engineering constraint rather than simply a visual theme.
Not all of that volume is available to the electronics.
The lower 3.575 cm of the current design is allocated to the charge controller and battery. The frame also consumes approximately 1.1 cm along each side. That leaves an available area of roughly:
8.9 cm × 8.9 cm × 6.425 cm
for the Arduino, expansion hardware, sensors, storage, display connections, camera interface, and associated wiring.
This immediately changes how components have to be evaluated.
A development board might work perfectly on a desk but become impractical when its connectors require cables extending in several directions. A sensor module may be electrically small while creating cable-management problems. The location of a microSD slot matters if students or instructors need to reach it after assembly.
Mechanical design and electronics design therefore cannot be treated as independent tasks.
Choosing a Familiar Microcontroller as the Foundation
The current platform is centered on the Arduino UNO R4 WiFi.
For an educational product, using a familiar development ecosystem has significant advantages. The objective isn't to hide the electronics from students. The microcontroller is part of what they are learning to use.
The Arduino also needs to remain removable from the CubeSat's expansion hardware. That allows it to be taken out and used with a breadboard or with sensors that aren't permanently incorporated into the CubeSat.
That requirement led us toward a stacked architecture: the Arduino remains the recognizable foundation while an expansion board sits above it and provides the connections needed by the integrated CubeSat hardware.
This is an important distinction between designing a prototype and designing an educational platform.
Permanently integrating everything could potentially produce a cleaner package. But doing so would sacrifice some of the flexibility that makes the system useful for teaching.
Making Multiple Sensors Work Together
A major requirement is that the core environmental sensors can operate simultaneously.
The planned architecture includes pressure, temperature and humidity sensing, acceleration, and air-quality measurement, along with additional peripherals for the display and audio functions.
Several of these devices use I2C.
That is useful in a space-constrained design because I2C allows multiple devices to share the same bus rather than consuming separate microcontroller connections for every peripheral. But sharing a bus also means the system needs to be considered as a complete architecture rather than as a collection of individually working modules.
Other peripherals introduce different interfaces.
The camera design uses a serial interface, while microSD storage uses SPI. The system therefore combines several common embedded interfaces within one small platform.
For students, that diversity is valuable. It creates the possibility of progressing beyond simply reading a single sensor and introduces the idea that embedded systems frequently coordinate devices using different communication methods.
For the hardware design, it means pin allocation, expansion-board design, cable routing, power distribution, and physical accessibility all have to be considered together.
Power Is Part of the Architecture
The CubeSat is primarily powered through the Arduino's external USB-C connection, with supplementary power supplied through a 5V solar charging system and an attached 3.7V lithium battery.
The current hardware estimate places average system consumption at approximately 350–400 mA at 5V when accounting for the Arduino, sensors, display, storage activity, camera, and periodic voice/audio operation.
With the estimated 2,000 mAh battery configuration and conversion losses taken into account, the design estimate is approximately 3 to 3.5 hours of continuous battery operation.
These numbers are design estimates rather than claims about final production hardware, but performing the calculation early is important.
It is easy to add another sensor to a parts list. Every addition, however, affects the power system.
The camera, display, Wi-Fi radio, storage writes, sensors, and audio subsystem all contribute to the total load. Solar generation then has to be considered alongside the limited external surface area of the CubeSat, where panels may ultimately compete with cameras, antennas, access points, or other components.
That makes energy management part of the lesson as well as part of the product.
Designing for Access, Not Just Assembly
Compact electronics have a tendency to become difficult to service.
That is particularly undesirable for educational hardware, where components may need to be inspected, replaced, demonstrated, or disconnected repeatedly.
We established several physical requirements to help prevent that problem.
The microSD card needs to remain externally accessible and face a side that isn't occupied by a solar panel. The OLED needs to remain clearly visible from either the top or side. The Arduino needs to be removable. Connectors should favor a consistent, compact approach, with JST PH connectors preferred where appropriate. Sensors and connectors should also be labeled to make debugging easier.
Even the expansion board has mounting requirements, including plated 3 mm mounting holes positioned at its corners.
Individually, these details may seem minor. Collectively, they determine whether a prototype that works once on a workbench can become a platform that someone else can actually use.
Modularity Creates Room for the Platform to Grow
One of our more important design requirements is that the electronics remain compact enough to support other form factors in the future.
That discourages solving today's packaging problem with a one-off arrangement of wires and boards that only works inside the current enclosure.
Instead, the CubeSat is being treated as a modular system.
The expansion hardware handles the integrated peripherals while the Arduino remains removable. Common interfaces such as I2C, SPI, and UART connect different classes of devices. Power distribution is considered as part of the expansion design. External access is preserved for components such as removable storage.
This architecture also supports the educational objective.
A student can begin with relatively simple code that reads temperature or acceleration. More advanced exercises can combine multiple sensors, log observations to storage, transmit information over Wi-Fi, display results locally, or incorporate camera and audio capabilities.
The same physical platform can therefore support increasingly sophisticated software without requiring an entirely different piece of hardware for each lesson.
Moving From Prototype Components Toward a Product
Early development can rely on commercially available modules and expansion shields. A product intended for repeated deployment has additional considerations.
Our requirements include keeping the complete unit economical enough for scaled production, with a target of keeping the hardware cost below $250 per unit. Component sourcing is also being considered, with sensors and PCB components from North American or European sources preferred where practical.
Those constraints influence decisions long before a final PCB is produced.
There is a natural temptation during prototyping to optimize exclusively for whether something works. Product development adds additional questions:
Can it be assembled consistently?
Can someone troubleshoot it?
Are the connectors understandable?
Can a component be replaced?
Does the design leave room for future revisions?
Can the architecture be reproduced economically?
Those questions are why documenting physical dimensions, electrical interfaces, connector preferences, mounting requirements, power estimates, and accessibility requirements early in development matters.
What We Learned
The most useful lesson from this stage of CubeSat development is that small hardware doesn't necessarily mean simple hardware.
Once compute, sensors, power, storage, communications, display, camera, and audio functions share the same constrained enclosure, decisions begin affecting one another quickly.
A good hardware architecture therefore starts with the complete system rather than with the individual components.
For this project, that has meant treating physical space, power, connectivity, accessibility, modularity, and educational value as parts of the same design problem.
It has also reinforced an important principle that applies well beyond CubeSats: a successful prototype proves that something can work; thoughtful product engineering determines whether it can keep working as the project grows.
Next Steps
The CubeSat hardware is one part of a larger educational platform that also includes programming and AI lessons, a code-execution environment, and an AI assistant.
The next stages of the project include continuing the structural and electronic design, assembling the CubeSat, and developing the software and educational material that will make use of its capabilities.
The goal is not to simulate an interesting engineering problem for students. It is to give them a real one—small enough to sit on a desk, but complex enough to introduce the same fundamental questions engineers face when software has to interact with the physical world.