Robotics for research and university labs
Petronella Technology Group helps research universities and grant funded labs prototype robots without giving up data sovereignty. We operate a Reachy Mini in our Raleigh lab, run a private NVIDIA Elite Partner Channel GPU fleet, and build secure pipelines that let principal investigators publish, demonstrate, and re-train without sending lab data to a public AI cloud.
Grants, IRB protocols, tech transfer offices, and the people who actually do the work
Robotics development inside a research university looks nothing like robotics development inside a defense prime or a Series B startup. The buying unit is a principal investigator with a grant, supported by post-docs and PhD students who do most of the building, observed by an Institutional Review Board, and indirectly governed by a university tech transfer office that owns the intellectual property paperwork. Anyone selling into this environment has to understand all four constituencies or the engagement stalls before the first sprint.
Principal investigators hold the grant and the lab. Their incentive is publication velocity, conference deadlines, and the next funding cycle. They do not have time to manage a vendor relationship that requires constant translation. They expect a partner who can read a Notice of Award, understand what the sponsor will reimburse, work inside the academic calendar, and ship usable artifacts a graduate student can pick up and extend.
Post-docs and PhD students do most of the engineering work. They are some of the strongest robotics talent in the world, but they rotate. A two-year post-doc, a three-year PhD push, a graduating cohort. The systems we build with them have to outlive the people who built them. That means documented setup, version-pinned dependencies, reproducible MuJoCo and LeRobot environments, and a code repository that a new graduate student can clone on day one and run on day two.
The Institutional Review Board reviews any work that involves human subjects, including human-robot interaction studies that record video, audio, gait data, or biometric signals. The IRB is not the enemy of the engineering team. It is a peer reviewer for the human-subjects piece of the work. We design data flows that the IRB can approve quickly, and we keep the audit trail the IRB will ask to see at renewal time.
The university tech transfer office owns the IP outputs, files the disclosures, and decides whether something becomes a license, a startup, or stays inside the lab. We respect the IP policy of the host institution. Our default contract language places lab-developed code, models, and CAD under the institution IP regime, and we do not push for ownership claims that would conflict with what the post-doc signed when they joined.
The funding sources shape everything else. The National Science Foundation Foundational Research in Robotics (FRR) program funds basic and use-inspired robotics research with three-year project awards. The NIH BRAIN Initiative funds neuro-robotics intersections including assistive devices and brain-machine interfaces. DARPA funds defense-adjacent academic work through Young Faculty Awards and program-specific solicitations. SBIR/STTR funds early commercialization with university subcontracts. Each program has different cost categories, different intellectual property rules, different reporting cadence, and different acceptable-use policies. We line up our deliverables with the actual budget categories the principal investigator has to spend through.
The personas we work with most often are the assistant or associate professor running the lab, the lab manager who handles purchasing and onboarding, and the senior PhD student or post-doc who has been told "you are leading the robotics part." When we draft a statement of work, we draft it for that triangle, not for a corporate procurement office that does not exist in this world.
One detail that surprises new partners: the academic calendar is the schedule. A post-doc finishing a manuscript in February is not going to commit to a sprint plan that requires their attention in the same week. A new cohort onboarding in late August needs a documented runbook ready before they arrive, not after. Conference deadlines (RSS, IROS, ICRA, CoRL, NeurIPS, CHI for HRI work) drive availability windows. We plan around them. Vendors who do not are remembered for the wrong reason.
What labs are actually building, and what we support
The patterns below come from publicly visible work at the major US robotics programs and from the Hugging Face LeRobot ecosystem (39 models and 181 datasets on the Hub at the time of writing). We do not claim partnerships with these labs. We list them here because the research patterns we support map directly onto the work they have already published.
Imitation learning, fine motor skill, dexterous grasping
Single-arm and bimanual manipulation studies on the SO-100, SO-101, Koch v1.1, ALOHA, Reachy 2, and Reachy Mini classes of platform. The ALOHA project from Stanford set a strong public baseline for low-cost bimanual teleoperation, and that work flows into LeRobot through public datasets and reference policies. Labs we support build on top of that pattern with their own task suites.
HRI, conversational robots, expressive head motion
Reachy Mini is a desktop expressive humanoid built specifically for HRI study (6 DOF head, body rotation, animated antennas, 4 microphones, 1 wide-angle camera, 5 W speaker, per the Hugging Face Reachy Mini launch post). It pairs with an LLM front-end for conversational studies, gesture-recognition studies, and expressive-motion research. Labs at MIT CSAIL and Stanford AI Lab (SAIL) have published HRI work on adjacent platforms.
Remote presence, shared autonomy, demonstration capture
Teleop is now the dominant data-collection method for imitation learning. DROID (the large-scale manipulation dataset co-authored by Berkeley AI Research, Stanford, and others) is one public anchor. Labs we support stand up their own teleop rigs, capture episodes, and train policies on owned hardware so the dataset never leaves the lab perimeter when it should not.
MuJoCo, Isaac Sim, and the bridge to physical hardware
Reachy Mini ships with a MuJoCo-based open-source simulation SDK (per the launch announcement). Sim-to-real workflows train policies in simulation, validate on a small real-hardware fleet, and iterate. RoboCasa and RoboMimic are public benchmarks the LeRobot stack already understands. We help labs stand up the simulator on their own GPUs and the real hardware on the bench at the same time.
VLA models like SmolVLA, RT-2, and OpenVLA
VLA models accept a natural-language instruction plus a camera frame and emit robot actions. The SmolVLA paper documents training on 4 GPUs with consumer-grade GPUs sufficient for inference, and RT-2 from Google DeepMind defined the modern VLA pattern. Labs we support train these models on owned GPU clusters, run inference on the robot or a tethered host, and avoid the public-cloud round trip.
Stretch 3, LeKiwi, and mobile bases for assistive research
Mobile-manipulator research is active in healthcare, accessibility, and ADL (activities of daily living) labs. Hello Robot Stretch 3 is a research-grade mobile manipulator widely used in this space, and LeRobot lists LeKiwi and Earth Rover Mini among its supported platforms (per the LeRobot real-world robot documentation). We integrate these with LeRobot pipelines on the lab's own compute.
The shared thread across these patterns is reproducibility. A robotics paper that cannot be re-run by reviewers, by the next post-doc cohort, or by an independent lab in another country is a paper with a half-life. We build for the case where the work has to keep running after the principal investigator goes on sabbatical. The Carnegie Mellon Robotics Institute publishes what is widely considered the canonical body of US robotics research, and the practical lessons in their work (rigorous evaluation harnesses, public dataset releases, hardware-agnostic policy code) inform how we structure our own deliverables. See our robotics overview for the full pillar and our robotics prototyping engagement for the deliverable view.
IRB, data management, export controls, and student researchers
Research robotics rarely sits inside a single regulatory regime. A typical project crosses Common Rule territory if the experiments involve people, NSF or NIH data management requirements as a grant-funding condition, ITAR or EAR if any collaborator is a foreign national or any technology is controlled, and FERPA when the post-docs or graduate students touching the data are also enrolled students. Our job is to make the IT environment satisfy all of them at once without slowing the science.
Human-subjects research and the 45 CFR 46 framework
Any robotics study that records video of a person, captures audio, measures biometric signals, or asks a participant to interact with a robot falls under the federal Common Rule (45 CFR 46). We design the data flow so the IRB-approved scope is enforced at the system layer. Recordings land in a study-specific bucket with retention rules, identifiers are kept in a separate enclave the engineers cannot touch, and the consent-form decisions follow the data through to publication.
Required at proposal time, audited at renewal
Every NSF proposal includes a Data Management Plan that commits the principal investigator to specific storage, retention, and sharing practices. The DMP is then audited indirectly when the project applies for renewal or a follow-on award. We help align the DMP language with what we will actually deploy, and we deliver the audit evidence at year-end so the next proposal is easier than the last one.
Neural data sharing rules and DUA-bound flows
Awards under the NIH BRAIN Initiative commonly include neural recording datasets governed by the NIH Genomic Data Sharing Policy, the BRAIN Initiative data sharing supplement, and project-specific Data Use Agreements. We deploy storage that honors the DUA at the access layer, run de-identification pipelines on outbound data, and keep the audit log the program officer expects to see.
International collaborators, deemed exports, lab access
Robotics research with defense-adjacent technology can fall under International Traffic in Arms Regulations or Export Administration Regulations. Foreign-national lab members can trigger deemed-export concerns. We build identity systems where citizenship and export-license status are first-class attributes, group memberships propagate to storage and compute, and the network segmentation reflects the Technology Control Plan on file with the export compliance office. The research universities cybersecurity sibling page covers this in more depth on the security side.
When student researchers are also data subjects
Graduate students and post-docs are often both researchers and enrolled members of the institution. If lab data flows include a student's own learning analytics, course performance, or institutional records, the Family Educational Rights and Privacy Act applies. We separate research data from FERPA-protected records at the storage tier and document the legitimate educational interest determinations that justify any crossover.
What hardware can sit on a federally-funded grant
Section 889 of the FY2019 NDAA restricts use of certain telecommunications and surveillance equipment from designated foreign vendors on federally-funded work. We screen hardware bills of materials before purchase, document the vendor review trail, and source compute through the NVIDIA Elite Partner Channel rather than gray-market resellers. Software supply chain follows CISA SBOM guidance for transparency.
None of this is unique to robotics. What is unique to robotics is the rate at which one project can light up multiple regimes at once. A reasonable-looking HRI study with a Reachy Mini can simultaneously carry IRB human-subjects scope, NSF DMP commitments, FERPA crossover from a graduate-student researcher, and Section 889 supply-chain review. We design for the stack of regimes from the start, rather than discovering one of them at the end of the year when the grant officer asks. For a deeper dive into the cybersecurity-only view of these patterns, see the research universities cybersecurity sibling.
Cyber depth, Reachy-class hardware, private AI infrastructure, grant-aware budgets
Most robotics consultancies bring engineers. The wedge that university labs ask us about is the layer underneath the engineers: a cybersecurity and compliance foundation that lets the lab keep its data inside its perimeter while still using modern AI tooling, plus a hardware testbed in our own building that we can use to prototype at our cost rather than the lab's.
23-year cybersecurity foundation
Petronella Technology Group has been a cybersecurity firm in Raleigh since 2002. We hold CMMC-AB Registered Provider Organization status (RPO 1449), the entire delivery team carries CMMC-RP credentials, and Craig Petronella is a Digital Forensics Examiner (DFE 604180) with CCNA and CWNE on top. When a research robotics engagement needs an enclave, an SSP, or an incident response runbook, the same firm that designed the prototype already has the cyber posture in place.
Reachy Mini in our Raleigh lab
We operate a Reachy Mini, the open-source desktop humanoid that Hugging Face acquired from Pollen Robotics in April 2025, in our office in Raleigh. The unit is on a private network behind our standard managed-IT controls. We use it as a testbed for client engagements so we can prove a workflow on our hardware before the lab spends one minute of post-doc time on it. See the Reachy Mini hardware page for the spec sheet.
Private AI infrastructure that stays on-prem
We run a private GPU cluster sourced through the NVIDIA Elite Partner Channel for training LeRobot policies, fine-tuning vision language action models, and running inference on workloads that should not leave the institution. Training and inference happen on owned hardware, not on a public API. The private AI solutions page covers the platform.
Grant-aware budget structure
We have helped clients align deliverables with NSF, NIH, DARPA, and SBIR cost categories so the grant can actually pay for the work. Equipment lines, services lines, indirect-cost considerations, and the timing of subcontract invoices all change how an engagement is shaped. We will not propose a structure the principal investigator cannot defend at award management.
What we are not is a robotics-only firm. The robotics practice is a 2025 addition to a cybersecurity firm. That is the honest framing. It is also why our pitch to research universities lands cleanly: the labs we serve do not just need a robotics engineer, they need an engineer who can also speak fluently about CUI, IRB data flows, on-prem GPU sovereignty, and 23 years of running production IT in regulated environments. Read more in the AI services overview.
Three patterns plus an advisory option that align with how grants actually pay for work
University procurement does not look like enterprise procurement. The shape of the engagement matters more than the dollar figure on the proposal. Below are the patterns we use most often. None of these are templates we force onto a lab. They are starting points for a real conversation about what the grant will actually allow.
Single-grant scoped pilot
A 6 to 12 month engagement attached to a single Notice of Award. Common shape: discovery in month 1, architecture and security plan in month 2, prototype build months 3 to 6, hardening and handoff months 7 to 9, optional support tail months 10 to 12. The deliverable is a working prototype on hardware the lab owns, with documentation a new graduate student can pick up and extend. We stay inside the budget category the principal investigator can spend through (usually a subcontract or a services line).
Multi-year program partner
A 2 to 3 year engagement attached to a multi-year program (NSF FRR, NIH BRAIN, DARPA Young Faculty Award, or a center grant). Quarterly cadence, named technical lead from our side, named principal investigator and post-doc on the lab side. The relationship is structured so we can renew under a follow-on award without re-negotiating the master terms. We participate in proposal development for follow-ons when the principal investigator wants that input, at no cost.
Departmental shared resource model
For larger institutions or institutes where multiple labs share infrastructure (a robotics maker space, a shared GPU cluster, a teaching collection), we engage with the department or institute as a managed-services partner. Per-lab usage is tracked, charge-back is honored if the institution requires it, and onboarding for a new lab joining the shared resource is a documented procedure rather than a re-negotiation. This model works well when the host institution wants one vendor relationship to manage instead of one per lab.
One-time advisory engagement
Sometimes a lab does not need build work, it needs an outside review of the architecture, the security posture, the data management plan, or the path to a CMMC-aligned subcontract on a defense-adjacent grant. We offer a fixed-fee advisory pattern (typically 20 to 60 hours) with a written report and a follow-up working session. It is the smallest engagement we offer, and it is the most common entry point for new lab relationships.
Multi-PI shared volumes, IRB audit trails, and NIH-funded data sovereignty
Research data is messier than enterprise data. A single lab volume can hold raw sensor recordings, processed datasets, model checkpoints, intermediate analysis notebooks, and shared resources from collaborating institutions, all under different access scopes and retention rules. The technical patterns below come from work in regulated industries (cybersecurity is our day job) adapted for the research environment.
Per-protocol shared storage with audit boundaries
Where multiple principal investigators share a robotics maker space or GPU cluster, the storage is partitioned by protocol, not by lab. Each IRB-approved protocol gets its own volume with its own retention rule, its own access list, and its own audit log. A graduate student rotating between two PIs sees both volumes through their identity, but the audit trail records every read and write per protocol, not per user. The auditor can answer "who touched protocol P-2025-014's data on March 12?" in a single query.
Evidence the IRB can pull on demand
For human-subjects research, the IRB renewal review can request an audit of who accessed what protocol data over the prior period. We deliver this as a system-generated report rather than a coordinator-assembled spreadsheet. Identity, action, timestamp, and protocol scope come from append-only logs that the lab cannot edit retroactively. The renewal process becomes a Tuesday afternoon, not a fire drill.
NIH-funded data stays in the institution
For NIH-funded work, especially BRAIN Initiative recordings or genomic-adjacent data, our default architecture keeps raw data on lab-owned encrypted storage. Training and inference run on owned GPUs through our private LLM platform. The data does not transit a public API, does not get fed to a public model for training, and does not leave the institution network without an explicit, logged, IRB-approved data sharing event.
Containerized environments that survive a cohort change
We build LeRobot training and inference environments as versioned containers with pinned model weights, pinned Python (>=3.12) and PyTorch (>=2.10) per the LeRobot installation docs, and pinned hardware drivers. A new graduate student can clone the repo, pull the container, and reproduce a result from the lab prior publication on day one. The science gains are obvious. The compliance gains (the lab can prove the environment that produced a published result) are the quiet bonus.
Sensor data integrity from capture to publication
Robot sensor recordings are evidence in a scientific sense. We sign recordings at capture time, store them write-once on lab-owned storage, and produce a verifiable chain of custody from camera or microphone capture to the final dataset that ships with the paper. For DFE-adjacent forensic robustness we apply the same evidence-handling rigor we use in our digital forensics practice (Craig Petronella DFE 604180 work).
Cross-institution data collection without leaking PII
Teleoperation studies sometimes span institutions. The remote operator is on one campus, the robot is on another. We build the network path so the teleop traffic is encrypted end-to-end, the recording lands at the host institution per the IRB-approved data flow, and the remote operator never has filesystem-level access to the recordings. Cross-institution work happens. PII does not leak.
Procurement, grants alignment, the Reachy Mini in our Raleigh lab
University procurement is real, and not negotiable. The path from first call to a signed engagement is a few weeks longer than commercial procurement and a different shape. We have built our intake to fit the academic side, not to fight it.
University procurement vehicles. Most of the labs we serve into purchase through one of three paths: a direct purchase order on the lab grant, a subcontract under a federal flow-through, or a state cooperative purchasing agreement. We can quote against any of the three. We will not pretend a vehicle exists when it does not, and we will tell the principal investigator early if the proposed structure will not work under their grant terms.
Grant alignment. Before we propose a structure, we read the Notice of Award. Equipment thresholds, services categories, allowable indirect-cost handling, and pre-approval requirements vary by sponsor and by institution. We will work with the office of sponsored programs (or its equivalent) to confirm the structure is allowable before we send a proposal the principal investigator might not be able to spend through. We do this even if it costs us the engagement. A grant we cannot honestly bill against is not an engagement we want.
The Reachy Mini in our Raleigh lab as testbed. Our Reachy Mini sits on a workbench in our office at 5540 Centerview Drive, Suite 200, Raleigh, NC 27606. It is on its own VLAN, behind our standard managed-IT controls, and tied into our private GPU cluster for any training-side work. We use it for three things in client engagements: (1) prototyping a workflow before the lab commits its own time, (2) demonstrating a behavior to a principal investigator who is evaluating the platform for a grant proposal, (3) reproducing a paper or a public LeRobot example so we can give the lab a working baseline to extend. None of this is performative. It is the cheapest way for both sides to find out if a workflow is going to behave the way the proposal said it would.
Onsite when it matters. Our office is 10 minutes from NC State, 30 minutes from Duke and UNC, and inside the Research Triangle Park service radius. When a lab needs hands on a rack, an in-person review with the office of sponsored programs, or a working session with the IRB office, we drive. National engagements are delivered remotely with periodic site visits structured around grant milestones.
What we will not do. We will not write a proposal in someone voice for a grant they did not earn. We will not bill against a budget category the institution flagged as ineligible. We will not put a Reachy Mini in a clinical environment without IRB approval. We will not fabricate a partnership with Pollen Robotics, Hugging Face, or NVIDIA. Where we sit in those ecosystems is plainly stated: we are an active customer of Reachy Mini hardware, an open-source participant in the Hugging Face LeRobot community, and a buyer through the NVIDIA Elite Partner Channel.
FAQ
Have you worked with research universities before?
Do you support the LeRobot stack natively?
Can our PhD students train large policies on your GPUs instead of ours?
How do you handle IRB-protected video or audio recordings of human subjects?
Can the Reachy Mini in your lab be used as a demo before our grant award lands?
Do you sign data use agreements with NIH-funded sponsors?
What is the difference between this page and the cybersecurity sibling page?
How fast can a small pilot start?
Do you offer reduced rates for academic engagements?
Can we bring our own robotics platform instead of Reachy Mini?
How does your work intersect with the canonical academic robotics labs?
See the cybersecurity sibling
This page covers robotics development for research universities. The cybersecurity, compliance, and research-IT view (CMMC L2 in academia, CUI enclaves, ITAR enforcement, REDCap hardening, FERPA crossover) is on the sibling page. Engagements often touch both.
See the cybersecurity sibling →Bring your grant. We will bring the robot, the GPUs, and the security posture.
Talk to a research-robotics engineer about your award, your lab, your IRB scope, and your data sovereignty plans. First call is a conversation, not a pitch.
Get the Secure Robotics Development Brief
Tell Petronella Technology Group about your robotics project. We will reply within 4 business hours with a CMMC-RP led scoping conversation and the early-access edition of our Secure Robotics Development Brief covering CUI handling, on-prem AI inference for robotics, and CMMC-aligned development practices. No obligation. No sales pressure.