On Phones as Edge Computer Replacements

Why the standard “edge PC + cameras + sensors + GPIO-driven actuators” robotics stack is an artifact of when it was designed, and what a phone-centric architecture — a modern smartphone or tablet paired with a small MCU — replaces it with.

What This Article Covers

· Why the traditional edge-PC robotics stack is a 2010s pattern.

· Peer-reviewed evidence that phone-based VIO beats RealSense, Zed, and embedded-SBC SLAM.

· A real-world result on a six-year-old iPhone 11 Pro Max.

· How phone-class compute density and vertical integration beat the traditional stack.

· The proposed architecture: phone for perception + ML + planning; MCU for low-level motor control; wireless between.

· The on-device ML that ships free with modern phones.

· The reasons it hasn’t taken over yet.

· Why the supply-chain outlook makes the traditional architecture worse.

· What the architecture enables at the limit — drones, BYO-phone robots, Apple-Silicon-integrated robots.

I’ve been building autonomous behaviors into an RC car for a while now, and every iteration of my stack has looked roughly the same as the stack you’ll find on almost any small-to-medium robot built today: a sensor suite at the front — cameras, IMU, lidar, GPS, whatever the use case calls for — an edge computer in the middle running perception, planning, and (through its own GPIO header) the low-level control signals out to the actuators. It’s the canonical robotics architecture — a pattern that the modern robotics community settled on in the early 2010s and has been refining ever since.

The problem is that this pattern was designed for a world that no longer exists. When ROS and ROS 2 took shape, phones were not a credible compute platform for anything that mattered. Their cameras were noisy, their SoCs throttled aggressively, and there was no realistic way to get raw sensor streams out of them. So the entire mapping / SLAM / perception ecosystem — Intel RealSense, Stereolabs Zed, Luxonis OAK-D, NVIDIA Jetson, Raspberry Pi — grew up around dedicated hardware.

Strip a robot down to its essentials, though, and there are only three jobs to do: perception (sense the world), planning (decide what to do), and control (actually move the actuators). That’s it. The traditional architecture mixes all three onto a Linux SBC with separately-sourced sensors bolted on. But in the meantime modern phone SoCs — Apple Silicon, Qualcomm Snapdragon, Google Tensor — got absurdly good, and almost nobody in robotics noticed that a modern phone, with no modification, now does the perception and planning sides of that triplet extraordinarily well. Both are exactly the kind of compute the consumer phone industry has spent years optimizing for.

The thing that pushed me to write this was a series of concrete results on my own hardware. I took an iPhone 11 Pro Max — a six-year-old phone — and used the RTAB-Map iOS app to walk the entire perimeter of an apartment complex in one pass. The iPhone produced a drift-corrected odometry trajectory of the loop and a sparse 3D point cloud of the visual features it tracked along the way — all in real time, with no external sensors and no tuning. Visual SLAM at that scale and accuracy, running in real time, is a genuinely demanding workload — and there is nothing in the traditional architecture at the same price point — and I mean nothing — that can do it out of the box; not a Pi 5 with a stereo USB camera, not a Jetson Orin Nano with a RealSense, not anything else in this budget range.

[embed]

And here’s what makes the result especially striking: the iPhone 11 Pro Max has no direct way to perceive depth. There is no LiDAR — that scanner only arrived on the iPhone 12 Pro and later Pro models. And even though the phone’s three-camera array could in principle be used as a stereo rig, ARKit does not use it that way: ARKit runs monocular visual-inertial odometry — a single camera plus the IMU — because it has to work on every iPhone Apple ships, including the ones with only one rear camera. Monocular VIO is the category of SLAM that classically suffers the worst scale ambiguity and drift; it is supposed to be the hard mode. The iPhone is producing a scale-consistent, drift-corrected trajectory plus a sparse 3D point cloud in monocular mode, on a six-year-old chip — while the canonical hardware that the same workload supposedly needs is a dedicated camera module (RealSense, Zed, OAK-D, or similar, $300–$500) paired with an edge computer (a Pi, Jetson, or x86 box, $500+) running an open-source VIO stack in real time. Two boxes, four-figure totals, and worse trajectory accuracy than a single phone.

Below I’ll walk through the two architectures side by side, lay out where the traditional stack hurts in practice, and then turn to why the better architecture hasn’t taken over yet.

The Traditional Architecture

This is the shape that almost every hobby robot, every educational platform, and a lot of small commercial robots take today.

Figure 1 — Traditional robotics architecture. A use-case-specific sensor suite (cameras, IMU, GPS, lidar, rangefinders, encoders — whichever the application requires) feeds an edge PC that runs perception and planning, and drives the actuators directly through its own GPIO header (PWM, SPI, I²C). Each sensor sits on its own bus; nothing is hardware-synchronized below the user-space layer.

The two subsystems:

· Sensor suite — whatever combination of cameras (RGB, stereo, depth), IMU, GPS, lidar, rangefinders, encoders, and other breakouts the application requires. Each typically connects over its own bus (USB, MIPI, I²C, SPI, UART) and is sampled in user-space on the edge PC.

· Edge PC — a single-board computer (Raspberry Pi, Jetson, BeagleBone) or a small x86 box. Runs Linux, ROS / ROS 2, the perception + planning stack, and — through its 40-pin GPIO header — generates the PWM / SPI / I²C signals that drive the motor controllers and servos directly. No separate MCU in the minimal canonical setup.

Why this looks reasonable on paper

It’s the modular setup everyone teaches: separation of concerns between perception, planning, and real-time control. ROS 2 nodes are easy to wire up. There’s a giant ecosystem of packages — ORB-SLAM3, VINS-Fusion, RTAB-Map, Nav2 — all assuming exactly this Linux SBC shape.

Why it’s frustrating in practice

Four things hurt every time I sit down to use it.

1. Mixing sensors from different vendors means giving up on hardware synchronization. The moment you pick a camera from one supplier, a lidar from another, and a GPS from a third — which is what almost every real-world robot stack ends up doing, because no single vendor sells exactly the combination of sensors any given application needs — you have given up on a shared hardware clock between them. Each sensor arrives over its own bus on its own clock, each vendor’s driver hands you timestamps in its own frame of reference, and the reconciliation happens in user-space on the edge PC. The jitter that introduces is on the order of 5–20 ms before you have even started filtering. That jitter is the single largest error source for visual-inertial odometry on this kind of stack, and it is structural — you cannot software your way out of it.

2. And even when you stay inside a single vendor’s hardware-synced module, the sync is still worse than what phones already do — and the phone outperforms the dedicated hardware directly. The Intel RealSense D435i is widely considered the standard, but its hardware sync between IMU and image is roughly 2.5 ms, on a module that costs over $400. The Zed and the OAK-D have variants of the same number. Apple, meanwhile, hardware-syncs the cameras and the IMU at the silicon level — well under a millisecond, easily an order of magnitude tighter than the RealSense’s 2.5 ms — and that tighter sync is a direct reason ARKit’s tracking accuracy is what it is. They do it because they need it for ARKit, and they ship it for free inside a phone you may already own. The same pattern holds across the phone industry — hardware-synced cameras and IMU are table stakes on every modern flagship, because every phone maker needs them for AR.

Three peer-reviewed studies make the gap concrete. The first (Kim et al., Sensors, 2022) benchmarked an iPhone and an Android phone against two of the most popular dedicated robotics cameras on visual odometry across six real-world routes, ending with a 3 km drive through a city. On that hardest test, the Intel RealSense T265 gave up entirely; the Stereolabs ZED 2 ended up 409 m away from where it actually was. The iPhone was off by 2.68 m — better by two to three orders of magnitude, at roughly the same retail price.

A second study (Marino et al., Sensors, 2022) broadened the comparison across eight phones and tablets at different price points, and confirmed that even cheaper phones beat the dedicated camera modules — with the LiDAR-equipped iPad Pro posting the best accuracy of any device tested. A third (Delmerico and Scaramuzza, ICRA, 2018) showed that the open-source tracking software the small-computer ecosystem depends on can’t actually run well on those small computers: most of the leading algorithms either failed outright or had to be slowed down so much they lost accuracy.

The takeaway across all three papers is the same: at the same price, phones beat the dedicated cameras, and the standard open-source software can’t fully run on the small computers it was meant for. The traditional setup is the bottleneck — and modern phones already sit comfortably outside it.

3. The bill of materials looks small per part and large in aggregate, and the supply outlook is getting worse. Edge PC, the sensor modules the use case requires (cameras, IMU, GPS, lidar, encoders, etc.), motor drivers, SSD, cooler, case, cables — the total tends to land somewhere between $1,000 and $1,500 for anything you’d want to put a real perception workload on. And every component sits inside the global semiconductor supply chain, which has been unstable for years. There’s no on-board storage that comes with the SoC for free, and no built-in connectivity beyond Wi-Fi / Bluetooth. Each of those is a separate decision and a separate purchase.

The strategic outlook makes this materially worse. NVIDIA is increasingly focused on enterprise data-center GPUs and AI accelerators — that’s where the margins are, that’s where the order volumes are, and that’s where the corporate strategy now lives. Consumer GPUs and edge-compute kits like the Jetson Nano line are visibly less of a priority every year. Smaller players — Raspberry Pi, BeagleBone, the educational-tier SBC vendors — are not going to escape the upcoming wave of AI-driven memory and storage bottlenecks; they are going to be the ones who lose the price war for DRAM and NAND when hyperscalers absorb the supply. The hardware you build a robot stack on today may not be the same hardware you can buy at the same price next year. Meanwhile, the phone supply chain — Apple, Samsung, Google, Xiaomi, and the rest of the pack — is the most resilient and best-priced one in consumer electronics.

4. The software environment on edge SBCs is fragile in a way modern phone stacks are not. Start integrating a few sensors on an SBC and you quickly discover the real workload isn’t the robot algorithm at all — it is reconciling ROS versions against Ubuntu versions against the specific sensor drivers each vendor ships, each one pinned to a different base image or kernel. The actual day-to-day work becomes editing CMakeLists files, chasing dependency conflicts, and rebuilding workspaces, not writing the perception or planning code you sat down to write. And the moment you try to escape that mess by upgrading the system — run sudo apt update && sudo apt upgrade on a Jetson and there is a non-trivial chance you have just broken your CUDA / cuDNN / TensorRT stack — JetPack’s dependency tree is notoriously brittle, the L4T base layer pins binary versions that Ubuntu’s package manager doesn’t know about, and any meaningful upgrade can cascade into hours of dpkg debugging. Pi OS isn’t quite as bad, but the same risk shows up the moment you mix vendor binary blobs (camera drivers, NN runtimes, hardware-acceleration libraries) with apt-managed packages. The contrast with the modern phone stack is the entire pitch of vertical integration: one company owns the SoC, the OS, the driver layer, the AR/ML frameworks, and the GPU API. iOS updates don’t break ARKit. Android updates don’t break ARCore. The phone industry — Apple, Google, Samsung, Qualcomm, all of them — has done the integration work that the robotics-SBC ecosystem has been quietly outsourcing to its users for years.

There’s also a fifth, less obvious cost: size and weight. You cannot fit this architecture on a small drone. Whole classes of small mobile robots are simply ruled out by the geometry of this stack.

The Phone-Centric Architecture

Here’s the architecture I’m proposing instead.

Figure 2 — The phone-centric architecture. A modern phone is the entire compute and sensor suite — cameras hardware-synced to the IMU at the silicon level, GPU on-die, GNSS and radios included. A small wireless MCU bridge handles only the deterministic GPIO and motor control that the phone OS is not allowed to do; the MCU in turn drives a motor controller for the actuators.

Two parts. The phone (an iPhone or iPad in my build, but any modern flagship phone or tablet of the same generation works the same way) is the entire compute + sensor suite. A small MCU hangs off it — over BLE or Wi-Fi — and handles the real-time GPIO that the phone OS is physically incapable of exposing to a third-party app. That’s it.

What a modern phone gives you for free

This is the part that, the more I list it out, the harder it gets to argue with. Every modern flagship phone — iPhone or Android — ships some version of this list, with only minor variation between vendors. A recent flagship typically includes:

· Two or three hardware-synchronized cameras already locked to the IMU clock at the silicon level. The same cameras can also be used together as a stereo pair to give the phone direct depth perception.

· A 6-axis IMU plus magnetometer plus barometer built in.

· GNSS (multi-band L1 + L5 on recent flagships).

· A LiDAR scanner on every Pro iPhone since the iPhone 12 Pro, exposed directly through ARKit; several Android flagships (e.g., Samsung’s Ultra line in earlier generations, current Honor and Huawei Pro models) ship comparable time-of-flight depth sensors as well.

· A capable GPU and a multi-core CPU. Modern phone SoCs — Apple Silicon, Qualcomm Snapdragon, Google Tensor — are designed to run AAA-class games at sustained frame rates for hours. They are categorically capable of the same workload running as a robotics perception loop.

· Wi-Fi 6, Bluetooth 5+, LTE / 5G, and UWB. Everything you need to talk to the robot, the cloud, and yourself — included.

· 256 GB to 1 TB of NAND storage built in on modern flagships (iPhone and Android Pro tiers all sit in this range). No add-on storage, no separate purchase.

· A thermal envelope tuned for sustained gaming. Modern flagship phone SoCs are designed to take heavy GPU load for extended periods without thermal throttling, in a chassis the size of a deck of cards. Most edge SBCs throttle in minutes under the same load — which directly caps how long their perception stack can stay at its peak compute rate.

A natural follow-up objection at this point is: but phone cameras are rolling-shutter, and rolling shutter is genuinely bad for high-motion robotics work. That’s true — a $400 global-shutter machine-vision camera with a hardware-synced exposure is, in pure sensor terms, a better front end. For the phone’s own built-in AR pipeline this isn’t actually an issue, because the platform has already solved it — on the iPhone, for example, ARKit’s tracker models the rolling shutter and produces the corrected pose stream that the rest of the system consumes (ARCore does the equivalent on Android). The point at which it matters is the moment you step outside the platform’s AR framework — a custom SLAM implementation, a high-rate optical-flow loop, a learned-feature tracker, anything where you want raw frames. The answer there is to do the rolling-shutter correction yourself in software: model the per-scanline exposure timing (parameters you can recover with a one-time camera-IMU calibration in Kalibr) and warp the image back into a global-shutter equivalent on every frame. It’s a known, well-understood algorithm; what it costs is compute. The Pi 5 doesn’t have enough compute to run it in real time alongside SLAM. Modern flagship phone SoCs do, comfortably, on the GPU. This is exactly the kind of tradeoff the architecture makes constantly: use compute density to cancel out cheaper sensor hardware, instead of paying $400 for the sensor in the first place.

And then the supply chain dimension: the phone industry’s procurement and manufacturing arms — Apple, Samsung, Google, Xiaomi, and the rest of the pack — are categorically better than anything a smaller SBC company can match. The cost per unit of compute, sensor, and connectivity inside a modern phone is the lowest in the world, by a wide margin, and the prices keep falling. A used flagship phone two or three generations old already outperforms most current robotics-dedicated edge hardware at a fraction of the price.

And the phone’s capabilities are not limited to VIO. The same hardware that runs ARKit (or ARCore on the Android side) also runs dense depth fusion, 3D scene reconstruction, room-scale photogrammetry, real-time semantic segmentation, on-device LLMs, and — increasingly — survey-grade dimensional measurement.

The most striking recent demonstration is this video comparing the iPhone 17 Pro against a professional total station — the laser-and-theodolite instrument surveyors have used for decades, typically $20,000–$60,000. Paired with an external RTK GNSS receiver that streams centimeter-accurate position over Bluetooth, the iPhone produces measurements within a small fraction of the total station’s precision, in a fraction of the setup time, with the result already in a 3D mesh. A consumer phone and an RTK dongle.

That pairing maps directly onto the architecture this article is proposing: the RTK module hangs off the MCU and forwards its centimeter-accurate fix to the phone, which fuses it with the on-device AR mesh in real time. The whole stack — phone plus RTK module — lands around $4,000, against a total station at $40,000–$60,000. Roughly two orders of magnitude, on the same chip already running the robot’s perception, planning, and on-device ML. It is not an add-on, not a separate product you have to buy — it is a feature the consumer-electronics industry already paid for.

What modern phones already ship as ready-to-use ML models

And the on-device toolkit doesn’t stop at VIO. Free with the OS, modern phones ship ready-to-use APIs for full-body skeletal pose, 2D and 3D hand pose, world-frame 3D body tracking, scene-mesh semantic segmentation, instance segmentation, dense optical flow, animal pose, face landmarks and blendshape face tracking, ball-and-projectile trajectory tracking, text and barcode recognition, sound classification across hundreds of built-in classes, on-device speech recognition, and on-device LLMs — all running on the GPU, all callable from two or three lines of code. On the iPhone these are exposed through the Vision, ARKit, Sound Analysis, Speech, and Core ML frameworks; on Android the equivalents are ML Kit, ARCore, MediaPipe, and TensorFlow Lite. Every one of those capabilities is a multi-week project on the traditional Linux-SBC stack — choose a model, convert it to TensorRT, profile the throughput, write the ROS wrapper. On a phone each one is a single API call. Multiply that gap across the list and the architecture comparison gets lopsided in a way the hardware-only comparison only hints at.

What the phone cannot do

There’s exactly one thing a phone can’t do, and it’s the one thing a microcontroller is built for: deterministic, sub-millisecond GPIO. A phone has no exposed pins. iOS (and Android, for the same security and power-management reasons) won’t let an app run a tight ISR loop. You cannot bit-bang a motor encoder from a phone app.

So a small MCU — an ESP32, an RP2040, an STM32 — sits next to the motor driver, handles the low-level motor control, and exposes itself to the phone over BLE or Wi-Fi. The phone sends high-level commands (“drive at 1.2 m/s, turn 15°”) at the rate of perception, and the MCU takes care of everything below that. The traditional Pi-based stack didn’t need this split because the Pi’s own 40-pin GPIO header can drive motors directly; a phone doesn’t have a 40-pin header, so the MCU plays the role those pins played on the Pi. That’s the only reason it’s there.

The Real Reasons This Architecture Hasn’t Taken Over

If a phone is so obviously better, why is essentially every hobby robot and every educational robotics platform still shaped like the traditional stack? I’ve been chewing on this and I think there are three reasons, in roughly ascending order of how solvable they are.

1. The software ecosystem grew up elsewhere

This is the real obstacle, and it isn’t an accident. For years, almost every paper, almost every open-source SLAM repository, and almost every reference implementation in robotics has been written for NVIDIA CUDA on x86 or for ARM Linux single-board computers like the Raspberry Pi and the Jetson — because NVIDIA, Intel, and the other dedicated-hardware vendors fund a large fraction of the academic robotics and computer-vision community, and funded groups target the funder’s hardware. When those graduates leave academia for industry, they take their toolchains with them, and the whole field converges on the same handful of stacks.

The result is that almost nothing of consequence is optimized for the iOS or Android ML backends, even though those backends are perfectly capable of running the same workloads on phone-class silicon. The hardware was ready a long time ago; the software ecosystem wasn’t. It’s the same dynamic that kept the Mac out of the AI/ML conversation for a decade — until Apple Silicon made it impossible to ignore. The Mac Mini’s local-LLM moment is the template for what happens to robotics when phones and tablets get the same treatment.

2. Mobile development, the dissolving barrier

The most common objection here is that most robotics teams aren’t used to iOS or Android development, and the Swift / Kotlin learning curve is enough to keep them on the familiar ROS-and-Python stack (and as a side note, Embedded Swift now exists, so if you already know Swift you can write the full robotics algorithm on the phone and the real-time code on the MCU in the same language). The objection is fair — but it is collapsing on three fronts at once.

First, the tooling itself has become genuinely approachable: Apple’s built-in vision, AR, and machine-learning toolkits expose state-of-the-art capabilities in two or three lines of Swift, with no CUDA versions to pin and no JetPack to reflash. Second, the development hardware itself is no longer a barrier — a Mac Mini M4 starts at $599 new, cheaper than a mid-range Jetson developer kit, and used M-series Macs run $300–$600. Third, LLM-assisted development has erased most of what was left — Claude, Cursor, ChatGPT, and Copilot can scaffold a working iPhone or Android robot app in a single sitting, with the developer reviewing rather than writing from scratch. The “we don’t do Swift” objection presumes a world where every developer learns each new stack the hard way, and the trend is pointing the opposite way.

3. Privacy is an underrated advantage

Most home robots with cameras today either upload frames to a vendor cloud or do their inference on a low-end on-device chip and still phone home for the “smart” features. Running the entire perception pipeline on the user’s own personal phone — a device they already trust with their entire life, and one whose privacy posture (iOS or Android) is materially more consumer-aligned than any robot vendor’s cloud — is the obvious answer, and nobody is shipping it.

What This Buys You at the Limit

Three cases where the phone-centric architecture isn’t just cheaper but enables things the traditional architecture can’t. The first is about carrying a phone on a class of robot the traditional stack physically can’t fit on. The second is about attaching a phone the user already owns. And the third — the most important — is about treating phone-class silicon as the right SoM (system-on-module) for every robot, including ones the user never sees a phone in.

Small drones. A sub-250 g drone — the DJI Mini class — cannot carry a Jetson + RealSense at all; with carrier board, battery, cables, and mounts the stack pushes well past that limit. Even a 500 g–1 kg airframe carries it barely, at real cost to flight time and agility, which is why most onboard-SLAM research drones still sit in the 1–2 kg class. A modern phone with hardware-synced VIO and phone-class compute, at 150–230 g, is on the table for the first time at the sub-500 g scale.

Personal robots that borrow the user’s phone. Imagine the boxing-trainer robot at home, or the kitchen-helper robot. Imagine the price point of each of those if the perception and AI are factored out of the BoM because the customer brings their own phone. The customer’s phone (an iPhone, in the Apple-centric version of this story) slots into a dock on the robot when they want to use it and pops out when they don’t. The robot itself ships with motors, an MCU, a frame, and a battery — nothing else.

Dedicated robots that integrate phone-class silicon directly. This is the case I want to make harder than I usually see it made. Even when you are building a robot that ships as a standalone product — no customer phone involved, ever — it is still better to take a phone SoC (Apple’s A-series or M-series, Qualcomm’s Snapdragon, Google Tensor) along with its native cameras, IMU, and radios, and integrate them as the compute core of your robot than it is to build the traditional edge-PC + dedicated-cameras + IMU-breakout stack from discrete parts. The phone industry has spent years and trillions of dollars optimizing exactly this collection of silicon for compute density, sensor sync, and cost. The reason a phone is the best edge computer for robotics isn’t a quirk of consumer ergonomics; it’s that the silicon inside it is the best-engineered package of mobile compute and sensors that human industry has ever produced. The “phone as robot brain” argument is really an argument about silicon, not form factor. And the silicon answer is: use what the phone industry built, whether the user ever sees a phone or not.

The two cases compound. The customer-brings-the-phone model brings the unit price of consumer personal robots down toward zero compute-side cost. The integrated-phone-silicon model brings the BoM of dedicated robots down to something a startup can actually afford to ship. The current “Jetson + RealSense” baseline is the worst of both worlds: more expensive than either, worse-performing than either.

And all of this lines up with where the broader AI industry is going. The trend is clearly toward small, locally-running ML models — distilled vision and language models that fit on consumer SoCs and run without a network — and away from giant data-center models accessed over an API. At the same time, the most plausible shape for the next generation of consumer robotics is not a single general-purpose humanoid that does everything; it’s many specialized appliances that each do one thing well. A boxing trainer. A kitchen helper. A garden weeder. A patrolling pet companion. The same way the appliance shelf in a home today contains a dozen single-purpose devices — toaster, microwave, blender, washing machine — the robot shelf tomorrow will contain a dozen single-purpose robots. Each of them needs perception, on-device ML, and actuation. None of them needs a data center, a $2,000 SBC, or a $400 stereo camera module. The phone-centric architecture is exactly the shape that both of those trends are converging on.

Where I’m Going Next

For context, the rig I’m currently running is a textbook traditional stack: a Raspberry Pi 5 (8 GB) + ELP USB stereo + Arduino Nano RP2040 (with built-in IMU) + motor driver. I’m migrating it to an iPhone 11 Pro Max — a six-year-old phone that, on every visual-SLAM benchmark I’ve run, beats the Pi 5 at lower power. The next step is to run mapping and depth perception on the iPhone and use those streams to drive the car. In the new build, the iPhone will run the perception and planning side — real-time mapping, pure pursuit for path following, gap-follow for reactive obstacle avoidance — and stream high-level drive commands to a small microcontroller on the car over Bluetooth. The MCU will handle the low-level motor control and talk to the motor driver directly. The traditional architecture cannot match this stack on cost, on size, on power, or on algorithm quality.

Closing Thought

The robotics community has been treating “edge computer” and “Linux SBC” as synonyms for so long that we forgot the question. The actual question is: what’s the cheapest, smallest package that has cameras, some sensors, connectivity, storage, and a thermal envelope big enough to run robotic perception, planning, and control sustainably?

For roughly a billion people, that package is already in their pocket. We just haven’t acted like it yet.

References

· Kim, P., Kim, J., Song, M., Lee, Y., Jung, M., Kim, H.-G. (2022). A Benchmark Comparison of Four Off-the-Shelf Proprietary Visual–Inertial Odometry Systems. Sensors, 22(24), 9873. doi.org/10.3390/s22249873

· Marino, E., Bruno, F., Barbieri, L., Lagudi, A. (2022). Benchmarking Built-In Tracking Systems for Indoor AR Applications on Popular Mobile Devices. Sensors, 22(14), 5382. doi.org/10.3390/s22145382

· Delmerico, J., Scaramuzza, D. (2018). A Benchmark Comparison of Monocular Visual-Inertial Odometry Algorithms for Flying Robots. IEEE International Conference on Robotics and Automation (ICRA).

· RTAB-Map iOS app — introlab.github.io/rtabmap (and available through App Store)

Follow along with more robotics builds:

youtube.com/@FouadRobotics Fouadrobotics.com