2.1. Hardware

The hardware consists of a main board and a driver board, as shown in Figure 3. The main board is primarily responsible for all processing operations related to the robot, while the driver board handles the control and state management of all motors. The components were selected to keep costs as low as possible, while also prioritizing parts that are readily available.

2.1.1. Main board

At the core of the main board is the ESP32 module, as shown in Figure 3, positioned on the top layer. This module features an ESP32-D0WDQ6 microcontroller while also integrating a $4$ MB SPI flash memory. To support image processing, the main board also includes an APS6404L integrated circuit (IC), which provides $64$ Mb of DRAM. The top layer of the board also hosts the speaker and microphone connectors, along with the reset button. On the bottom layer, the camera connector, power input, and board-to-board headers are located. To ensure proper power distribution, both layers include $3.3$ V voltage regulators connected via a $0.1$ $\Omega$ resistor for load balancing. It is worth noting that the ESP32-D0WDQ6 module was chosen for its availability and low cost; however, variations or updated versions of this module can be used with minimal impact on the overall project design.

Figure 3.

Top and bottom views of the main and driver PCB boards.

2.2. Sensors

As shown in the front view in Figure 2, the Jaeger UTFPR uses a camera to capture image data from its surroundings. For this purpose, a 24-pin Flexible Printed Circuit (FPC) connector, located on the bottom layer of the main board shown in Figure 3, is used to interface with an OV2640 camera featuring a $160^\circ$ field of view. This camera is equipped with a sensor array of 1632 columns by 1232 rows, capable of capturing images with resolutions up to 1632 × 1232 pixels. To allow proper positioning within the robot’s frame, the camera’s FPC cable must be at least $10$ cm long. The microphone and speaker are placed as shown in the front view of Figure 2. Directly below the camera, a $9$ mm microphone is installed and connected to the Microphone JST connector located on the top layer of the main board, as shown in Figure 3.

2.3. Actuators

Below the microphone, a $2$ W speaker with a diameter of $2.3$ cm is mounted, with its connector also located on the top layer of the main board, as shown in Figure 3. An LM358 operational amplifier, positioned on the bottom layer of the main board, is used to amplify the microphone’s signal. The speaker is driven via a digital pin using the Remote Control Transceiver (RMT) peripheral of the ESP32, which emulates Pulse Width Modulation (PWM) behavior. The audio signal is generated at a frequency of $8$  kHz with 8-bit resolution per sample. In this setup, each audio sample is mapped to a PWM duty cycle ranging from $0\%$ (0) to $100\%$ (255), where each sample period consists of 255 pulses.

The robot’s motor actuators consist of seven stepper motors with 2210 steps per revolution and two N20 DC motors, with their JST connectors located on both the top and bottom layers of the driver board, as shown in Figure 3. Each arm is equipped with three $5$ V stepper motors, each having a $15$ mm diameter and featuring an embedded $1:110$ reduction gear, enabling movement in three degrees of freedom: vertical (up and down), horizontal (forward and backward), and the opening and closing of the forearm. The positioning of each motor is illustrated in the left, right, and top views in Figure 2. Notably, each arm also includes a motor housed within the robot’s main body.

The use of low-cost N20 DC motors and small stepper motors was a deliberate choice to provide the robot with a good range of motion without a significant cost increase. The N20 motors provide sufficient torque to move the robot on flat surfaces, while the stepper motors offer precise, repeatable movements for the arms. The trade-off is that these motors have limited speed and torque, which means the robot cannot perform tasks requiring rapid, forceful movements or lift heavy objects. Similarly, the ESP32 microcontroller, while being an excellent low-cost solution for Wi-Fi and processing, is not as powerful as more expensive microcontrollers, which limits the achievable video resolution and frame rate. This highlights the core design philosophy of the proposed platform: balancing performance and cost by making conscious trade-offs in component selection to achieve an accessible, functional system.

2.4. Embedded software

2.4.1. Firmware

The robot’s firmware was developed using the Espressif Internet of Things Development Framework, which offers a comprehensive set of tools and libraries to support application development on ESP32-based hardware. The firmware is responsible for real-time tasks such as image acquisition, audio processing, motor control, and wireless communication.

Image data is acquired from the OV2640 camera, with frame rates varying from 15 to 60 fps depending on the selected resolution. Higher resolutions impose a significant processing load on the ESP32 and result in larger image files, which in turn decrease the transmission rate to the VR headset. As shown in Figure 4, multiple ESP32 peripherals are utilized: Inter-Integrated Circuit (I $^{2}$ C) for camera communication, Universal Asynchronous Receiver/Transmitter for programing and debugging, Analog-to-Digital Converter (ADC) for audio sampling, timers for stepper motor control, RMT (Remote Control) for sound playback, and Wi-Fi for wireless data exchange.

Audio sampling is performed at 24 kHz via the ADC. To reduce high-frequency noise, every three samples are averaged to produce an effective 8 kHz signal. The resulting 8-bit samples are stored in a circular buffer and transmitted in chunks of 4000 samples (equivalent to 500 ms of audio) to the VR headset. Sound playback is handled using the RMT peripheral, which is typically employed for protocol timing but is leveraged here for generating precise PWM signals. Unlike timer-based solutions, RMT offers superior timing accuracy with minimal interference from the main application thread. For each 500 ms block of received audio (4000 samples), the RMT generates a PWM signal composed of 256 high and low duty cycle segments to reconstruct the analog waveform.

Motor control is managed via a queue that stores successive target angles received from the VR headset. The system controls seven stepper motors, each updated using one of two hardware timers. Motors are actuated at speeds of up to 800 steps per second. Given a resolution of 2210 steps per revolution, this equates to a maximum angular velocity of approximately $130^\circ$ /s per motor. Importantly, each timer can operate different motors independently. The firmware also handles concurrent transmission of image data over Wi-Fi and the bi-directional streaming of audio data. While images are transmitted as they become available, audio data is sent in fixed-size chunks of 500 ms.

Figure 4.

Peripheral usage.

2.5. Kinematics

To accurately replicate the operator’s arm movements, the robot’s arm utilizes both forward and inverse kinematics. These techniques enable the computation of joint angles for the three actuated degrees of freedom in the arm, either by exhaustively minimizing positional error across all angle combinations or by directly solving the inverse kinematics equations for a given end-effector target. In this work, both approaches are supported; however, due to their computational demands, all calculations are offloaded to the VR headset rather than performed onboard the robot.

The overall kinematics of the robot’s arm are represented by a transformation matrix $\textbf {K}$ , which results from the successive application of rotation and translation matrices. These matrices describe the spatial relationship between the joints and segments of the robot arm in 3D space. Below is a breakdown of each transformation matrix:

1. 1. Rotation Matrix about the $x$ -axis $\textbf {R}_x$ :

   (1) \begin{equation} \textbf {R}_x = \begin{pmatrix} 1 &\quad 0 &\quad 0 &\quad 0 \\ 0 &\quad \cos (\theta _1) &\quad -\sin (\theta _1) &\quad 0 \\ 0 &\quad \sin (\theta _1) &\quad \cos (\theta _1) &\quad 0 \\ 0 &\quad 0 &\quad 0 &\quad 1 \end{pmatrix}. \end{equation}
   Applies a rotation of angle $\theta _1$ around the $x$ -axis, corresponding to the shoulder pitch movement.

2. 2. Rotation Matrix about the $z$ -axis $\textbf {R}_z$ :

   (2) \begin{equation} \textbf {R}_z = \begin{pmatrix} \cos (\theta _2) &\quad -\sin (\theta _2) &\quad 0 &\quad 0 \\ \sin (\theta _2) &\quad \cos (\theta _2) &\quad 0 &\quad 0 \\ 0 &\quad 0 &\quad 1 &\quad 0 \\ 0 &\quad 0 &\quad 0 &\quad 1 \end{pmatrix}. \end{equation}
   Represents a rotation by $\theta _2$ around the $z$ -axis, corresponding to shoulder roll.

3. 3. Translation Matrix along the $y$ -axis $\textbf {T}_{y-\text{arm}}$ :

   (3) \begin{equation} \textbf {T}_{y-\text{arm}} = \begin{pmatrix} 1 &\quad 0 &\quad 0 &\quad 0 \\ 0 &\quad 1 &\quad 0 &\quad -\mathcal{D}_{s-e} \\ 0 &\quad 0 &\quad 1 &\quad 0 \\ 0 &\quad 0 &\quad 0 &\quad 1 \end{pmatrix}. \end{equation}
   Translates the coordinate frame by a distance $\mathcal{D}_{s-e}$ (shoulder to elbow) along the negative $ y$ -axis.

4. 4. Rotation Matrix for the forearm $\textbf {R}_{x-\text{forearm}}$ :

   (4) \begin{equation} \textbf {R}_{x-\text{forearm}} = \begin{pmatrix} 1 &\quad 0 &\quad 0 &\quad 0 \\ 0 &\quad \cos (\theta _3) &\quad -\sin (\theta _3) &\quad 0 \\ 0 &\quad \sin (\theta _3) &\quad \cos (\theta _3) &\quad 0 \\ 0 &\quad 0 &\quad 0 &\quad 1 \end{pmatrix}. \end{equation}
   Rotates the frame by angle $\theta _3$ around the forearm’s $x$ -axis, corresponding to elbow pitch flexion.

5. 5. End-effector Position Vector $\textbf {p}$ :

   (5) \begin{equation} \textbf {p} = \begin{pmatrix} 0 \\ -\mathcal{D}_{e-h} \\ 0 \\ 1 \end{pmatrix}. \end{equation}
   Defines the hand’s position in homogeneous coordinates, where $\mathcal{D}_{e-h}$ is the distance from elbow to hand.

To align with the actual mechanical configuration of the robot, the angles used in the above matrices are adjusted to match the motor rotation directions:

(6) \begin{equation} \theta _{M1} = -\theta _{1}, \quad \theta _{M2} = \theta _{2}, \quad \theta _{M3} = -\theta _{3}. \end{equation}

The final kinematic transformation matrix $\textbf {K}$ is computed as a product of the individual transformations applied to the end-effector vector $\textbf {p}$ , being given by

(7) \begin{equation} \textbf {K} = R_x \cdot R_z \cdot T_{y-\text{arm}} \cdot R_{x-\text{forearm}} \cdot \textbf {p}. \end{equation}

Each matrix multiplication incrementally updates the coordinate frame, accounting for the robot’s joint angles and link lengths. This sequential transformation yields the final position of the end-effector (hand) in the robot’s base reference frame. After computing the full transformation chain, the resulting position vector $\textbf {K}$ can be analytically expressed as:

(8) \begin{equation} \textbf {K} = \begin{bmatrix} \cos (\theta _{M3}) \sin (\theta _{M2}) \mathcal{D}_{e-h} + \sin (\theta _{M2}) \mathcal{D}_{s-e} \\[6pt] (\cos (\theta _{M1}) \cos (\theta _{M2}) \cos (\theta _{M3}) - \sin (\theta _{M1}) \sin (\theta _{M3})) \mathcal{D}_{e-h} - \cos (\theta _{M1}) \cos (\theta _{M2}) \mathcal{D}_{s-e} \\[6pt] \cos (\theta _{M2}) \sin (\theta _{M1}) \mathcal{D}_{s-e} - (-\cos (\theta _{M2}) \cos (\theta _{M3}) \sin (\theta _{M1}) - \cos (\theta _{M1}) \sin (\theta _{M3})) \mathcal{D}_{e-h} \\ 1 \end{bmatrix}. \end{equation}

This vector’s components correspond to the position of the robot’s hand in three-dimensional space: the first element represents the $x$ -axis position ( $x_p$ ), the second the $y$ -axis position ( $y_p$ ), and the third the $z$ -axis position ( $z_p$ ). Therefore, the vector provides a complete mathematical description of the hand’s location based on the motor angles and the lengths of the arm segments, effectively modeling the forward kinematics of the robotic arm.

To aid in visualizing the kinematic behavior, Figure 5 shows a perspective view of a person wearing a VR headset. The figure depicts the global coordinate axes ( $x$ , $y$ , and $z$ ), the hand position components ( $x_p$ , $y_p$ , $z_p$ ), and the joint rotation angles $\theta _{M1}$ , $\theta _{M2}$ , and $\theta _{M3}$ . These joint angles are represented using cylindrical symbols with arrows indicating the positive direction of rotation. Specifically, $\theta _{M1}$ and $\theta _{M2}$ are located at the shoulder and correspond to pitch and roll movements, respectively, while $\theta _{M3}$ represents the elbow pitch. Additionally, the distances from the shoulder to the elbow ( $\mathcal{D}_{s-e}$ ) and from the elbow to the hand ( $\mathcal{D}_{e-h}$ ) are annotated to provide spatial context for the arm’s segment lengths.

Figure 5.

Perspective view of the humanoid’s upper-body kinematics. The diagram shows the global coordinate axes, joint angles ( $\theta _{M1}$ , $\theta _{M2}$ , $\theta _{M3}$ ), segment lengths ( $\mathcal{D}_{s-e}$ , $\mathcal{D}_{e-h}$ ), and hand position components ( $x_p$ , $y_p$ , $z_p$ ) relative to the VR operator.

As for the inverse kinematics, from Eq. 8, assuming normallized equal proportions between the shoulders and elbow, and elbow and hands, such that $\mathcal{D}_{s-e} = \mathcal{D}_{e-h} = 1$ , we have that the estimated motor angles $\theta ^{,}_{M1}$ , $\theta ^{,}_{M2}$ , and $\theta ^{,}_{M3}$ are given by

(9) \begin{align} \theta ^{,}_{M1} &= \frac {180}{\pi } \text{ArcTan} \left [ \frac {-32 c_5 y_p \left ( x_p^2 + y_p^2 + z_p^2 \right ) + \sqrt {-\left ( (c_1 + c_2 - c_4)c_6 \right ) + 1024 c_5^2 \, y_p^2 \left ( x_p^2 + y_p^2 + z_p^2 \right )^2}}{c_6}, \nonumber \right . \\ &\quad \left . -\frac {-c_5 \left ( c_6 - 64 y_p^2 \right ) \left ( x_p^2 + y_p^2 \right ) + c_5 \left ( c_3 - c_6 \right ) z_p^2}{2 z_p c_6} \nonumber \right . \\ &\quad \left . - \frac {y_p \sqrt {-\left ( (c_1 + c_2 - c_4) c_6 \right ) + 1024 c_5^2 y_p^2 \left ( x_p^2 + y_p^2 + z_p^2 \right )^2}}{z_p (c_3 + c_4)} \right ], \end{align}

(10) \begin{align} \theta ^{,}_{M2} &= \frac {180}{\pi } \, \text{ArcTan} \left [ c_5, \frac {2x_p}{x_p^2 + y_p^2 + z_p^2} \right ], \end{align}

(11) \begin{align} \theta ^{,}_{M3} &= \frac {180}{\pi } \text{ ArcTan} \Bigg [ \frac {1}{2} \left ( -2 + x_p^2 + y_p^2 + z_p^2 \right ), \nonumber \\ & \quad \frac {1}{4 (c_3 + c_4) c_6 z_p} \Big \{ \vphantom {\sqrt {-\left ( (c_1 + c_2 - c_4) c_6 \right )}} c_4 c_6 x_p^2 y_p c_5 + 2 c_4 c_5 y_p \left ( y_p^2 + z_p^2 \right ) \left ( c_6 - 64 \left ( x_p^2 + y_p^2 + z_p^2 \right ) \right ) \nonumber \\ & \quad + 4 c_6 \left ( y_p^2 + z_p^2 \right ) \sqrt {-\left ( (c_1 + c_2 - c_4) c_6 \right ) + 1024 c_5^2 y_p^2 \left ( x_p^2 + y_p^2 + z_p^2 \right )^2 } \nonumber \\ & \quad + c_3 \left ( c_6 x_p^2 y_p c_5 + 2 c_5 y_p \left ( y_p^2 + z_p^2 \right ) \left ( c_6 - 64 \left ( x_p^2 + y_p^2 + z_p^2 \right ) \right ) \right ) \Big \} \Bigg ], \end{align}

where $\text{ ArcTan}[x,y]$ denotes the arctangent function taking into account which quadrant the point (x, y) is in, and the intermediate variables $c_1$ through $c_6$ are defined as

(12) \begin{align} c_1 &= 16 \left ( x_p^2 + y_p^2 + z_p^2 \right )^2, \\[-10pt] \nonumber \end{align}

(13) \begin{align} c_2 &= -64 \, x_p^2, \\[-10pt] \nonumber \end{align}

(14) \begin{align} c_3 &= 64 \, y_p^2, \\[-10pt] \nonumber \end{align}

(15) \begin{align} c_4 &= 64 \, z_p^2, \\[-10pt] \nonumber \end{align}

(16) \begin{align} c_5 &= \frac {\sqrt {c_2 + c_1}}{\sqrt {c_1}}, \\[-10pt] \nonumber \end{align}

(17) \begin{align} c_6 &= c_3 + c_4. \\[6pt] \nonumber \end{align}

3.1. Kinematics and inverse kinematics evaluation

In order to validate the correctness of the kinematic and inverse kinematic models, we conducted a numerical evaluation using representative joint configurations. In Table I, we begin by applying the actual motor angles ( $\theta _{M1}$ , $\theta _{M2}$ , and $\theta _{M3}$ ) to Eq. (8) to compute the corresponding positional values $x_p$ , $y_p$ , and $z_p$ . These positional values are then used as input for the inverse kinematics equations Eqs. (9), (10), and (11) to calculate the estimated motor angles ( $\theta _{M1}^{'}$ , $\theta _{M2}^{'}$ , and $\theta _{M3}^{'}$ ). A comparison of the original and computed angles demonstrates that the inverse kinematics equations accurately reproduce the original joint configurations, validating their correctness.

Table I.

Inverse kinematics results for $\theta ^{,}_{M1}$ , $\theta ^{,}_{M2}$ , and $\theta ^{,}_{M3}$ .

Note that both forward and inverse kinematics can be used to estimate the correct joint angles. Forward kinematics achieves this by performing an exhaustive search through possible angle combinations and comparing the resulting end-effector position to the desired coordinates $(x_p, y_p, z_p)$ . In contrast, inverse kinematics directly computes the angles by substituting the desired position into the inverse kinematic equations. Naturally, the inverse kinematics approach is significantly more computationally efficient.

Nevertheless, there are scenarios in which inverse kinematics fails to produce valid angle estimates, for example, when the target position lies beyond the robot’s physical reach, defined by the sum of the shoulder-to-elbow ( $D_{s\text{-}e}$ ) and elbow-to-hand ( $D_{e\text{-}h}$ ) segment lengths. In such cases, the exhaustive search method provided by forward kinematics becomes necessary.

Although both the VR application and firmware are implemented as embedded software, our experiments demonstrated that these kinematic computations are best performed on the VR headset due to its substantially greater processing power. Meanwhile, the ESP32-based firmware handles lower-level tasks such as sensor data acquisition, motor control, and communication, ensuring an efficient division of responsibilities across the system.

Figure 6.

Position error [m] versus miscalibration of $D_{s\text{-}e}$ and $D_{e\text{-}h}$ [m] (0.5 = true value) for various joint angle combinations.

To assess the impact of miscalibrating the segment lengths $D_{s\text{-}e}$ and $D_{e\text{-}h}$ , Figure 6 shows the resulting position errors for several configurations listed in Table I. The analysis assumes the correct reference values to be $D_{s\text{-}e} = D_{e\text{-}h} = 0.5$ m. The plot reveals that multiple joint configurations yield identical error profiles. Specifically, the position errors for points 1, 2, 3, 4, and 7 overlap entirely. For these cases, the error starts at 0.6 m when $D_{s\text{-}e} = D_{e\text{-}h} = 0.2$ , decreases linearly to zero at the correct calibration point ( $D_{s\text{-}e} = D_{e\text{-}h} = 0.5$ ), and then increases linearly back to 0.6 m as the values rise to 0.8.

In contrast, points 5 and 6 exhibit a similar trend but with a reduced maximum error of approximately 0.43 m at both ends of the tested calibration range. This behavior highlights the sensitivity of kinematic calculations to accurate measurements of limb segment lengths. Consequently, precise calibration of the shoulder-to-hand distance is essential to ensure reliable position estimation and overall system accuracy.

3.2. FPS and image quality

The proposed system employs an OV2640 camera module to capture image data. According to the manufacturer’s specifications, the camera supports a maximum resolution of 1600 × 1200 pixels at 15 frames per second (fps). For lower resolutions, it is capable of achieving 30 fps at 800 × 600 and up to 60 fps at 400 × 296 [38]. However, as illustrated in Figure 7, empirical results reveal that actual performance when integrated with the ESP32 microcontroller falls significantly short of these theoretical limits.

Specifically, at a resolution of 400 × 296, the camera achieved a frame rate of 28 fps – approximately 46.7% of the datasheet’s stated maximum. For 800 × 600, we observed a frame rate of 18.3 fps (61% of the theoretical 30 fps), and for 1280 × 1024, 6.45 fps was achieved – just 43% of the expected 15 fps. These discrepancies are primarily attributed to the ESP32’s limited processing power and the communication bottlenecks involved in transmitting image data to the VR headset.

Despite these constraints, empirical testing indicates that a resolution of 800 $\times$ 600 provides the most favorable trade-off between image clarity and frame rate for the intended application. While higher resolutions yield better image quality, they come at the cost of a significantly reduced frame rate, negatively impacting real-time performance and user experience.

Figure 7.

Average frame rate (FPS) for different image resolutions. The solid line represents the measured average FPS across resolutions, while the dashed red line indicates maximum theoretical FPS values for selected resolutions (400 × 296, 800 × 600, 1280 × 1024).

3.3. Sound, data acquisition, and real-time response

The microcontroller is responsible for managing several time-sensitive tasks, including real-time image acquisition and transmission, audio sampling via its ADC, motor control through its timer peripherals, and audio playback using the RMT (Remote Control) peripheral. Experimental results revealed that to minimize high-frequency noise and enhance audio clarity, each sample of the 8 kHz audio signal should be repeated at least three times during playback. Although higher repetition rates were evaluated, they significantly increased the computational load on the already resource-constrained system without yielding perceptible improvements in sound quality. Among the peripherals tested for audio output, the RMT module consistently produced the most reliable and clear results.

Regarding communication and system responsiveness, TCP was found to offer greater reliability compared to UDP. Although UDP offers lower latency, its lack of guaranteed delivery introduced issues such as missed motion commands and intermittent audio dropouts. These problems were particularly noticeable during fast operator inputs and simultaneous audio transmission. Consequently, TCP was adopted for its superior stability in the context of this application.

Finally, while image data is continuously streamed from the Jaeger UTFPR system, experimental evaluation demonstrated that a positional update rate of 6 Hz from the VR headset strikes the optimal balance between responsiveness and system load, leading to a more consistent user experience.

3.4. Key challenges

Designing Jaeger UTFPR under strict cost constraints introduced a series of technical and engineering challenges that required innovative solutions across hardware, firmware, and software layers. Every design decision – from mechanical structure to embedded system architecture – was guided by the goal of achieving functionality, reliability, and interactivity at an exceptionally low price point.

A core challenge lay in selecting components that could collectively deliver real-time control, audiovisual streaming, and responsive actuation with low cost. The ESP32 microcontroller was chosen for its rare balance of affordability, wireless capabilities, and sufficient processing power to simultaneously handle tasks such as image acquisition, stepper motor control, and audio signal processing. However, maximizing the utility of such constrained hardware demanded optimized firmware design, careful peripheral usage, and strict memory and timing management.

Image capture relied on the OV2640 camera module, which supports resolutions up to UXGA while offering low latency at modest frame rates. Transmitting visual data over Wi-Fi in parallel with real-time audio and motor commands introduced substantial synchronization and bandwidth management challenges. Given the ESP32’s limited resources, the firmware was meticulously optimized to prioritize tasks based on timing sensitivity, buffering strategies, and transmission modes.

The actuation system posed its own set of complexities. A hybrid approach using low-cost N20 DC motors and small stepper motors was adopted to deliver adequate degrees of freedom while maintaining positional accuracy. However, controlling nine motors with limited GPIOs necessitated the use of 74HCT259 addressable latches in combination with DRV8833 motor drivers. Implementing this multiplexed control scheme required precise logic sequencing and signal routing to ensure reliable operation without interference – particularly under concurrent Wi-Fi communication and sensor processing.

Audio processing added further constraints. Real-time audio transmission demanded careful tuning of sampling rates, quantization schemes, and buffering techniques. To reduce ESP32 workload while maintaining intelligibility, audio input was sampled at 24 kHz, downsampled to 8 kHz, and compressed into 8-bit values before being transmitted in 500 ms chunks. Playback using the RMT peripheral required creative signal generation techniques to synthesize PWM waveforms with minimal CPU overhead.

On the software side, the VR application was tasked with offloading computationally intensive processes, such as inverse kinematics and hand tracking, from the microcontroller. Ensuring accurate, low-latency coordination between the VR interface and the physical robot required careful calibration and networking strategies, as well as support for both TCP and UDP protocols for balancing reliability and real-time responsiveness.

For the motors, a combination of N20 DC motors and stepper motors was selected to ensure the necessary degrees of freedom and movement precision without incurring unnecessary costs. Similarly, using readily available and low-cost components, such as the DRV8833 motor drivers and LM358 operational amplifiers, ensures that the overall system remains affordable while meeting the required performance specifications. This focus on cost-effective solutions allows the robot to deliver functional capabilities while minimizing the financial burden of production. The total cost of producing a single robot is estimated at below USD 35 [39–41], as summarized in Table II. The detailed electronics bill of materials (BOM), including ”Other ICs and Items,” is available in the full BOM listed in ref. [35].

While the unit cost is low, there are a few important considerations to keep in mind. First, it does not account for shipping costs or taxes. Since many parts need to be sourced from different vendors, shipping costs can easily exceed the price of the individual components. Additionally, although the cost of PCB fabrication is included, producing a single PCB is significantly more expensive than manufacturing multiple units. To mitigate these issues, one should purchase as many components as possible from each supplier. Furthermore, producing more than one unit at a time is considerably more cost-effective than manufacturing a single unit.

For the 3D-printed parts, which are the primary structural components, all necessary models are publicly available in ref. [35] as 16 .stl files, totaling approximately 20 individual parts. The total filament consumption is about 80g. In the project’s experiments, we used PLA filament, but other materials could be used as well. The material cost for a single robot is less than $10. We also recognize that for an individual user, the cost of the 3D printer itself can be a hidden threshold. However, given the open-source nature of the project, users can also choose to have the parts printed by a third-party service, and the full BOM is also available in ref. [35]. Note that the unit cost of ICs and other components could be significantly reduced for mass production [39–41]. It is also worth noting that the maintenance cost of the printer (wear and tear, electricity, etc.) represents a negligible cost of a few cents for this project, making the overall cost of the 3D printed parts highly affordable. Moreover, the open-source nature of the project encourages users to share their own designs and improvements, further reducing the overall cost of the project.

In summary, the development of Jaeger UTFPR demanded far more than assembling inexpensive components – it required creative engineering to overcome the limitations inherent in ultra-low-cost design. The result is a fully functional, immersive telepresence robot system built on embedded hardware that demonstrates how performance and affordability can coexist through thoughtful system integration.

Table II.

Estimated costs, with a total of less than USD 35 [39–41].

3.5. Applicability

As a remote-controlled small robot, the Jaeger UTFPR offers a wide range of applications. In education, it provides an engaging way to introduce fundamental robotics concepts, fostering problem-solving skills and creativity. The robot’s small size is a key advantage for its application in education, making it an ideal tool for teaching fundamental robotics concepts in a hands-on, classroom setting. Its compact design allows for easy storage and deployment, and its open-source nature provides students with a complete platform to learn about hardware design, firmware development, and VR programing. The same characteristics also make it suitable for educational competitions, where navigation in tight spaces is often required. Its low cost makes it accessible to a wide range of educational institutions and students, easing access to robotics education.

With a full arm length of just 7 cm, the robot’s arms are designed for simple tasks, such as interacting with small objects or gesturing, rather than high-precision manipulation. The stepper motors offer sufficient resolution for educational and entertainment applications, such as interacting with small objects or performing simple gestures. However, for applications such as foreign object detection in pipelines, its primary capability comes from the combination of its small size, maneuverability, and video feedback, which allows the operator to perform visual inspections in confined spaces. With further improvements, the robot could serve in exploration roles in difficult-to-reach areas, such as construction, maintenance, and disaster recovery, or be expanded to fields like surveillance and remote monitoring.

The Jaeger UTFPR fills a critical gap when compared to other market solutions. While many miniature remote-controlled robots exist, there are very few affordable VR-controlled platforms. For complex, bipedal robots, prices can range into the thousands of dollars, such as with the Unitree R1 EDU [42]. Even more accessible options, like the InMoov DIY project [43], can have a cost that is at least 10 times higher than the one presented in this work. This platform therefore provides a fully open-source, VR-controlled humanoid at an unprecedentedly low cost, contrasting with commercial solutions that offer superior performance at a significantly higher price and often lack an open-source nature. The primary focus of this platform is on visual inspection and remote presence, rather than on manipulation precision, which would require more expensive actuators and encoders.

3.6. Limitations and future work

We acknowledge that the design of the Jaeger UTFPR under strict cost constraints introduces several limitations that are important to discuss. First, the multiplexing scheme for motor control using 74HCT259 latches and DRV8833 drivers, while cost-effective, can introduce a slight latency in motor response. This is because the controller must address each motor sequentially, which can be a bottleneck in scenarios requiring simultaneous, high-speed movements of multiple stepper motors. Future work could explore the use of dedicated, multi-channel motor driver ICs to reduce this latency and improve the real-time responsiveness of the system.

Second, while the 800 × 600 resolution provides a reasonable trade-off between image quality and frame rate, a frame rate of 18.3 fps and observed latencies of 20–60 ms may not be sufficient for highly dynamic teleoperation tasks, such as navigating an environment with rapid changes in scenery. Optimizing the image compression algorithm on the ESP32 or offloading this task to a more powerful microcontroller could help increase the frame rate and reduce latency without compromising image quality. We also note that the system currently does not have a specific alternative for a complete lack of a Wi-Fi signal, which is a key limitation for teleoperation in unstable network conditions. Alternatives to Wi-Fi may include Narrowband-Ultra-Reliable Low-Latency Communication. It could be an option if more reliability is required in a new version of the robot, but it would increase the costs and complexity of the network infrastructure.

The system’s power consumption varies significantly with its state of operation. The main board, responsible for streaming and processing, consistently draws about 300 mA. However, the total current draw can increase to approximately 900 mA when the robot’s arms and wheels are actively moving, due to the high consumption of the stepper motors (about 500 mA each) and DC motors (about 50 mA each). The two 1300 mAh batteries, connected in series, allow for an average operating time of approximately 1 to 2 hours, taking into account the inherent power loss in the LDO voltage regulators. This endurance can be extended in scenarios with minimal movement. For prolonged use, a larger battery pack or an external power source would be required. This is a crucial limitation for applications such as remote inspection, where extended operation is often necessary. Future work could focus on optimizing power consumption and exploring more efficient battery solutions to increase the robot’s endurance.