Robo-Platform: What a Phone-Based Sensor Recorder and Robot Controller Measures

Three parts and two modes

Robo-Platform is described in an arXiv preprint by Masoud Dayani Najafabadi and Khoshnam Shojaei of the Department of Electrical Engineering, Islamic Azad University, Najafabad Branch. It was first submitted on 25 September 2024 and revised to version 3 on 17 July 2025. No conference or journal venue is listed, so it has not been presented here as peer-reviewed work. [1] [2]

[2] [3]

In data acquisition mode, only the phone is needed, plus the board if an external sensor is read. In robot control mode, all three parts are used: commands travel wirelessly from the controller to the phone, and over USB from the phone to the board that drives the motors. The code, schematics and PCB designs are in an MIT-licensed repository that links to a sample dataset. [2] [3]

What it records, and in what form

[2]

Each value is stamped with nanosecond resolution when it becomes available to the app. The paper does not describe hardware synchronization between sensors. Locking focus and exposure keeps the camera model constant through a recording, which visual SLAM relies on; the missing synchronization means time offsets between camera and IMU must be estimated afterwards. The paper itself notes that, unlike MARS Logger, it does not calibrate time offsets offline. [2]

Why timestamps and synchronization decide whether recorded data can be trained on is explained in how robotics teams collect training data.

Measured rates: a fast IMU and a slow camera

[2]

Two figures deserve attention. The IMU period varies by 2 ms around 10 ms, so consecutive samples are not evenly spaced and must be integrated with their own timestamps rather than an assumed 100 Hz. The camera delivers about three images per second. For comparison, the EuRoC drone dataset that the paper also evaluates lists 20 images per second per camera and a 200 Hz IMU. At three images per second, a phone carried at walking pace moves roughly 40 cm between images, which leaves visual tracking little overlap to work with. That distance is our arithmetic at an assumed 1.3 m/s, not a figure from the paper. [2] [4]

How fast each link is

[2]

The Arduino link is close to its ceiling. A serial line at 115,200 bit/s with the usual one start bit and one stop bit per byte carries at most 11,520 bytes per second, about 11.25 KiB/s; the measured 9.9 KiB/s with 1024-byte buffers is about 88 % of that. The framing assumption and the percentage are ours. The V-USB board is fastest at small buffers but grows slowly, and the current implementation cannot handle buffers of 256 bytes or more, so only its 64-byte figure reflects the board as published. [2]

Latency becomes distance once a robot moves. If the reported delay sits between a command and a wheel, a vehicle at 1 m/s covers about 6 mm over the Arduino USB link, 14 mm over Wi-Fi and 87 mm over Bluetooth before the command arrives. Those distances are our arithmetic. For a toy car the Bluetooth figure is tolerable; for anything that must stop near a person it is not, and Robo-Platform makes no safety claim. [2]

What SLAM tools made of the recordings

[2]

Visual-only ORB-SLAM3 tracked between 6 % and 28 % of the indoor sequences and none of the park sequence. Adding the IMU helped where it worked: VINS-Fusion tracked 97 % of the lab sequence and 90 % of the library. The inertial EKF tracked everything, but the authors note that it drifts, because the IMU-only runs had no magnetic or GPS correction. A 100 % tracking time therefore says the filter kept producing an estimate, not that the estimate stayed correct. [2]

The authors attribute the visual failures to low frame rate, fast motion and lighting changes, and their reference sequences from EuRoC and TUM-VI generally scored higher. That matches the rate table above. Anyone recording with this app for visual SLAM should expect to raise the image rate or slow the motion before blaming the algorithm. [2]

The two robot experiments

The toy car uses a Samsung Galaxy J5 attached to an ATmega8 V-USB board. Two digital outputs drive a DC motor through a motor driver, one switching it on or off and the other setting its direction, and commands come wirelessly from the desktop app. The quadcopter uses an Arduino to generate PWM. The phone reads the four current PWM values, the wireless commands and its own IMU to estimate orientation, then computes new PWM outputs. [2]

The paper reports no flight measurements for the quadcopter. An attitude loop that passes through Android scheduling and a USB round trip of several milliseconds is a demanding arrangement, so the experiment shows that the architecture can be wired together, not how well it flies. [2]

A phone that does run a walking robot’s control is examined in what UCLA’s PhoneBot runs on the phone.

What the authors say it does not do

• Android only; no iOS version and no barometer recording.
• In data acquisition mode, the board is read over USB only, and live data is shown only as the camera preview.
• No monitoring in control mode: camera feeds are not sent to the controller, and sensor data is not used for control in server mode.
• Recorded data is uncalibrated and noisy and needs post-processing, such as timestamp alignment and format conversion, before SLAM tools accept it.
• The code is not optimized for performance, and communication logic is not separated from sensor logic.
• V-USB buffers are capped at 64 bytes; encrypted communication is mentioned only as future work.

[2]

When it fits a project

[2]

The useful lesson extends beyond this app: before recording a dataset with any phone logger, measure the actual period and jitter of each stream, as Table IV does, and check that the camera rate suits the motion you intend to record. [2]