top of page

ASTRAEUS

Prototype Solar Support Rover 

Engineering Requirements

Limitations

The Astraeus prototype was intentionally scoped to balance both ambition and feasibility. To be ensured the project remained achievable within the available time, budget, and resource constraints. The limitations outlined below were not merely obstacles, but deliberate design boundaries established to focus on core functionality, proof of concept, and our project timeline.

 

Scale and Functionality:
Astraeus was designed as a scaled-down prototype to validate key engineering concepts including rocker-bogie suspension, modular power systems, and solar panel cleaning. It does not represent the full mechanical scale, ruggedness, or redundancy required for deployment on Mars. The prototype focused on demonstrating subsystem integration rather than simulating the exact environmental conditions of extraterrestrial operation.

Component Selection:
To maintain affordability and accessibility, the team selected commercial off-the-shelf (COTS) components, including hobby-grade servos, consumer microcontrollers, and non-radiation-hardened sensors. While sufficient for a terrestrial prototype, these parts lack environmental endurance, fault tolerance, and precision of space-grade electronics.

 

Autonomy & AI Capabilities:
Full AI-based navigation was outside the project’s scope. Instead, Astraeus uses QR code detection for identifying solar panel targets and Sharp IR distance sensors to align precisely 10 cm away from the panel before initiating cleaning. This control sequence provides reliable behavior in a controlled test setting but does not generalize to unstructured exploration, SLAM-based mapping, or adaptive routing in dynamic environments.

 

Panel Orientation  Constraint:
To ensure mechanical stability and simplify cleaning arm operation, Astraeus was limited to cleaning panels mounted at a fixed 45-degree angle. This orientation was chosen based on physical testing constraints and recommendations from a NASA solar array specialist, who affirmed that this is a reasonable starting point for early-stage prototyping. The specialist noted that future Martian solar farms may include panels with variable orientations or sun-tracking capabilities, and suggested designing for cleaning adaptability in future versions [A].
See Appendix A for the full email excerpt from NASA

 

Testing Environment:
Terrain testing was performed on standard Earth surfaces with uneven obstacles. Although the team obtained 1 kg of MGS-1 regolith simulant, full environmental testing in UCF’s Martian soil pit was not completed due to a cost of $1200, which exceeded the project budget. The cleaning brush was tested on MGS-1 applied to a test panel, but traction and suspension behavior on true regolith-like terrain remains unverified.

 

Power and Runtime Constraints:
The estimated power consumption was based on the final comprehensive power budget, and the system was powered by a 12V, 30Ah LiFePO₄ battery. However, extended runtime tests beyond two hours were not performed. Testing focused on short-duration functional sequences. Battery degradation, thermal behavior, and peak surge response were not assessed under prolonged use.

 

Communication:
Astraeus uses a local server configuration hosted on the onboard Raspberry Pi, which serves a custom web interface for system control and monitoring. This architecture allows for direct interaction through any device connected to the same local network, either via a hotspot hosted by the Pi itself or an external Wi-Fi access point. While this method is efficient for short-range testing and demonstration, it limits the rover’s operational range to areas with controlled wireless access. This setup does not support long-range wireless communication, remote telemetry, or autonomous data uplink capabilities such as those required in actual planetary missions. For this reason, real-time communication and system diagnostics were restricted to line-of-sight operation within a lab or field test environment. Implementing true remote telemetry would require additional hardware such as LoRa, cellular, or satellite modules, which were beyond the scope of this project.

 

Contact us

bottom of page