PCB ‐ Design Decisions & Revisions - RoboFEIatWork/electronics GitHub Wiki

🔄 PCB - Design Decisions & Revisions

During the development and assembly of the main PCB, several design decisions had to be reconsidered based on real-world testing, hardware limitations, and time constraints. This section documents the unused circuits, lessons learned, and improvements planned for future versions.

❌ Unused or Removed Circuits

By inspecting the schematic, it’s possible to identify multiple circuits that were ultimately not used or later removed during assembly.

🛠️ Operational Amplifier Circuit

Originally, we included op-amps to amplify the PWM signals from the ESP32, based on the assumption that the motor drivers required a 0–5V signal.

However, after further research and testing, we found that:

  • The driver accepts both 0–3.3V and 0–5V PWM signals.
  • The ESP32 outputs PWM at 3.3V by default.
  • The op-amp circuit introduced instability and added unnecessary complexity.

✅ Conclusion: The op-amp stage was removed, and the drivers now receive PWM directly from the ESP32 (3.3V logic).

⚙️ Modular Approach over Full Integration

The original design aimed to fully embed all modules (step-down converters, communication interfaces, LIDAR control, etc.) into the PCB to save space and reduce wiring.

However, we found this approach was:

  • Hard to debug, due to lack of modularity
  • Difficult to assemble, given our equipment limitations
  • Unreliable, since embedded modules introduced more soldering points and risk of failure

✅ Conclusion: Step-down converters and other modules remain external for easier maintenance and testing.

🔌 LIDAR Integration

Initially, the LIDAR was supposed to be powered and read through the PCB via ESP32. However, this proved to be:

  • Unstable due to power consumption
  • Complex to implement serial communication through ESP32 in real time

✅ Conclusion: The LIDAR is now connected directly to the computer via USB, simplifying power and communication.

💡 LED Control

The PCB includes circuits for LED control, but they are currently not in use, as they are not essential for the robot’s operation.

⚠️ Planned: To implement in the future once critical systems are stable.

🔋 Second Battery Removal

Originally, we planned a second battery dedicated to powering the ESP32. However, given that the ESP32s:

  • Are mounted externally via modules,
  • Require USB connection for ROS2 communication,

It became redundant to power them separately.

✅ Conclusion: The ESP32s are now powered directly via USB from the computer.

🧩 USB Hub Implementation

As more devices were connected directly to the PC (two ESP32s, LIDAR, cameras), we faced a USB port limitation (only 3 available). To solve this:

  • We added an externally powered USB hub
  • Powered it using a 24V → 12V step-down converter on the robot

✅ Result: Stable USB connections without overloading the PC ports.

🧠 Future Improvements

🔄 Short-Term (Next Iteration)

  • Redesign the PCB to remove unused circuits
  • Optimize layout to reduce size and improve airflow
  • Improve connector interface for the motor drivers (current setup has contact reliability issues)

🚀 Long-Term Vision

  • Replace ESP32 with a custom FPGA to centralize control and feedback
  • Integrate step-down converters and communication transceivers in a more robust and compact layout
  • Possibly implement plug-and-play expansion headers for modular peripherals

📘 All design decisions are documented here to help other teams avoid similar issues and accelerate development.