RC Car with a Banalytics Agent: A Mobile Edge Robotics Case Study

Treat the vehicle as a complete edge system, not a remote peripheral

The prototype starts with a conventional RC chassis and adds an on-board mini PC, Banalytics Agent, USB camera, LTE modem and Arduino Nano. The operator connects through a browser and uses a standard USB or Bluetooth gamepad. The Agent handles the network-facing work: video acquisition, session coordination, joystick input and local orchestration. The microcontroller translates bounded commands into electrical control of the drive motor, steering servos and lighting.

This split creates a useful mobile-robotics pattern. Linux and Java can manage video, networking, observability and integration without being responsible for pulse-level hardware timing. The Arduino can remain small and deterministic without needing to understand browsers, codecs, authentication or the selected Internet transport. The vehicle continues to be an autonomous edge node even when the operator is remote.

A physical platform, an edge computer and a portable operator station

Keep the human loop, network loop and hardware loop explicit

Operator commands originate as gamepad state in the browser. The remote session carries those inputs to the Agent on the vehicle. The Agent validates and maps them to a small local control contract, and the Arduino applies the corresponding motor, steering and lighting outputs. Video travels in the opposite direction: the camera feeds the Agent, which prepares the live stream and returns it to the operator.

The peer-to-peer claim is about the media and control path between endpoints. Session discovery, identity or connectivity negotiation may still require coordination services. The important operational result is that the maker does not expose an inbound control port on the vehicle, configure router forwarding, or maintain a separate VPN tunnel.

Use the mini PC for rich services and the MCU for bounded execution

A mini PC has enough resources for a JVM, camera capture, video encoding, browser integration, logs and future analytics. It also has an operating system whose scheduling, USB devices and network state can vary. An Arduino is much more limited, but its control loop is easy to understand and can continue applying a defined safe policy when higher-level input stops.

Latency matters, but stale-command behaviour matters more

The prototype reported 50–200 ms between operator input and visible response. That range is plausible for a lightly loaded LTE path, but it will change with radio coverage, congestion, codec buffering, browser scheduling and the distance between peers. A robust controller must therefore be designed around command age rather than assuming a fixed network delay.

1. Sample input intentionally. Transmit gamepad state at a bounded rate and include a monotonic sequence or timestamp.
2. Filter near the operator. Apply axis dead zones and calibration before small joystick noise becomes network traffic or motor movement.
3. Validate on the vehicle. Clamp throttle and steering, reject invalid modes and discard out-of-order or expired commands.
4. Act locally. Send a compact desired state to the Arduino instead of forwarding raw browser events directly to pins.
5. Return evidence. Live video provides human feedback, while telemetry should report link health, last-command age and active safety state.

Treat Internet connectivity as a replaceable transport

The prototype uses LTE because it allows the vehicle to operate beyond a local Wi-Fi network. The Banalytics architecture is not limited to LTE: the Agent needs a suitable IP connection to the Internet, while the controller and actuator contract remain unchanged. This separation lets the same assembly move between local, mobile, private and long-range networks without redesigning the hardware-control layer.

Many of these networks place the robot behind carrier-grade NAT, a firewall or a site router. Traditional inbound TCP control would require infrastructure that is difficult or unsafe to expose. The Agent instead establishes outbound connectivity and participates in the remote session, allowing the browser and vehicle to negotiate a usable path without opening the robot to unsolicited Internet traffic.

P2P does not remove the need for security engineering. The operator and Agent still need authenticated identities, encrypted transport, scoped access and revocation. The Agent should expose only the required camera and control capabilities to the session, and logs should distinguish connection, authorization, input and actuator events.

Transport selection must be based on measured worst-case behaviour, not advertised peak bandwidth. Test round-trip time, jitter, packet loss, handover interruption, coverage boundaries and recovery after a complete outage while the vehicle is stationary. Changing from LTE to Wi-Fi, 5G, mesh or satellite must never change the safe-stop requirement: excessive command age or loss of the control session must still remove propulsion authority at both the Agent-rule and controller-firmware levels.

The assembled vehicle closes the browser-to-hardware loop

The short demonstration shows the completed mobile platform and its remote-control concept.

Build from verified local control toward remote operation

A remotely controlled platform can create real kinetic, electrical and fire hazards. An unexpected command, delayed video, software failure, broken wire or damaged enclosure can cause property damage or physical injury. The build process must therefore treat controlled failure, mechanical protection and repeatable testing as product requirements rather than improvements to add after the vehicle starts moving.

1. Select a suitable chassis. Choose a platform with enough payload capacity, internal volume and mounting area for the required components without obstructing steering, suspension, cooling or service access. Account for the final centre of gravity and the effect of added mass on braking and stability.
2. Select the control and measurement hardware. Define the low-level controller, companion computer and communication equipment, then add the sensors needed to understand the platform's state. Depending on the application, these may include a camera, GPS receiver, current and voltage sensors, inertial sensors, temperature monitoring, proximity sensors or wheel feedback.
3. Develop the firmware and configure Banalytics Agent. Implement bounded actuator commands, neutral states and an independent communication watchdog in the controller firmware. Install the edge Agent, configure video and device integration, and create rules for command-age validation, connection loss, safe stop and explicit re-arming.
4. Design the enclosure and mounting system. Provide secure locations for every component, battery, converter, cable and antenna. Protect electronics from impact, moving parts, heat and moisture while preserving cooling, radio performance, camera visibility and maintenance access.
5. Assemble and inspect the complete platform. Route and strain-relieve wiring, isolate motor noise from compute power where possible, protect conductors from sharp edges and suspension travel, and include a reachable physical master disconnect. Verify polarity, current limits, fasteners and mechanical clearances before applying propulsion power.
6. Test only under controlled conditions. Begin with the wheels lifted or propulsion mechanically isolated, then move to an enclosed test area with barriers, a physical observer and a clear emergency-stop procedure. Avoid public spaces whenever possible. If an authorised test must take place in a public area, limit maximum speed and acceleration, maintain a safe exclusion zone, and prove beforehand that excessive latency, software failure or loss of communication produces a fail-safe stop at both the Agent-rule and controller-firmware levels.
7. Perform separate mechanical and environmental validation. Test enclosure impact and controlled breakage, fastener loosening, cable and connector fatigue under vibration, electrical disconnection, thermal load and the required level of water and dust protection. Repeat the safe-stop tests after this stress testing: damage must not create uncontrolled motion, expose hazardous conductors or disable the physical power disconnect.

Remote authority must expire automatically

Hobby models need the same principle in a simpler but still independent form: a lost connection or control latency above the configured limit must trigger a fail-safe stop of the vehicle. This protection must exist at both layers. The Agent assembly should contain rules that monitor session state and command age, force throttle to zero when either becomes unsafe, and block further motion until the operator explicitly re-arms the vehicle. Separately, the controller firmware must implement its own watchdog that returns motor output to neutral when valid commands or heartbeats stop arriving. The firmware safeguard must work even if the Agent process, operating system or communication link fails completely.

Full-scale robots need more than a remote-control link. They should include an autopilot or another independent safety-control system capable of maintaining a safe operating envelope when an operator command is delayed, invalid or unavailable. Depending on the platform, that system may enforce speed and geofence limits, detect obstacles, preserve stability, execute a controlled stop, move to a predefined safe location or hand authority to a verified local controller during a critical situation.

Any robot intended to operate where people or infrastructure are present requires comprehensive validation of the complete system, including its autopilot, sensors, communications, actuators, power system, degraded modes and emergency procedures. Before operational deployment, the platform and its safety functions must pass the government certification and regulatory approval applicable to its vehicle class, operating environment and jurisdiction. A successful prototype test or reliable remote connection is not evidence that the robot is safe for public, commercial or infrastructure use.

The prototype is a maker platform and educational demonstrator. It is not a road vehicle, autonomous driving system or safety-rated controller. Operate it only in a controlled space, within radio and visual constraints, and never around people, animals or property that could be harmed by unexpected motion.

The enclosure turns the electronics into a serviceable mobile node

The finished body protects the compute and power stack while leaving the USB camera and LTE antenna exposed. Hinged sections provide access to the interior. This is more than cosmetic: a useful mobile edge enclosure must control cable movement, airflow, service access, radio placement and impact risk.

The reusable product is the boundary between remote intent and local action

The RC car is a compact demonstration, but the same architecture applies to inspection crawlers, camera dollies, educational robots, pan-tilt rigs and mobile lab equipment. The browser should express operator intent. The Agent should own connectivity, media, orchestration and policy. The local controller should own the final safe relationship between commands and hardware.

This separation also makes the platform extensible. A second camera, environmental sensor, GPS receiver, MQTT telemetry path or local computer-vision task can be added to the Agent without rewriting the Arduino control loop. Conversely, the chassis or motor controller can change without changing how the operator opens a browser session.

Commission one boundary at a time

1. Configure a USB camera on the mini PC and verify a stable local view.
2. Use the Gamepad State Controller to inspect axes, buttons, dead zones and inversion without connecting propulsion.
3. Define a small Agent-to-Arduino contract: desired steering, desired throttle, lighting state, sequence and validity timeout.
4. Verify local actions with the vehicle lifted, then deliberately stop the Agent and unplug the control link to confirm the Arduino returns to neutral.
5. Configure the Agent Connector and Portal WebRTC Integration for the remote session.
6. Test LTE access with propulsion inhibited. Measure command and video age under good and poor coverage.
7. Enable a low speed limit, require explicit arming and conduct remote tests in a controlled area with a physical observer.

For a first build, replace the drive motor with an LED or keep the chassis on a stand until every disconnect path is understood. The goal is not merely to make remote control work; it is to know exactly what the platform will do when any part stops working.