Open-source robots, built for your work

Custom robotics development is the engineering practice of taking a real-world task that a human, a fixed-function machine, or no automation currently performs and producing a robotic system that performs it well enough to evaluate, deploy, or scale. It spans hardware selection, mechanical adaptation, sensor integration, perception software, motion planning, learned policies, teleoperation surfaces, simulation, safety analysis, and the operational documentation that lets the system survive the handoff to an operating team. It is not a product purchase. It is a project.

The label "robotics" gets stretched in the market to cover everything from fixed industrial cobots to autonomous vehicles to surgical platforms to humanoid demos. To be useful, the practice has to be scoped. Petronella's robotics practice deliberately stays inside prototyping, research-and-development, and demonstration builds. We do not ship industrial cobot integration, autonomous vehicles, surgical robotics, weapons platforms, or humanoid manufacturing. Inside the lane we do operate, the work is a custom build, not a configured purchase.

The taxonomy a buyer should know

When a procurement team or research PI starts scoping a robotics build, the first useful step is a clear taxonomy of what they are buying. Three categories cover most of what we are asked about:

• Fixed-function robotic systems. A catalog cobot or industrial arm running a configured program for a known task. Off-the-shelf, low custom engineering, deployed by an integrator. This is not what custom robotics development is for.
• Application-specific custom builds. A robot platform combined with custom perception, custom control, custom interfaces, and custom data pipelines for a task no off-the-shelf product solves. This is the bulk of what serious R&D and prototyping engagements look like, and it is where Petronella plays.
• Foundational research. Robotics work whose purpose is to extend the field, produce papers, train models, or generate datasets. Our role here is implementation partner to a research lab or PI, not principal investigator. Our compliance and infrastructure foundation is the value-add.

What a "custom" build actually contains

A custom robotics development engagement is several streams of work that converge: a hardware stream (platform selection, mounts, end-effectors, sensors, power, networking), a software stream (perception, control, behavior code, simulation, evaluation), a data stream (teleoperation captures, learning datasets, policy weights, evaluation sets), a security and compliance stream (audit logging, access control, secrets handling, data residency), and an operations stream (runbook, on-call posture, documentation, handoff). Underspecify any one stream and the prototype either does not run, does not pass review, or does not survive the first staff change.

Open-source as a default

Modern robotics has converged on a layer of open-source primitives that make custom work tractable: the Robot Operating System (ROS) ecosystem, the Hugging Face LeRobot library for learned policies, simulation environments such as MuJoCo and Gazebo, and a growing fleet of open-hardware platforms that make iteration fast. Petronella's practice defaults to these primitives. They reduce vendor lock-in, accelerate prototyping, and produce systems that an in-house team can continue to evolve after the engagement closes.

The shortest correct definition: custom robotics development is the engineering work that turns a task description into a working, evaluable robotic system on hardware and software the client can keep running. Everything else on this page is how Petronella Technology Group does that for organizations that cannot send their data to a public cloud while doing it.

Why "custom" is the right word for the regulated case

It is worth saying out loud why this lane of work needs to be custom in the first place. Off-the-shelf robotics products are designed for the broadest customer cross-section the vendor can find, which means the data assumptions, the integration assumptions, the network assumptions, and the security assumptions all default to "internet-connected, cloud-backed, vendor-telemetered." That default is fine for an unregulated commercial deployment. It is wrong, on day one, for a CUI workload, a HIPAA-covered research project, or any IP-sensitive engineering build. The cheapest way to use a regulated dataset with a vendor's default product is usually not to use the product at all, because the moment the product phones home with a sample of the input, the regulated boundary has been crossed. Custom development re-asserts the boundary. The hardware platform may still be a vendor product (Reachy Mini, an open-hardware arm, an off-the-shelf manipulator); the software, the data plane, the model weights, and the operational posture are built around the boundary, not against it.

Petronella has been a Raleigh, NC cybersecurity practice since 2002. The firm holds CMMC-AB Registered Provider Organization #1449, an A+ BBB rating since 2003, and operates a private AI cluster from our facility for regulated workloads. When we started the robotics practice, the cybersecurity, compliance, and infrastructure substrate was already there. Robotics is a new application of a 23-year-old foundation, not a new firm.

That ordering matters because most custom robotics development firms approach security and compliance as an afterthought. They build a working prototype, then bolt on the audit story when the client's compliance officer reviews the engagement. We do the inverse. We assume the engagement is regulated until proven otherwise, sign the appropriate engagement letter (CMMC-aligned, HIPAA business associate agreement, or research data use agreement) before any controlled data enters scope, and design the development environment around the data class on day one.

What "cyber-first" means in practice

It means we do not build a robotics prototype on a developer laptop that is also reading personal email. It means the development environment runs on hardware we operate, with audit logging on by default, with access scoped to named identities, with secrets managed in a vault rather than committed to a repository, and with a software bill of materials produced for every external dependency the build pulls in. That is not robotics-specific. It is what cybersecurity practice looks like applied to a robotics codebase.

What "compliance-first" means in practice

It means before we write a line of perception code that has to read sensor data from a regulated source, the data flow has been mapped against the relevant compliance frame. For Defense Industrial Base work, that frame is NIST SP 800-171 r3 and the CMMC Final Rule, with appropriate DFARS 252.204-7012 handling for any covered defense information that surfaces. For research-university work that touches human subjects, it is the Common Rule and the institution's IRB. For healthcare R&D that touches PHI, it is the HIPAA Security Rule. These are not obstacles to robotics work; they are the boundary inside which the work has to happen.

Sovereignty as the default deployment posture

The third piece of our approach is data sovereignty. Robotics builds today are LLM-adjacent, vision-model-adjacent, and dataset-adjacent in a way they were not five years ago. A learned manipulation policy is trained on a dataset, fine-tuned on the client's own captures, and run on inference hardware. If any of those steps quietly route through a public AI vendor, the regulated data class has just left the boundary. Petronella's robotics builds default to running on our private GPU fleet, sourced through the NVIDIA Elite Partner Channel, or on hardware we operate inside the client's facility. Public-cloud AI APIs are not in the default path. They are an opt-in for non-regulated workloads only.

For a deeper read on how the private-AI substrate works, see our private AI solutions pillar. The robotics practice is what happens when you point that substrate at a robot.

Reachy Mini, in our Raleigh lab

Petronella operates a Reachy Mini in our Raleigh, NC lab. Reachy Mini is the open-source desktop expressive humanoid built by Pollen Robotics (acquired by Hugging Face in April 2025) and launched in July 2025. The unit is 28 cm tall when active, 1.5 kg, with a 6-DOF head, full body rotation, 4 microphones, a wide-angle camera, a 5W speaker, and animated antennas. Reachy Mini ships in two variants: the $299 Reachy Mini Lite, which pairs to a Mac or Linux host, and the $449 Reachy Mini Wireless, which carries an onboard Raspberry Pi 4, Wi-Fi, and a battery. Pricing and specifications are sourced from the Hugging Face Reachy Mini launch announcement and verified against the Pollen Robotics organization on Hugging Face Hub.

The Reachy Mini is open-source on the software side and Pollen has stated CAD files for the hardware are pending release. The Python SDK is published at github.com/pollen-robotics/reachy_mini and the platform integrates with the Hugging Face LeRobot stack and the broader Hugging Face Spaces ecosystem of robot behaviors. The default privacy posture is documented by Hugging Face: "no personal data stored, transmitted, or processed by default; camera and microphone use fully user-controlled." That posture aligns with the regulated-deployment frame the regulated buyers we serve work inside.

Why the Reachy Mini is the right anchor platform

For a custom robotics prototyping practice, the platform anchor matters. The Reachy Mini was chosen for four reasons. First, it is open-source, which means the code, the platform integration patterns, and the underlying community work are accessible without a vendor approval cycle. Second, it sits on the LeRobot stack, which lets a Reachy Mini prototype reuse models, datasets, and tooling that work on a wide set of supported platforms (the LeRobot documentation lists SO-101, SO-100, Koch v1.1, LeKiwi, Hope Jr, Reachy 2, Unitree G1, Earth Rover Mini, OMX, OpenArm, Aloha, ViperX). Third, the price point ($299 to $449 per unit) makes fleet experimentation tractable for prototyping. Fourth, the platform's expressive form factor is well-suited to conversational AI, perception research, teleoperation studies, and human-robot-interaction pilots, which are the categories of prototyping our regulated clients ask about.

Private GPU fleet

The training and inference side of our robotics practice runs on a private GPU fleet operated from our Raleigh datacenter. The fleet is a mix of NVIDIA DGX, HGX, and RTX PRO systems sourced through the NVIDIA Elite Partner Channel. The same fleet underwrites our private AI cluster and is sized for regulated mid-market workloads: large enough to host meaningful LeRobot policies, vision-language-action models, and simulation runs, small enough to preserve the per-customer attention that hyperscaler help desks cannot offer. For workloads that exceed our cluster's local capacity, we deploy and operate dedicated GPU hardware in the client's colocation facility or on-premises rack under the same operations model. See our AI workstation hardware page for the underlying systems specification.

What we explicitly do not run on

For regulated robotics builds, we do not route training, fine-tuning, or inference through a public-cloud AI API by default. The default path is local hardware. Public-cloud AI is an opt-in for non-regulated workloads, with an explicit data-flow approval. The same posture applies to the perception side: we do not push client camera feeds through a third-party hosted perception service unless the client's compliance officer has explicitly approved the data flow. This is why "private GPU fleet" is the operative phrase, not "we use the cloud."

How the hardware combines into a build

A typical regulated prototype combines a Reachy Mini (or, for builds that need locomotion or arm dexterity, a different LeRobot-supported platform sourced for the project) with a perception and policy stack running on the private GPU fleet. The Reachy Mini Wireless variant runs onboard inference for low-latency expressive behaviors via its Raspberry Pi 4. Heavy training, fine-tuning, simulation, and large-scale evaluation runs land on the GPU fleet. The teleoperation interface, dataset capture, and policy-evaluation harness all run inside the client's compliance boundary. That topology is what "sovereign robotics prototyping" looks like in practice.

What the LeRobot stack gives us, concretely

The Hugging Face LeRobot stack is more than a library; it is a working set of models, datasets, hardware integrations, and evaluation harnesses that lets a small team produce a useful prototype in weeks rather than quarters. The publicly documented hardware support list spans SO-101, SO-100, Koch v1.1, LeKiwi, Hope Jr, Reachy 2, Unitree G1, Earth Rover Mini, OMX, OpenArm, Aloha, and ViperX, with camera support for OpenCV USB and built-in cameras, ZMQ network cameras, Intel RealSense depth cameras, and Reachy 2 cameras. For a prototyping practice, the practical effect is that a client's specific hardware ask rarely lands outside the supported set, which means time on the build phase goes into the client-specific work (perception, policy, integration, security overlay) rather than into porting to a non-standard platform. When the client's preferred platform does fall outside the supported set, that is a Phase 1 finding worth surfacing before the build phase commits.

The Petronella robotics practice is organized around three layers: a hardware spoke that documents the platform we operate, a solutions spoke that documents the engagement model, and a set of industries spokes that document how the practice maps to defense, research-university, and healthcare-research contexts. Every spoke links back here; this pillar links down to all of them. Use whichever entry point matches how you are evaluating us.

Defense and the Defense Industrial Base

Defense robotics work for prime contractors, sub-tier suppliers, and SBIR/STTR-funded programs is the natural home for our practice. The work is custom by definition, the data class is CUI by default, and the compliance frame is the CMMC Final Rule, NIST SP 800-171 r3, and DFARS 252.204-7012. Our CMMC-AB RPO #1449 standing means the engagement letter is written by people who write engagement letters for a living, not adapted from a generic master services template at the last minute. Typical work in this lane includes perception prototypes for defense logistics, teleoperation interfaces for stand-off applications, dataset curation pipelines for ML-driven defense AI, and demonstration builds for program-of-record evaluation. We do not do weapons platforms, autonomous combat systems, or anything that conflicts with the practice's documented exclusions. See the defense robotics page for the full scope.

Research universities and federally funded labs

Research universities with NSF Foundational Research in Robotics, NSF AI Institute, NIH BRAIN Initiative, or DARPA-funded grants need a robotics implementation partner who can move at the pace of grant timelines, integrate with the lab's existing ROS 2 codebase, work alongside graduate students without becoming the bottleneck, and respect the institution's IRB and research-data-management policies. We come from the cybersecurity side, which is unusual in the robotics-services space, and that turns out to matter for cyber-physical research where the lab's own data security posture is part of the grant deliverables. See the research university robotics page for the full scope, and the existing sibling page on research university cybersecurity for context on the broader practice.

Healthcare research and academic medical centers

Healthcare research robotics is a deliberately narrow lane for us. We do not build FDA-regulated Software as a Medical Device, surgical robotics, or any clinical-decision-support system that requires regulatory premarket review. We do support healthcare R&D groups, academic medical center engineering teams, and rehabilitation-research labs that need a robotics implementation partner who already speaks HIPAA, already understands the Common Rule and IRB process, and can build a perception or interaction prototype on infrastructure that does not push PHI through a public-cloud AI vendor. The exclusions are explicit on the healthcare research robotics page; the inclusions are equally explicit.

Verticals we deliberately do not serve

Industrial cobot integration on a factory floor, autonomous vehicles for on-road deployment, surgical robotics, defense weapons platforms, humanoid manufacturing at scale, and consumer robotics products are all out of scope. Several of those are fine markets; they are not our markets. Stating the lane sharply lets the firms that should pick us actually pick us, and lets the firms that need a different practice find it without a wasted call.

1. Phase 1 - Discovery and scoping. A two-to-three-week engagement to convert a task description into a written scope. We map the data flows, the regulatory frame, the success criteria, the integration surfaces, and the production constraints. Output: a written scope, a candidate platform shortlist, an evaluation harness sketch, and a go or no-go recommendation. The point of Phase 1 is to retire risk before either party signs a build contract. Roughly half of discovery engagements result in a recommendation that is something other than "build this." That is a feature, not a bug.
2. Phase 2 - Architecture and prototype. A four-to-eight-week sprint that produces a working robotics prototype on the agreed platform, with the perception, control, learned policy, and integration plumbing scaffolded. The prototype runs against a small, real evaluation set. We instrument the run with telemetry from day one. Output: a working demo, a code repository under your account or ours per the agreement, an evaluation report against the agreed criteria, and a written architecture document that the team can read after the engagement.
3. Phase 3 - Hardening and compliance overlay. A two-to-six-week phase that turns the prototype into something that can survive a real review. This is where the security overlay lands properly: secrets management, audit logging, access scoping, software-bill-of-materials production for every external dependency, threat model documentation, and penetration-test-equivalent review against the deployed prototype. The compliance frame (CMMC L2 controls, HIPAA Security Rule controls, IRB documentation) is mapped onto the build with evidence artifacts. Output: a hardened prototype, the compliance artifacts, the runbook, and a written go-or-no-go for the production decision.
4. Phase 4 - Handoff and operations. A two-to-four-week phase that hands the work to your team or to a Petronella managed engagement, depending on where you want to land. We document the operational posture, train the receiving team on the runbook, fix the things that surface in the first week of use, and define the on-call boundary going forward. Output: a stable operational footprint with a clear ownership model. We do not "throw it over the wall." If you want us to keep operating it under managed engagement, we do; if you want it to live entirely inside your team, it does. The choice is yours.

Phase gates, not phase suggestions

The boundary between phases is a written go-or-no-go, signed by both sides, that points at the deliverable produced in the previous phase. A phase that does not produce its deliverable does not graduate to the next phase. That sounds bureaucratic on the page; in practice it is what stops a build from drifting into the "scope creep until the budget runs out" pattern that kills most regulated prototyping engagements. Each phase gate is also where the client's procurement, legal, security, and program teams have a concrete artifact to review (a written scope, a working demo plus architecture document, a hardened prototype plus compliance evidence pack, an operational runbook) rather than an in-flight build that nobody outside the room can evaluate. We set the gate language in the master engagement letter on day one, so the cancellation right and the cost ceiling per phase are bilateral and explicit. That is what makes the methodology safe to run inside a regulator-watched program.

Why four phases rather than two

The honest answer is that "scope it and build it" engagements consistently underdeliver in regulated robotics work. The compliance overlay is not optional, the handoff is not optional, and treating both as side effects of the build phase is how a working prototype turns into an unreviewable artifact that nobody can operate. Splitting the engagement into four phases lets each phase succeed or be cancelled on its own merits, lets the client's procurement team write a smaller initial commitment, and lets us produce a written deliverable per phase that survives staff turnover. The four-phase pattern is what we run on private-AI engagements as well; the methodology is shared because the discipline is shared.

CMMC Levels 1, 2, and 3

For Defense Industrial Base work, the relevant frame is the CMMC Final Rule (32 CFR Part 170). CMMC L1 governs Federal Contract Information (FCI) handling at the FAR 52.204-21 baseline, applicable to the majority of DIB suppliers. CMMC L2 maps to NIST SP 800-171 r3 and applies to most CUI-handling work. CMMC L3 raises the bar to NIST SP 800-172 protections and applies to a smaller cohort of high-priority programs. Petronella consults at all three levels. For robotics builds in this lane, we treat the development environment, the dataset stores, the GPU fleet, and the prototype itself as in-scope assets, mapped to the relevant control families on day one. See the CMMC compliance pillar for our full compliance methodology.

NIST SP 800-171 r3 and DFARS 252.204-7012

Defense robotics work that touches CUI is governed by NIST SP 800-171 r3 (the CMMC L2 baseline) and DFARS 252.204-7012, which mandates safeguarding covered defense information and 72-hour cyber incident reporting. We map robotics-specific data flows (sensor captures, teleoperation logs, training datasets, policy weights, evaluation artifacts) to the 800-171 control set during Phase 1 discovery and produce the System Security Plan section that covers the prototype as part of Phase 3 hardening.

HIPAA Security Rule

For healthcare research robotics, the frame is the HIPAA Security Rule. We sign the appropriate Business Associate Agreement before any PHI enters scope. The development environment, the dataset stores, and the inference path are inside the BAA boundary. The Reachy Mini's documented default privacy posture (no personal data stored, transmitted, or processed by default; camera and microphone use fully user-controlled, per Hugging Face) is an additional layer; the operational layer is what we add.

Common Rule and IRB

For research-university and academic-medical-center work involving human subjects, we operate inside the institution's IRB process under the Common Rule (45 CFR 46). The IRB is the PI's; we are the implementation partner. Our role is to keep the data flows and consent posture documented and auditable in a way the IRB will accept.

NIST SSDF and SBOM discipline

For every robotics codebase we produce, we map the build to NIST SP 800-218 SSDF practices and produce a CISA-aligned Software Bill of Materials for every external dependency. This is what allows the receiving team to update the prototype safely after the engagement and what lets a security-officer review or a third-party auditor see exactly what is inside the build.

The point is not that we recite frameworks. The point is that we build robotics prototypes that pass the review the framework was written to require. That is what the compliance posture is for.

None of those differentiators is "we have built 100 robots." We have not. That claim would be fabricated. The claim that we hold a verifiable CMMC-RPO standing, run a verifiable private GPU fleet, and operate a verifiable Reachy Mini in our lab is the claim a regulated buyer can underwrite.

The named Petronella team holding CMMC-RP credentials reflects what we say we sell: a Petronella robotics engagement is led by people who write CMMC-aligned engagement letters for a living. The full team is CMMC-RP certified and works under RPO #1449 in good standing. For research and program-management partnerships, we work alongside the client's PI, IRB administrator, or contracting officer and treat their authority chain as authoritative.