In this interview, Todd Roberts, CEO and co-founder of ATDev, explains why assistive robotics must be designed around a spectrum of autonomy rather than full automation. He discusses how real-world disability, clinical workflows, and safety-critical use cases shaped ATDev’s approach to preserving user agency while scaling robotic assistance.
Q: Assistive robotics sits at a tension point between autonomy and user agency. If a system becomes too autonomous, the user risks losing control. How do you design decision boundaries that ensure the AI assists without overriding user intent, especially in safety-critical situations?
A: When we talk about autonomy in assistive robotics, it is more accurate to think in terms of a spectrum rather than a binary choice between manual control and full automation. Different tasks, users, and contexts demand different points along that spectrum, and good design allows movement along it rather than locking a system into a single mode.
At one end of the spectrum is direct user control, where the system functions as an extension of the user’s body. The AI is largely invisible, providing signal filtering, stabilization, or force amplification without making independent decisions. This is essential for preserving agency in tasks where intent is highly personal or situational. Moving along the spectrum, shared autonomy becomes valuable. Here, the user defines the goal or direction, and the system assists with execution by handling subtasks such as obstacle avoidance, trajectory smoothing, or error correction. The key is that the AI is optimizing how something is done, not what is done.
Further along, conditional autonomy can support repetitive or physically demanding actions under clearly defined constraints. The system may take temporary control to complete a bounded task, but only with explicit consent and continuous monitoring. Importantly, the user must be able to interrupt, override, or reclaim control at any moment. At the far end of the spectrum is full autonomy, which is rarely appropriate in assistive contexts and, in our view, should be reserved for narrowly scoped safety functions or environments where user interaction is impossible.
Designing for a spectrum of autonomy acknowledges that users’ needs change over time due to fatigue, progression of disability, or environmental complexity. The system should adapt accordingly, scaling assistance up or down while keeping intent, authority, and trust anchored with the human. Autonomy, in this sense, is not about replacing the users’ control, but about meeting them where they are and supporting them without diminishing their role in the interaction.
Q: Your founding story includes living with Owen Kent, which gave you continuous exposure to real-world disability rather than episodic user studies. What core engineering assumption from your academic training was most decisively broken once you observed daily life in a home environment?
A: The most decisive assumption that broke was the idea that you can meaningfully separate “the task” from the surrounding context. In academic training, we tend to model assistive technology as something that solves a discrete, well-defined problem. Grasp this object. Navigate from point A to point B. Perform a therapy movement. Living in a home environment made it immediately clear that daily life does not decompose cleanly into isolated tasks. Every action is embedded in timing, fatigue, social dynamics, spatial constraints, and competing priorities that shift hour by hour.
What surprised me most was how often the technically correct solution was functionally useless. A system could perform well in a lab setting and still fail because it assumed ideal posture, uninterrupted attention, consistent energy levels, or perfectly prepared environments. Academic models often assume that if you reduce physical effort, you are helping. In reality, reducing physical effort at the cost of cognitive load, setup complexity, or loss of control can actually make someone less independent. Watching daily life unfold showed that reliability, predictability, and ease of recovery from failure matter far more than peak performance metrics.
That experience fundamentally changed how we think about engineering priorities. Instead of optimizing for task completion in isolation, we design for continuity of living. How quickly can someone recover when something goes wrong? How easily can the system be used when the user is tired, distracted, or frustrated? How much invisible labor does it introduce? The core lesson was that assistive technology succeeds or fails in the margins of everyday life, not in the moments we usually design for in the lab.
Q: Remote Therapeutic Monitoring CPT codes have created new business models for rehabilitation devices. To what extent did reimbursement requirements shape the design of Reflex itself, and were any features built primarily to satisfy billing or audit constraints rather than clinical necessity?
A: Reimbursement requirements absolutely influenced the design of Reflex, but in a deliberate and bounded way. We did not start with CPT codes and work backward to a product. We started with a clinically meaningful use case and then ensured the system could generate the objective evidence required to operate sustainably within existing reimbursement frameworks. Remote Therapeutic Monitoring codes did not dictate what Reflex does, but they did shape how Reflex measures, documents, and communicates what it does.
In practice, this meant building robust data capture, time tracking, and adherence metrics directly into the core architecture rather than treating them as an afterthought. Features such as session logging, range of motion quantification, usage duration, and clinician facing dashboards serve a dual purpose. Clinically, they allow therapists to assess progress, adjust protocols, and intervene earlier. From a reimbursement standpoint, they provide defensible, auditable records that demonstrate medical necessity, patient engagement, and ongoing therapeutic oversight. Those two goals are tightly aligned when done correctly.
That said, we were very intentional about not adding features solely to satisfy billing at the expense of the user or clinician experience. Any feature that increased cognitive burden, setup time, or friction for the patient was treated as a design failure, even if it made documentation easier. In cases where billing requirements demanded specific data points, we focused on passive or automated capture rather than manual input. The guiding principle was that reimbursement compliance should be invisible to the patient and minimally intrusive to the clinician.
Ultimately, CPT codes did not drive the clinical design of Reflex, but they did reinforce the importance of rigor, traceability, and accountability in the system. If a device is going to be prescribed, reimbursed, and scaled within real healthcare systems, it has to speak both languages fluently. The challenge is ensuring that the business model supports better care, not the other way around.
Q: Assistive technology has historically faced high R&D costs and limited market scale. Your shift from full exoskeleton concepts to a single-joint device appears pragmatic. Was this primarily a clinical insight, or a strategic move to survive commercialization constraints in the orthopedic market?
A: It was both, but the clinical insight came first and ultimately justified the strategy. Early on, full exoskeletons were appealing because they represented a comprehensive, almost aspirational vision of mobility. In practice, living in clinical environments and watching real rehabilitation workflows revealed that most functional gains in outpatient and post-acute care are driven by very specific joints, very specific movements, and very specific windows of recovery. The knee, in particular, sits at the center of gait, transfers, and fall risk, yet it is underserved by scalable, home-based robotic therapy.
That realization aligned quickly with commercialization realities. Full exoskeletons carry enormous R&D, regulatory, and deployment costs, and they demand specialized clinical infrastructure. That makes them difficult to scale in orthopedic markets that are driven by volume, reimbursement efficiency, and clinician time constraints. By focusing on a single joint, we could dramatically reduce system complexity, cost, and regulatory burden while still delivering measurable clinical value. This was not a compromise of ambition, but a reframing of impact. Solving one problem well, in a way that fits real care pathways, creates more real-world benefit than solving everything poorly.
From a business perspective, the single-joint approach allowed us to enter the market with a device that could be prescribed, reimbursed, and supported within existing workflows, while still serving as a technological foundation for a broader robotic ecosystem. Reflex was designed as a wedge, not an endpoint. It generates clinical data, clinician trust, and payer validation that would be nearly impossible to establish starting with a full-body system.
So while commercialization constraints mattered, they did not force the decision. They reinforced it. The combination of clinical observation and market discipline pointed to the same conclusion: scalable assistive robotics will succeed by being precise, focused, and deeply integrated into how care is actually delivered, not by trying to leap straight to the most technically impressive form factor.
Q: The RAMMP program carries an open-source mandate, while venture-backed companies are expected to build defensible IP. How do you reconcile these two forces structurally, and where do you draw the line between open contribution and commercial protection?
A: We reconcile those forces by being very explicit about what needs to be open to advance the field and what needs to remain protected to sustain a company. Open source and defensible IP are often framed as oppositional, but in practice they operate at different layers of the stack. The RAMMP program is fundamentally about accelerating a shared research and development substrate for assistive robotics, and that is where openness has the highest leverage. Interfaces, data schemas, simulation environments, reference architectures, and baseline control frameworks are far more valuable to the ecosystem when they are shared than when they are siloed.
Structurally, we draw a clear line between platform-level contributions and product-level differentiation. Core operating concepts, interoperability standards, and tooling that enable researchers, clinicians, and developers to build and test assistive systems belong in the open domain. These elements reduce duplication, improve reproducibility, and allow innovation to compound across institutions. In contrast, commercial protection applies to specific implementations that translate those foundations into safe, manufacturable, regulated products. That includes proprietary mechanical designs, manufacturing processes, system integration, clinical protocols, and regulatory know-how. Those are not abstractions. They are hard-won capabilities that determine whether something works reliably in the real world.
Another important distinction is governance. Open contributions are structured, intentional, and documented, not a leakage of IP. We contribute through defined repositories, licenses, and scopes that align with the program’s mandate while preserving freedom to operate commercially. Venture investors are not funding secrecy for its own sake. They are funding execution risk, regulatory burden, and the ability to deliver at scale. Protecting that execution layer is not at odds with open science. It is what allows open research to escape the lab and reach people’s homes.
Ultimately, the line is drawn at user impact. Anything that benefits from broad collaboration and does not require centralized control to be safe or effective should be open. Anything that carries regulatory liability, manufacturing responsibility, or direct patient risk must be owned, validated, and supported by a commercial entity. If we get that balance right, openness becomes an accelerant rather than a threat, and IP becomes a tool for sustainability rather than exclusion.
Q: Your CTO previously led R&D at SmartDrive, one of the few commercially successful assistive mobility products. What specific scaling or support failure modes from that experience are you deliberately engineering around at ATDev?
A: That experience was invaluable because it exposed the gap between getting a product to market and sustaining it at scale in the real world. One of the most important failure modes we are deliberately engineering around is support load that grows faster than revenue. In assistive mobility, even a small friction point can cascade into high-touch customer support, returns, or device abandonment. At SmartDrive, it became clear that system complexity must not translate to user complexity or training complexity. The interface that the user learns and uses on a daily basis must be simple and intuitive enough that it removes friction from their ADLs, rather than adding friction. Additionally, there must be feedback provided by the system so that the user immediately understands when the system is detecting and translating their intent to action. This feedback builds trust between the user and the system and is critical for ensuring that the system is acting as an extension of the user, rather than independently from the user. These core system and experience design principles directly translate to the products that we are designing and developing at ATDev.
Additionally, we are designing ATDev products with serviceability and observability as core engineering requirements, not downstream concerns. Devices are built to self-diagnose, log meaningful state data, and surface actionable information remotely so issues can be resolved without repeated in-person visits. We are also intentionally minimizing configuration surfaces. Fewer modes, fewer hidden states, and clearer feedback loops reduce user confusion and clinician burden. If a device requires expert intuition to understand why it is behaving a certain way, it will not scale.
Another lesson was the importance of aligning incentives across users, clinicians, and support teams. Products that technically empower users but lack clear onboarding, training pathways, or clinical integration often end up underutilized. We are engineering workflows, not just hardware. That means designing devices that fit naturally into care delivery and daily life, with predictable behavior across environments. Variability is unavoidable in real-world use, but surprises should be rare and recoverable.
Finally, we are engineering around the long tail of edge cases. At scale, edge cases are not edge cases. They are the product. Differences in user strength, cognition, home environments, and caregiver involvement all surface quickly once you leave controlled pilots. SmartDrive demonstrated that success in assistive mobility is not about peak performance. It is about resilience, support efficiency, and trust over years of use. ATDev’s approach is shaped by that reality from day one.
Q: Looking five years ahead, do you expect ATDev to primarily be a hardware company or a musculoskeletal data platform built on deployed devices, and if hardware becomes commoditized, where does lasting value actually reside?
A: Looking five years ahead, we do not see ATDev as choosing between being a hardware company or a data company. We see ourselves as building a robotics mobility ecosystem where hardware, software, and musculoskeletal intelligence are inseparable. Devices like Reflex, power wheelchairs, and future platforms such as RAMMP are not endpoints. They are anchors that allow us to safely deploy intelligence into real environments and generate high-quality, longitudinal data about movement, recovery, and independence.
Hardware will continue to matter because it is the enforcement layer. If you do not control the physical interface with the human body, you cannot guarantee safety, data integrity, or consistent user experience. Power wheelchairs, in particular, are foundational. They are already central to daily life, continuously in use, and deeply tied to mobility, fatigue, and independence. By building robotic mobility and assistive intelligence directly into these platforms, we gain a persistent, real-world signal that no episodic clinical device can provide. RAMMP fits into this vision as a modular robotic layer that extends capability without forcing users into entirely new form factors or workflows.
As components commoditize, lasting value shifts to the system-level intelligence that sits across devices. That includes how we fuse data from rehabilitation, mobility, and daily activity; how we adapt assistance over time; and how we translate that information into actionable insight for users, clinicians, and care systems. The defensible asset is not a single robot, but the continuously improving understanding of how musculoskeletal systems behave in the real world when people are living their lives, not performing scripted tasks.
In that future, ATDev’s advantage comes from owning the full loop. Hardware captures truth. Software contextualizes it. Data enables prediction, personalization, and scale. The robotics mobility ecosystem allows those elements to reinforce each other across rehabilitation, power mobility, and daily living. That is where durable value resides, not in any one device, but in the integrated system that evolves alongside the people who rely on it.
Editor’s Note
This interview reflects a broader shift in assistive robotics away from maximal autonomy toward systems that prioritize trust, recoverability, and continuous human control in real-world environments.
