BotSat - Flight Hardware - Part 2

In this second part of the BotSat flight hardware series, we’ll delve deeper into the payload design.

As you may recall from earlier posts, this project evolved from a previous CanSat mission, and we found ourselves with leftover components as well as a few additional miscellaneous parts.

The original CanSat payload focused on detecting atmospheric gases at various altitudes and testing the logic for deploying a multi-stage parachute. However, we didn’t have a gas sensor available this time around, and realistically, a gas sensor wouldn’t be particularly exciting on a BotSat anyway. Thankfully, we did have extras of most other essential flight components, including:

• GPS module
• Barometer
• IMU (Inertial Measurement Unit)

The GPS module was originally intended to aid in payload recovery after a soft landing. Given the chaotic nature expected during this BotSat flight, our hopes for a soft landing were slim. Nevertheless, we included the GPS module out of curiosity about what kind of positioning data—if any—we might capture during such an unpredictable flight.

The barometer and IMU were crucial for accurately tracking flight dynamics. We’ll explore the data from these sensors in greater detail in a future post.

For our flight computer (microcontroller), we utilized some spare Seeed Studio XIAO ESP32C3 boards I had leftover from another project. This turned out to be an excellent choice, as I’ll explain shortly.

The original CanSat utilized an Arduino Nano Every, which unfortunately gave us numerous problems—especially when attempting to read multiple sensors and manage communication across several UART connections. UART (Universal Asynchronous Receiver-Transmitter) protocols require precise timing, and the Arduino Nano Every only provides two hardware UARTs. With additional tasks like controlling servos and reading sensor data via I2C, the team constantly struggled with timing and interrupt conflicts. In contrast, the ESP32C3 offers more resources, and since we had no servos or additional gadgets to manage, our task became much simpler. If you’re planning your own mission, carefully consider your microcontroller’s capabilities to match your specific needs.

For communication, the original CanSat flew missions with the recommended APC220 radio module, which provides excellent range but is relatively slow at just 9600 baud. To overcome this limitation, the previous team implemented a simple yet effective binary communication protocol. Inspired by this, we ported the solution to use UDP over the built-in WiFi capability of the ESP32. At the time, I hadn’t realized just how powerful this bottle rocket would be—I had initially envisioned launching from the backyard, comfortably within range of our home WiFi network.

Another advantage of the ESP32C3 is its built-in LiPo battery management, allowing a simple, direct connection of a 3.7V LiPo battery to solder pads underneath the board. Provided your power requirements remain within what the ESP’s 3.3V bus can supply, you can power your sensors directly from this setup.

So, after reviewing and selecting our hardware, the finalized payload consists of:

• Seeed Studio XIAO ESP32C3
• Seeed Studio Grove GPS Air530 (Seeed Wiki)
• GY-LSM6DS3 six-axis accelerometer (generic)
• GY-BMP280 barometer (generic)
• 400mAh 3.7V LiPo 403040 battery