ESP32 Robot Update: Web Control, Account Permissions, and Reliable OTA

The robot has moved beyond an Android joystick and camera feed. It now has a computer-hosted account backend, a browser controller, signed vehicle permissions, infrared remotes, voice tools for an air conditioner, and considerably better evidence when an update or crash goes wrong.

The current snapshot is robot firmware 2.4.11, Android 1.4.5, build 13, and ESP-Hosted 3.0.8 on the P4/C6 pair. These are dated project results, rather than a claim that every combination of phone and network has been tested.

Open the web controller · Download Android 1.4.5 · Project and release page

Browser control without changing the robot’s real-time transport

The direct IPv6 UDP channel remains the robot’s motion interface. A browser cannot send those UDP packets, so the new web client talks to the backend over WebSockets. The backend signs control tokens and forwards commands to the robot at 25 Hz.

The controller has dual joysticks, gear selection, an emergency stop, battery and attitude information, video, intercom and infrared controls. Video uses H.264 where the browser supports WebCodecs, with MJPEG as a fallback. The backend shares an upstream video connection between web viewers; the robot’s H.264 server still has a single upstream viewer limit, so an Android video session can compete with the web relay.

The relay treats a missing browser joystick update for about 0.4 seconds as a released stick and stops the drive. The firmware also retains its own command-loss timeout. Neither depends on the user remembering to press a stop button before a tab disappears.

The same page can be added to an iPhone’s Home Screen as a PWA. The layout and browser logic were exercised on a computer, including phone-sized viewports, but that is not a substitute for testing a real iPhone’s decoder, microphone and audio routing.

A separate HTTPS endpoint, with DDNS

The public controller is https://robot.daojianmeng.top:8444/. Both the scheme and port matter: this is an HTTPS listener, not a plain HTTP page.

The backend computer updates the DNSPod AAAA record at startup, checks the local IPv6 address every five minutes, and rechecks the online record every thirty minutes. A Let’s Encrypt certificate is obtained with DNS-01 validation, renewed when thirty days remain, and loaded without restarting the service.

The Android backend continues to use its existing certificate on port 8443 because the app pins that certificate’s public key. Browser control uses its own certificate on 8444. Port 8080 remains a loopback-only administration and local debugging interface; it is not the public controller.

During this handover, the DNSPod API and two public resolvers returned the current backend IPv6 address. The HTTPS listener passed hostname and certificate-chain verification, and the owner subsequently confirmed that the login page opened from an outside network after using the full HTTPS URL. A successful ping alone would not have established that the HTTPS port worked.

Accounts, ownership and signed permissions

The backend now handles login, vehicle binding, ownership, transfers and per-feature permissions. Control, video, intercom, voice assistant, infrared, firmware updates and calibration are distinct permissions.

It issues ECDSA P-256 control tokens with a twelve-hour lifetime. The vehicle checks signatures, vehicle identity, expiry and the requested operation. Policy updates support revocation after permission or account changes. Compatibility mode still exists for older clients; strict mode is a separate vehicle setting and should not be assumed enabled.

The web controller uses the same account model. The Android APK linked here is a direct download from this notes site, so obtaining the installer does not depend on an already-authenticated app session.

A second silent OTA reset, with a different cause

The earlier OTA article describes moving a blocking update out of the main event loop. That was not the end of the story.

After the OLED was working, updates again reset the P4 during flash writing. This project runs code and constants from PSRAM, while the Chinese display font and wake-word resources are still read through flash mappings. Concurrent display reads during erase/write operations were the important difference in this later failure.

Firmware 2.4.6 changed the update sequence: download the complete image into PSRAM first, then perform flash operations in blocks while holding the display lock. The successful follow-up was monitored over serial: a roughly 3.5 MB download took about six seconds, flash writing about thirty-seven seconds, and the new image booted and was marked valid. Further OTA updates also succeeded.

Progress survives in retained RTC memory and appears in telemetry as the last OTA stage. Other flash-writing paths still need the same concurrency discipline; fixing OTA does not prove every future NVS write safe. The useful lesson is to record the reset reason and failed stage, rather than label every silent reset a task-watchdog failure.

Networking and sensors

A separate IPv6 problem came from the C6 hosted firmware and the P4 host library being out of step. Pairing both with ESP-Hosted 3.0.8 restored multicast and neighbor discovery. The recorded post-upgrade test passed twenty-four rounds of multicast and unicast checks over about twelve minutes. It is a bounded stability result, not an indefinite uptime claim.

The current IMU is a GY-85 assembly with an ITG3205, ADXL345 and the QMC5883P magnetometer actually fitted to this module. The driver supports axis mapping and magnetic calibration, but the physical installation still needs the calibration procedure completed. An available yaw value is not evidence of an accurately calibrated compass.

Joysticks, infrared and idle power

The camera pitch stick now commands a rate: release it and the camera holds its current angle. The right stick locks to rotation or pitch until it returns to center. Adjustable response curves make small movements less abrupt, while the left stick keeps its two-axis movement.

Infrared support includes a code library and learned keys. A hardware change from a 220-ohm to a 47-ohm transmitter resistor made the existing air conditioner respond in the recorded physical test. The newer air-conditioning panel and voice tools use full-state Gree/Midea encoders and synchronize one appliance’s state with the robot. The encoding checks passed, but the complete updated voice-to-appliance workflow still needs a physical test.

With no active control or video use, firmware 2.4.11 can stop camera streaming and servo pulses after an idle interval. The voice assistant and Wi-Fi performance policy stay active. Standby/wake behavior was observed; actual battery-current savings have not been measured.

Finally, a retained crash record now carries the task, exception and code addresses into the next heartbeat. The backend resolves those addresses against the matching firmware ELF, which was checked with a deliberate diagnostic crash. Old failures from before the recorder was installed cannot be reconstructed from it.

What remains

The next checks are practical: a real iPhone and Home Screen session, sustained video and intercom on cellular, the updated air-conditioning panel and voice tools against the actual appliance, and final IMU calibration.

The controller and installer links are kept together on the robot project page. The backend computer must remain running for new logins and browser control, and the controller’s current public endpoint requires IPv6 connectivity.