10. Output devices¶
Summary¶
Group Assignment¶
This week we measured the power consumption of output devices using a measuring instrument and compared their energy usage.
Power Supply¶
This is our laboratory DC power supply WANPTEK NPS1203W, a compact and precise unit that allows me to set and fine-tune voltage and current for testing circuits. It provides real-time monitoring of voltage, current, and power, which is essential for comparing the energy consumption of different output devices. Its stable output helped me perform accurate measurements throughout the assignment.
Important Safety Note About the Power Supply¶
On the back side of the laboratory power supply, there is a red voltage selector switch. This switch allows the device to operate either at 115V or 230V, depending on the mains voltage.
I always check the position of this switch before powering on the supply. This is extremely important: choosing the wrong input voltage can permanently damage the power supply.
Digital Multimeter (UNI-T UT33B+)¶
This is the UNI-T UT33B+ digital multimeter, a compact and reliable tool that I use for measuring voltage, current, resistance, and continuity during my electronics work. It supports both AC and DC measurements and includes essential functions such as a diode test, continuity buzzer, and auto power-off. The device is easy to use and helps me quickly verify circuit behavior and component values while developing and testing my boards.
Power Calculation – Understanding P = U × I¶
During our measurements, we used the fundamental electrical power formula:
P = U × I
Where:
P is the electrical power in watts (W)
U is the voltage applied to the device (V)
I is the current drawn by the device (A)
This equation is essential when analyzing how much energy an electronic or electromechanical component consumes. Power directly indicates how “hard” the device is working and how much load it places on the power supply.
Motor Consumption Measurement – DC Geared Motor¶
Next, we started measuring the power consumption of output devices. For this experiment, we selected two geared DC motors with different form factors to compare their performance. Our laboratory power supply displays three main parameters on the screen:
V - voltage
A - current
W - power
We gradually increased the voltage, and as a result, the current and power values also changed. We recorded all these measurements step-by-step and organized them into a table for further comparison and analysis.
We selected a small yellow DC geared motor and measured its power consumption at different voltage levels. For the measurements, we used our laboratory power supply, which displays V (Voltage), A (Current), and W (Power) in real time.
We gradually increased the voltage from 4 V to 20 V and observed how the current and power changed accordingly. All measured values were recorded in the following table:
GA25-370 Geared Motor¶
This is the second motor we tested — the GA25-370 DC gear motor (6V/280RPM). I connected the motor to the lab power supply and gradually increased the voltage. At each step, I measured the current (A) and power consumption (W) displayed on the power supply.
Here are the recorded values for this motor:
Motor Power Consumption Measurement¶
In this video, you can see how I measured the power consumption of the motors. I monitored the current draw and voltage behavior under different load conditions to understand how much power the motors require during operation. This helped me evaluate the stability of the power supply and the overall efficiency of my system.
Conclusion¶
This week we explored how different output devices behave under real electrical conditions. We measured the power consumption of two types of DC geared motors using a laboratory power supply and recorded how voltage, current, and power changed under no-load conditions. This helped us clearly understand the relationship between electrical input and mechanical output.
We also learned the importance of proper measurement tools: the bench power supply allowed precise voltage control, while the multimeter helped us verify current and power readings. By comparing the two motors, we gained useful insights into efficiency, operating ranges, and their suitability for robotics applications.
Overall, this week strengthened our understanding of how output devices consume power, how to safely work with lab equipment, and how to evaluate components before integrating them into more complex systems.
Individual Assignment¶
Problem & Solution¶
My final project is a delivery robot, and one of the most important requirements is reliable and accurate movement. For this purpose, I needed strong motors with high torque, so I decided to use two BLDC motors from a hoverboard.
At the beginning, I experimented with different Chinese BLDC drivers. I installed them onto my platform, connected the motors, and controlled everything using an Arduino. However, the robot could not move accurately — it was only able to drive straight, and the motion was unstable. I spent about one and a half months testing multiple drivers. Several of them even burned out, so I had to order replacements and continue experimenting.
While researching online, I found that many makers repurpose the original hoverboard motherboard by flashing custom firmware. This solution immediately made sense, because the hoverboard board already contains both the microcontroller and powerful BLDC drivers on a single PCB — compact and highly integrated.
I had several hoverboard boards available because earlier I bought used hoverboards from a local online shop just for the motors. So I decided to try this method. To flash the board, I used an ST-Link programmer.
The first board failed: my computer recognized it only once — I managed to remove the read protection, but on the next connection, the board no longer responded. It had an STM32F103RB microcontroller (a common F1-series chip). I tried to replace it by desoldering the chip from a Blue Pill board and soldering it onto the hoverboard PCB. Unfortunately, the board still didn’t work because several PCB traces were damaged.
Then I moved to the second board and worked very carefully. This time everything went smoothly: the firmware uploaded successfully, and the board started working with the BLDC motors perfectly.
You can find the firmware and step-by-step flashing instructions here
Jetson Nano in My Delivery Robot¶
In my final project, I decided to use a Jetson Nano as the main single-board computer for my delivery robot. Since my robot will rely heavily on neural networks, computer vision, and ROS2, I needed a powerful yet energy-efficient computation platform.
The Jetson Nano includes an NVIDIA GPU, which provides significantly higher performance for deep-learning tasks compared to Raspberry Pi or Orange Pi. This GPU acceleration allows me to run object detection, image processing, and navigation algorithms in real time — which is essential for autonomous operation.
Another important advantage is its low power consumption. Even with its GPU, the Jetson Nano can run from a 5V power supply, making it ideal for mobile robots powered by batteries.
Overall, the Jetson Nano gives my robot enough computational power to handle SLAM, obstacle detection, path planning, and high-level AI tasks, all within a compact and efficient hardware platform.
Making Final Board¶
In my robot, I designed a modular architecture where the Jetson Nano serves as the main high-level computer. The Jetson Nano sends commands to the hoverboard motor control board through the UART protocol to drive the BLDC motors. This part of the system works well, but the robot also requires several additional components:
-
A servo motor for opening and closing the top lid
-
Multiple sensors (IR, ultrasonic, limit switches, etc.) for obstacle detection and status monitoring
-
Additional low-level I/O control
The Jetson Nano does not have many GPIO pins, and it is not ideal for direct control of servos or reading multiple sensors. Because of this, I decided to design a custom control board that will act as an interface between all sensors, the servo, and the hoverboard board.
My Solution¶
I created a custom microcontroller board that connects to:
-
The hoverboard controller (for BLDC motors)
-
The servo motor (for the lid mechanism)
-
All robot sensors
This custom board then communicates with the Jetson Nano using UART, sending sensor data upstream and receiving control commands downstream.
Why This Architecture?¶
-
Jetson Nano handles AI, ROS2, SLAM, perception, and global navigation
-
My custom board handles real-time control, servo PWM, sensor reading, and motor commands
-
Communication between both systems is simple and fast using UART protocol
This architecture makes the robot more reliable, scalable, and much easier to debug.
What is ROS 2?¶
ROS 2 (Robot Operating System 2) is a modern framework for building robots. It allows different parts of a robot (sensors, motors, cameras, etc.) to communicate and work together in real time.
What is SLAM?¶
SLAM (Simultaneous Localization and Mapping) is a technique that enables a robot to create a map of its environment while also locating itself on that map.
I opened KiCad and started creating the board.¶
Here is the schematic of my custom board. When I created this design, I did not face any problems or unclear steps, because I had already fully explained my workflow during Electronics Design Week.
In this board, I use the ESP32-WROOM-32U microcontroller as the main controller. I added a voltage regulator (AMS1117-3.3) to step down the 5V supply from the hoverboard motherboard to a stable 3.3V required by the ESP32. I also included several decoupling capacitors to smooth the power lines and reduce noise.
To monitor the power status, I added a power LED with a current-limiting resistor. For entering flash mode, I included push buttons with 10 kΩ pull-up resistors. I also added a USER button and a USER LED with a resistor for future debugging and testing (for example, simple blink tests).
Finally, I added connectors for UART communication, servo control, and sensor inputs, because my board will interface with the hoverboard motor controller and other modules in my delivery robot.
After completing the schematic, I designed the PCB layout and created a single-layer board. I placed the decoupling capacitors close to each other near the ESP32 to ensure stable power filtering. For all routing, I used 0.4 mm trace width, which provides a good balance between manufacturability and current capacity for this board. The final layout of my single-layer PCB looks like this.
Next, I exported the project as Gerber and DRL files. After generating all the necessary fabrication files, I opened them in Mods and converted the Gerbers into G-code, which I later used for milling the PCB on the CNC machine.How I worked with Mods is already described in the Electronics Production week.
Line traces¶
Outline and drill files¶
After generating the G-code files, I started milling the board on the CNC machine. I first cleaned the machine and fixed the FR-1 material to the worktable using double-sided tape. I began by milling the traces with a 0.2 mm V-bit. After that, I milled the drill file and the outline using a 0.8 mm tool.
Milling line traces¶
Milling drill and outline traces¶
Here is my finished PCB after milling. The traces came out clean, and the outline was cut accurately. This is the final result of the board I designed in KiCad, exported to Gerber/G-code, and milled using the CNC machine.
Soldering and Testing¶
After milling the PCB, I started soldering all the components onto the board. I carefully soldered the ESP32-WROOM-32U module, voltage regulator, capacitors, resistors, LEDs, buttons, and all connectors for UART, sensors, and the servo motor. I used flux to ensure clean joints and checked every connection with a multimeter in continuity mode.
After soldering all the components, I cleaned the PCB using isopropyl alcohol and a toothbrush to remove any remaining flux and dirt. This step helped me get a clean and professional-looking board, and it also allowed me to inspect all solder joints more clearly.
Here is my fully assembled and cleaned PCB. After milling and soldering all components — including the ESP32-WROOM-32U, buttons, LEDs, voltage regulator, and connectors — I cleaned the board with isopropyl alcohol to remove flux residues. The final result looks neat, and the board is ready for testing and integration into my delivery robot system.
I used the Arduino IDE to upload a simple blink program to my board. I connected the onboard LED to GPIO 2, and after uploading the code, the LED successfully started blinking. This confirmed that my PCB, the ESP32 module, and the power circuitry were all working correctly.Everything worked as expected, and the board successfully passed the initial testing.
Output device¶
In this photo, I was soldering and connecting the UART communication wires between my custom board and the hoverboard controller board. This connection allows Jetson Nano (through my ESP32 interface board) to send commands to the BLDC motor drivers on the hoverboard board. I carefully prepared and crimped each connector, checked continuity, and ensured that the TX/RX lines were correctly matched before powering the system.
Next, I mounted the hoverboard controller board and the battery onto the robot platform. The hoverboard board outputs around 15 V, but my custom ESP32 interface board requires 5 V, so I added a DC-DC buck converter to step the voltage down safely. After wiring everything together, I tested the power distribution and confirmed that both the converter and my board were working correctly.
After that, I wrote a simple program to control the robot platform. I created a basic UART communication script that sends commands from my custom ESP32 board to the hoverboard controller. Through this UART protocol, I can send direction and speed signals, allowing the hoverboard board to drive the BLDC motors and move the platform.
#include <Arduino.h>
#define HOVER_BAUD 115200
#define START_FRAME 0xABCD
#define TIME_SEND_MS 100
#define SPEED_MAX 300
#define SPEED_STEP 20
#define HoverSerial Serial
typedef struct attribute((packed)) {
uint16_t start;
int16_t steer;
int16_t speed;
uint16_t checksum;
} SerialCommand;
SerialCommand cmd;
unsigned long nextSend = 0;
int speedVal = 0;
int step = SPEED_STEP;
void setup() {
HoverSerial.begin(HOVER_BAUD);
pinMode(2, OUTPUT);
}
static inline void sendCmd(int16_t steer, int16_t speed) {
cmd.start = START_FRAME;
cmd.steer = steer;
cmd.speed = speed;
cmd.checksum = (uint16_t)(cmd.start ^ cmd.steer ^ cmd.speed);
HoverSerial.write((uint8_t*)&cmd, sizeof(cmd));
}
void loop() {
unsigned long t = millis();
if (t >= nextSend) {
nextSend = t + TIME_SEND_MS;
sendCmd(0, speedVal);
speedVal += step;
if (speedVal >= SPEED_MAX || speedVal <= -SPEED_MAX) step = -step;
}
digitalWrite(2, (t % 1000) < 500);
}
I successfully uploaded the sketch to my board, and everything worked as expected. In the photo, you can see the final result of my work — the platform responds to the UART commands and the motors start moving according to the control signals.
Conclusion¶
This week was a major step forward in the development of my delivery robot. I designed and fabricated my own custom ESP32-based control board, milled it using CNC, soldered all components, and successfully tested its functionality. I established reliable UART communication between my board and the hoverboard motherboard, allowing me to control the BLDC motors directly from my microcontroller. I also mounted the electronics onto the robot platform, added a DC-DC converter to regulate power, and verified stable operation of all modules. Overall, this week helped me integrate electronics design, fabrication, and embedded programming into a working system for my final project.