Loading...
Skip to content

HRL / APPLICATION ENGINEERING

From a practical task.
To an engineered system.

Product-wise case studies exploring the environment, technology and evidence behind a robotics application.

Explore the studies
Engineering workflow connecting sensing, planning, actuation and measured validation in a feedback loop
THE ENGINEERING LOOP / DEFINE. INTEGRATE. MEASURE.
READ THE DATA CORRECTLY

Application studies, with transparent assumptions.

These are illustrative engineering cases, not claims of completed customer deployments. Product information comes from HRL’s published development material. Calculations show how a proposed application could be evaluated; they are not measured savings, guarantees or independent test results. Each study separates known product information from assumptions and the evidence still needed.

01 / HCR · FLOOR-CARE APPLICATION

A repeatable cleaning route
for a busy warehouse.

Illustrative setting: a warehouse with shared pedestrian aisles, changing stock positions and a planned cleaning window.

The operational question

How can a facilities team clean a defined floor area consistently while retaining control of exceptions? In this example, the team selects a 3,000 m² route inside a larger facility. It excludes loading bays during vehicle movement, damaged flooring and temporary storage areas. The objective is a repeatable process that can be inspected, rather than a promise to remove every manual cleaning task.

The proposed technical approach

HCR’s proposed application approach combines LiDAR, vision or time-of-flight sensing, an IMU and wheel encoders for navigation. Twin brushes address floor contact, while suction and a squeegee support recovery. A site-specific plan would define cleaning zones, restricted areas, docking access and operator handover. Manual override and emergency-stop arrangements remain part of the operating procedure.

Before autonomous trials, the team would map aisle widths, floor transitions, reflective surfaces and traffic patterns. Routes should be reviewed after layout changes. The planning target for tank capacity cannot establish refill frequency by itself: actual water demand depends on dosing, floor conditions, cleaning settings and the usable volume of each tank.

A planning calculation

Illustrative route model; no field measurements implied
InputPlanning value
Selected cleaning route3,000 m²
Assumed productive rate1,500 m²/h, within the development target range
Calculated productive time3,000 ÷ 1,500 = 2 hours
Assumed service / interruption allowance30 minutes
Illustrative operating window2.5 hours

The calculation is a scheduling example, not a throughput commitment. Using the endpoints of the published target range gives approximately 1.7–2.5 productive hours before interruptions. Obstacle stops, recovery passes, charging, refilling and servicing can extend the window.

What a pilot must establish

The pilot should record completed area, elapsed time, manual interventions, water added, recovery volume and post-clean inspection results. Operators should log why a task stopped, not just that it stopped. Compare the same route and inspection method over multiple shifts, including an appropriately supervised busy period. Any claimed labour, water or cost improvement requires a measured baseline with equivalent cleaning quality.

The case advances only when the route is repeatable, exceptions are manageable and the facilities team can operate and maintain the system. A successful demonstration in an empty aisle is one input to that decision, not a substitute for site acceptance.

02 / PAARTH R1 · RESEARCH APPLICATION

Turn a humanoid research question
into a measurable experiment.

Proposed research case: supervised perception and object-handling experiments in a controlled laboratory.

The research question

A laboratory wants to investigate how perception, task planning and controlled manipulation interact in a humanoid platform. The initial question is deliberately narrow: can an object be identified and handled consistently within a defined, supervised workspace? It is not a proposal for unattended work in a public space, and it does not presume that the developing robot already performs the task.

The proposed system boundary

Paarth R1’s published concept brings together RGB-D or stereo perception, inertial sensing, state estimation, motion planning and whole-body control. Independent safety layers are intended to retain authority over physical execution. A research plan should separate the high-level task request from the controls that decide whether movement is permitted.

The first experiment would use supported or constrained configurations chosen by the development team, lightweight test objects and an exclusion zone. It would not combine a new grasping task with unvalidated walking. Researchers should establish sensor calibration, joint limits, permitted motions and a repeatable reset condition before collecting comparative data.

A proposed trial matrix

Experiment design only; no trials or success rates claimed
VariableProposed test design
Object categories3 lightweight research objects
Starting poses4 defined poses per object
Repetitions5 per object / pose combination
Planned attempts3 × 4 × 5 = 60
Recorded outcomesCompletion, intervention, reset and fault reason

The matrix makes comparisons explicit. Each attempted task should carry an experiment identifier, configuration version and timestamp. Aborted attempts remain in the record; removing them would make the system appear more reliable than the evidence supports. Lighting, object placement and software revisions should be controlled or documented.

What the study could establish

Measurements would include task completion, intervention frequency, completion time and the consistency of the reset process. Researchers can then examine whether a change improves one metric while worsening another. A faster movement is not automatically a better outcome if it reduces control margin or makes recovery less predictable.

This case is a research framework, not a deployment report. Proposed payload, endurance and motion capabilities remain development targets. The 2028 sales-readiness date may change. Collaboration should begin with an agreed experiment, supervision plan and evidence requirements, followed by a review of what the platform can actually demonstrate at that stage.

03 / ROBOTIC ARMS · INTEGRATION APPLICATION

Build a handling cell
around the part and the process.

Illustrative setting: a small manufacturing team evaluating repeatable transfer of components to an inspection fixture.

The operational question

The team needs to transfer a component from a defined pickup location to an inspection fixture without losing orientation or damaging the surface. The robot is one part of the solution. Part presentation, gripper contact, fixture repeatability and the inspection handoff must be considered together. The case begins with a task specification rather than selecting an arm solely by its number of axes.

The proposed cell architecture

Engineers would assess the combined mass of the part and end effector, the required reach, cable routing, approach angles and available mounting space. A part-presence input, fixture-ready signal and inspection-complete signal form a proposed sequence. The cell should define what happens when a part is absent, a grasp is uncertain, the fixture is occupied or communication is lost.

A handling trial also needs a controlled loading arrangement and an appropriate safeguarding design. No collaborative-operation rating or suitability for unguarded use is implied. Operating limits, guarding, safe stopping and recovery require review for the selected hardware and installation. The operator should have a clear indication of whether the cell is ready, running, paused or awaiting intervention.

A qualification dataset to collect

Proposed sampling plan, not completed production data
Test dimensionPlanning value
Representative part variants4
Pickup orientations per variant3
Repetitions per combination10
Planned handling attempts4 × 3 × 10 = 120
Cycle-time boundariesPickup ready → inspection handoff complete

For every attempt, record the part variant, orientation, transfer result, inspection handoff, elapsed time and any recovery action. Separate robot movement time from waiting for a fixture or operator. Production capacity cannot be inferred from a single fast movement, and successful transfers should not conceal damage, incorrect orientation or failed inspection handoffs.

The decision after testing

Review the distribution of cycle times and the reasons for failed or interrupted attempts. A recurring alignment issue may call for better fixturing rather than faster robot motion. A gripper change may improve retention while reducing access to the inspection area. Record these tradeoffs, repeat the affected tests and agree acceptance criteria before extending the trial.

The resulting decision should describe the validated part range, operating conditions, supervision and maintenance requirements. Cost and payback estimates belong after those facts are known. A well-documented cell can then support operator training, controlled changes and a defensible decision about whether to scale the application.

YOUR APPLICATION / THE NEXT STUDY

Start with the task.
Build the evidence together.

Share your site layout, operating window, product requirements and current process. HRL can discuss a practical evaluation scope, the data to collect and the conditions that would support a deployment decision.

Discuss an application ↗
AI ChatBot