ArduinoTool: Open Hardware Control and Sensing

• ArduinoTool is a design pattern where Arduino boards serve as a core substrate for sensing, actuation, and control, enabling diverse application integrations.
• The systems typically use domain-specific shields, distributed controllers, and protocol-bridging techniques to interface legacy instruments with modern software.
• Research validates ArduinoTool’s low-cost, open-hardware approach, while highlighting challenges in safety, calibration, and reliable real-world deployment.

ArduinoTool denotes, in the literature surveyed here, an Arduino-centered class of tools in which an Arduino board, shield, or Arduino-compatible workflow serves as the primary substrate for sensing, actuation, communication, experimentation, or engineering support. Across the published record, such tools range from an open-hardware smart metering shield and a universal laboratory interface to a robotic observatory dome controller, an assistive head-controlled mouse, a desktop AC susceptometer interface, and later software systems for classification, debugging, personalized circuit construction, and hardware-faithful formal verification (Klemenjak et al., 2014, Gingl et al., 2019, 1804.03232, Dantas et al., 9 Jul 2026).

1. Conceptual scope

A recurring definition of ArduinoTool in the cited work is not a single product category but a design pattern: Arduino is used as a low-cost, open, and modifiable control core around which domain-specific analog front ends, user interfaces, and host-side software are organized. The literature repeatedly emphasizes properties such as low cost, open-source hardware and software, USB programming, and strong community support, and also stresses that Arduino was chosen because it is cheap, widespread, and relatively transparent, with directly accessible microcontroller pins rather than an over-integrated appliance model (Shaikh, 2012, Gingl et al., 2019).

This scope is unusually broad. In some cases Arduino is the only MCU and all intelligence resides in firmware on the board; in others it is an interface concentrator, a USB HID endpoint, a relay driver, or a node in a larger PC-supervised system. A plausible implication is that ArduinoTool functions less as a device taxonomy than as a systems concept: a way of packaging measurement, control, or interaction so that specialized hardware remains accessible through familiar Arduino workflows.

2. Recurring hardware archetypes

The surveyed systems converge on a small number of architectural forms. One form is the domain-specific shield, where Arduino supplies digital control and the shield handles analog conditioning, isolation, or power switching. Another is the distributed controller, where multiple Arduinos divide low-level tasks across physically separated subsystems. A third is the instrument front end, where Arduino mainly bridges legacy equipment or external modules to a contemporary host interface. A fourth is the human-interface appliance, in which Arduino directly mediates between sensors, user inputs, and a host computer (Klemenjak et al., 2014, Kumar et al., 2016, 1804.03232, Gunsha et al., 2024).

System	Arduino integration	Primary function
YoMo	Shield; SPI to ADE7753; relay; CT and isolation amplifier	Smart metering and load switching
EDAQuino	Universal shield; A1–A5 inputs; pins 3–6 for switch control; PGA	Reusable sensor/lab interface
ATVS dome controller	Two Arduino boards with RF link and relay boards	Dome rotation and shutter control
Assistive mouse	Arduino Leonardo with I²C MPU-6050 and pedal inputs	USB HID cursor and click control
MEMSDuino	UNO or Mega with shield, NeoPixels, and relay/HV board	90 V MEMS switch control

YoMo exemplifies the shield model. It is an Arduino-compatible smart metering shield that turns a standard Arduino into a fully functional power meter and remotely controllable smart plug, with a current transformer for non-intrusive current measurement, voltage sensing through a divider plus isolation amplifier, an ADE7753 energy monitor IC, and a mechanical relay that switches both line and neutral for safety (Klemenjak et al., 2014). EDAQuino uses the same stacked-shield idiom, but for pedagogy and general-purpose instrumentation: three universal sensor input ports, software-controlled analogue switches, a programmable gain amplifier, and Arduino analogue inputs A1–A5 plus digital pins 3–6 form a configurable signal-conditioning layer rather than a fixed-purpose sensor board (Gingl et al., 2019).

Distributed control appears in the autonomous telescope dome system, where one Arduino fixed to the dome base handles rotation motors, encoder readings, home sensing, PC/RTS2 communication, and RF communication, while a second, battery-powered Arduino on the rotating dome controls the shutter motor and limit switches (Kumar et al., 2016). MEMSDuino extends the pattern to laboratory high-voltage switching: an Arduino UNO or Mega, a custom shield, NeoPixel indicators, a resistor-ladder button interface, and a relay matrix route a 90 V control signal to cryogenic MEMS switches, with the high-voltage electronics enclosed in a diecast aluminum box (Spietz et al., 6 Jan 2025).

3. Firmware, communication, and host integration

The software organization of ArduinoTool systems is typically split between a simple embedded loop and a richer host-side process. In YoMo, the Arduino is the control and communication brain: it configures and reads the ADE7753 via SPI, controls the relay, handles commands from an external coordinator, and can send measurements via UDP through a Wi-Fi shield to a Raspberry Pi running a Java daemon and web interface (Klemenjak et al., 2014). In the dome controller, logic is explicitly layered: low-level motor drive, encoder counting, home referencing, safety checks, and RF protocol remain on the Arduinos, while the PC/RTS2 side performs high-level observatory logic, target-azimuth computation, scheduling, and error logging (Kumar et al., 2016).

A distinct pattern is the Arduino-as-protocol-bridge model. The desktop AC susceptometer uses an Arduino Uno plus a MAX232 and Bluetooth serial module to connect a laptop to RS-232 instruments such as a function generator and an SR810 lock-in amplifier. The Arduino does not digitize the pickup signal; instead it acts as a UART bridge and command router, forwarding command strings and instrument responses so that a freeware C++ GUI can control the full measurement chain from a laptop (1804.03232). By contrast, the assistive mouse relies on Arduino Leonardo’s native USB HID capability: the board reads head-motion data from a GY-521 MPU-6050 module over I²C, reads two foot-operated pedal switches, and presents itself to the computer as a USB mouse recognized immediately without additional drivers (Gunsha et al., 2024).

Wireless or mobile integration is also common. The spy robo car uses an Arduino Uno, an ESP8266-class Wi-Fi module, a dual H-bridge motor shield, DC motors, and a pan-tilt USB camera; the smartphone connects to the robot’s Wi-Fi network, sends motion and camera commands, and receives live video, while the Arduino interprets commands arriving over serial/UART from the Wi-Fi module (Kamal, 2021). Across these cases, the embedded code remains relatively compact, and complexity is often pushed into a shield IC, a communication module, or host software.

4. Domain-specific realizations

Measurement-oriented ArduinoTool systems commonly embed domain equations either in dedicated hardware or in the surrounding software stack. YoMo is organized around AC power theory with instantaneous power

$p(t)=u(t)\cdot i(t),$

and it reports active, reactive, and apparent power together with RMS voltage, RMS current, and accumulated energy. Its ADE7753 performs the high-frequency ADC sampling and internal signal processing, while Arduino selects the application-level read-out interval (Klemenjak et al., 2014). The AC susceptometer addresses a different measurement domain, the complex susceptibility

$\chi(\omega)=\chi'(\omega)-i\chi''(\omega),$

but again places Arduino in the control path rather than the primary measurement path: the function generator drives the primary coil, the lock-in amplifier reads the pickup coils, and Arduino plus Bluetooth solves the instrument-control and portability problem (1804.03232).

Educational systems use ArduinoTool not merely to automate acquisition but to expose the signal chain itself. EDAQuino explicitly frames experimentation as a progression from physical quantity to sensor, analogue signal, signal conditioning, A/D conversion, integer numbers, software processing, and actuator output. Its examples include thermistors, LDRs, photogates, Hall sensors, accelerometers, photoplethysmography, and environmental monitoring, all through a universal sensor interface rather than a collection of opaque modules (Gingl et al., 2019). A related high-school physics study uses Arduino UNO, BMP180 sensors, LCD displays, potentiometers, and simple experimental setups in thermology and optics to collect temperature-versus-time data and relate graphs to concepts such as heat transfer, thermal equilibrium, and light absorption (Lima et al., 2020).

Human-computer interaction and embodied access form another cluster. The head-controlled mouse maps head movements to cursor motion and foot pedals to left and right clicks, with diagnostic LEDs and an enclosed Leonardo-based controller (Gunsha et al., 2024). The interactive artwork installation at NTNU uses Arduino Nano, IR sensors, RGB LEDs, and speakers to alter light and sound in response to what users place in environmentally friendly or toxic containers, thereby communicating water pollution and recycling through sensor-driven multimodal feedback (Shaikh, 2012).

Robotics and infrastructure further extend the concept. The autonomous observatory dome couples encoder-based azimuth tracking, shutter control, RF communication, and planned weather-sensor integration for autonomous closure (Kumar et al., 2016). The spy robo car integrates locomotion, pan-tilt camera control, Wi-Fi control, and live video monitoring on a compact mobile platform (Kamal, 2021). MEMSDuino, finally, situates ArduinoTool in quantum-information laboratory infrastructure, where an Arduino-based rack instrument manually or programmatically routes high-voltage control signals to cryogenic MEMS RF switches (Spietz et al., 6 Jan 2025).

5. ArduinoTool as an object of analysis, debugging, and verification

A later research strand treats Arduino not only as a controller but also as the target of higher-level engineering assistance. ArduCode is a machine-learning framework trained on 2,927 Arduino projects and 683 PLC projects. It performs code classification, semantic code search, and hardware recommendation, using document embeddings and downstream models to classify Arduino project categories with an F1-score of 72%, to retrieve similar code snippets, and to recommend hardware with autoencoder performance of $p@3 = 0.79$ and $p@5 = 0.95$ at the level-1 hardware taxonomy (Canedo et al., 2019).

Debugging support has also become more specialized. Inline is a VS Code extension plus Node.js server that instruments Arduino sketches automatically, uploads an instrumented build, reads logs over the serial port, and renders hardware logs directly within the code as inline text, glyphs, graphs, histograms, and line highlights. In a twelve-user study it reported SUS $=79.6/100$ and NASA-TLX workload $\approx 28.8/100$, emphasizing code-local visibility rather than a separate serial monitor (Bianchi et al., 4 Mar 2026). WireWay moves further toward hardware-contextualized assistance by combining a Fritzing extension, a BlinkBoard augmented breadboard, and an LLM-based conversational agent. It provides row-level LED guidance and dynamically generated in-situ tests, with a twelve-participant study reporting SUS $70.4 \pm 15.2$, NASA TLX $42.8 \pm 10$, and average chat response time $8.91 \pm 5.13$ s (Lertjaturaphat et al., 5 Mar 2026).

Formal verification brings yet another reinterpretation of ArduinoTool. ESBMC-Arduino instantiates hardware-faithful verification for Arduino-class open-hardware PLCs through a declarative HAL descriptor

$$H=\langle w,\, b_{\mathrm{adc}},\, b_{\mathrm{pwm}},\, \mu \rangle,$$

where word width, ADC resolution, PWM resolution, and I/O binding are derived from official cores. On a corpus of 123 real programs, naïve 16-bit overflow checking without a hardware input model yielded 54 false alarms, whereas the HAL annotator eliminated all 54 while preserving robustness proofs (Dantas et al., 9 Jul 2026). This result is significant because it recasts ArduinoTool from a prototyping convenience into a deployment-constrained verification target whose ADC ranges and ABI-level integer widths materially affect soundness.

6. Validation, limits, and open-hardware significance

The evidentiary quality of ArduinoTool research is heterogeneous. Some systems report concrete operating ranges or accuracy. YoMo is designed for appliance and household loads from a few watts up to about 5 kW, with active-power errors across typical loads in the range of about 0.5%–4% relative to a reference instrument with $\chi(\omega)=\chi'(\omega)-i\chi''(\omega),$0 accuracy, and is characterized as suitable for home energy awareness, research, and non-billing-grade monitoring rather than revenue-grade metering (Klemenjak et al., 2014). The AC susceptometer calibrates against YBCO at 77 K, determines a calibration factor $\chi(\omega)=\chi'(\omega)-i\chi''(\omega),$1, and estimates a susceptibility resolution of approximately $\chi(\omega)=\chi'(\omega)-i\chi''(\omega),$2, while also reporting reliable operation at room temperature and cryogenic temperatures (1804.03232).

Other systems foreground feasibility more than metrology. The assistive mouse reports experimental trials resulting in ideal accuracy and precision and states that the prototype is functional for cursor movement and left- and right-click, but its comparative table also states “Static cursor stability: No” and provides no explicit numeric error or latency metrics (Gunsha et al., 2024). The dome controller emphasizes successful observatory testing, established RF communication, and developed synchronization software, but provides no encoder-resolution or timing metrics (Kumar et al., 2016). EDAQuino notes deployment in 27 high schools and presents numerous experiments, yet explicitly does not provide quantitative evaluation data on learning outcomes (Gingl et al., 2019).

A second persistent limit is that ArduinoTool does not abolish domain-specific engineering obligations. Smart metering still requires galvanic isolation, proper housing, fusing, and calibration (Klemenjak et al., 2014). Educational instrumentation still requires correct signal conditioning and sampling discipline (Gingl et al., 2019). High-voltage switch control still demands shielding, relay protection, and enclosure design (Spietz et al., 6 Jan 2025). Debugging remains difficult because hardware and software faults are intertwined, which is precisely the motivation behind Inline and WireWay (Bianchi et al., 4 Mar 2026, Lertjaturaphat et al., 5 Mar 2026).

The open-hardware and open-software dimension is therefore central rather than incidental. YoMo provides schematics, PCB layout, and BOM, with hardware under CC-BY-4.0 and software under GPLv3 (Klemenjak et al., 2014). EDAQuino distributes hardware, firmware, software, and tutorials through a public repository and tutorial site (Gingl et al., 2019). MEMSDuino releases design files and firmware under Public Domain (Spietz et al., 6 Jan 2025). ArduCode provides a Python reference implementation and proof-of-concept integration into an automation engineering system (Canedo et al., 2019). Taken together, these works show ArduinoTool as an extensible research instrument category: open enough to be modified, but technically demanding enough that safety, calibration, interface design, and deployment realism remain first-order concerns.