Egocentric Patient Mobility Assistance Data

Egocentric patient mobility assistance data is first-person video of a person helping another person move, or steadying the equipment that helps them move, recorded to a written spec so that a robot learning system can see how the work is done. It is recorded from the operator viewpoint with depth, 3D hand pose, contact events and frame-accurate action segments aligned on one hardware clock. The same request is sometimes phrased as care robot mobility assistance training data, a mobility aid handover video dataset, egocentric caregiver mobility support data or custom care task data collection. They describe one job from different angles: write down the task, collect it on demand, and receive validated episodes with the labels a training pipeline expects.

The data is human capture. A paid, consented contributor performs the task while a rig records it. It is not robot or teleoperation data, it is not simulation data, and it is not a fixed corpus you download. This page is narrower than the elder care and assisted living page, which covers five different nursing home rows and treats resident mobility assistance as one of them, and narrower than the hospital and clinical care page. Its subject is the five catalog rows that describe mobility assistance or the handover of a mobility aid, drawn from three environments.

It is also not clinical data. The site states no diagnosis, assessment, treatment plan, outcome measure or medical record for any of these rows, and it does not state that any real person’s health information is captured. This page describes what is collected for robot training, not how to move or care for a person, and nothing here should be read as patient-handling guidance.

The site’s commercial task catalog has five rows that describe mobility assistance. The first table below reproduces them as the catalog states them. Four are rated Medium and one, Hand over mobility aid, is rated Easy. All five are Available on request, which the site defines as scoped and recruited to spec when a buyer asks for it, rather than already set up and recording.

The rows are "Hand over mobility aid" (Position and steady a mobility aid.), "Resident mobility assistance" (Support a resident standing, transferring to a chair or walking with a frame.), "Mobility support" (Help a patient stand, walk with aids and transfer between bed, chair and equipment.), "Balance training" (Set up balance boards and supports and guide a patient through balance exercises.) and "Assisted stretching" (Guide a patient’s limb through a stretch, holding and supporting the joint through the range.). This page quotes them and says no more. The catalog does not say what the aids are, how long a task runs or what counts as a completed step.

Assisted stretching is a mobility-adjacent row rather than a standing or walking row. It is included because it sits in the same physiotherapy environment and describes supporting a limb through a range. Where the catalog has no row, this page says so instead of implying coverage. The second table sorts the work into kinds and marks the gaps, including wheelchair use, patient lifting and gait work, for which no row is listed.

The five rows sit in three environments of the Healthcare & Life Sciences sector. "Hand over mobility aid" is in Care Room (assistive care), whose examples read "Care room: bed, tray table, linens, participant or mannequin". "Resident mobility assistance" is in Nursing Home & Assisted Living. "Mobility support", "Balance training" and "Assisted stretching" are in Physiotherapy & Rehabilitation Clinic, whose examples read "Physiotherapy clinic, rehabilitation center, sports medicine facility -- assisted stretching, therapeutic exercise, mobility support, balance training, and rehabilitation equipment operation".

The environments differ in how they are captured. The Care Room row lists the capture setup "Multiview rig + handheld grippers", which the site describes as a staged working set recorded by a multiview rig while the operator performs the task with handheld grippers, so demonstrations map onto a robot end effector. The other four rows list "Phone (head-mounted) / multiview rig". The catalog does not say which of those two options applies to a given collection, so that is settled in the spec.

The physiotherapy environment has two further rows, "Rehabilitation equipment operation" and "Therapeutic exercise guidance", which this page does not count. They are not described as mobility assistance in the catalog, and counting them would claim more than the rows say. A buyer who wants them would ask for them in a separate spec.

The site’s general capture statement lists a head-mounted global-shutter 4K/60 camera with a 120° lens, two wrist-mounted 1080p/60 cameras, an active-stereo depth sensor at 848×480 and 30 fps, and 200 Hz 6-DoF IMUs, all hardware-triggered onto one PTP clock domain. It describes ten synchronized streams aligned under 2 ms. Which of those streams a mobility program carries is Not stated for these rows, because the rows list a multiview rig or a head-mounted phone mode rather than the full rig, and it is agreed in the spec.

For the head-mounted phone mode, the site describes the first-person view of real work on site. For care settings that has to be read together with the simulated-patient boundary described below, so this page does not claim work with real patients or residents. The multiview mode adds a second viewpoint of the same scene, which matters when two bodies and one aid share the frame.

Force and tactile readings are not among the standard streams; standard capture is cameras, depth and IMU. A separate glove tier records a tactile glove signal beside the video, time-synced to a head-mounted stereo camera by hardware timestamps and an IMU, with each glove calibrated every session. The site does not state that the glove tier has been used on mobility assistance, and it states no force, load or support measurement for these rows. Whether it fits a mobility program is agreed with us before you rely on it.

Mobility assistance is close, shared and continuous. The assistant’s hands sit on a frame, a belt, a limb or a chair back, the person being assisted often covers them, and the movement unfolds over seconds rather than at a single contact point. That is why 3D hand pose carries a per-joint visibility flag, why contact events mark when a hand meets an item, and why instance masks are recorded per frame. The challenge table maps each difficulty to the stream or label the site already states, or says Not stated.

Step boundaries are a second issue. Standing, turning and sitting blend into one another, so a spec has to say where one step ends and the next begins. The site’s action segments carry start_ns, end_ns, verb and noun, aligned to every other stream, and a spec can define one segment as one stand, one transfer or one balance exercise. The site does not state a standard segmentation for these rows, so the definition comes from your spec.

The third issue is what video cannot show. A clip does not show how much weight is being supported or how stable a stance is, and the site states no support, load or stability label for these rows. This page does not claim that a model trained on such footage would assist anyone safely or correctly. It describes what is recorded, not what a robot trained on it can do.

Each attempt at a task is delivered as one episode. The site’s episode schema lists action segments, contact events, 3D hand pose for both hands with a per-joint visibility flag and instance masks, alongside int64 nanosecond timestamps per stream and camera intrinsics and extrinsics. Hand pose is stated as 21 joints per hand, in 3D, in metres in the head-camera frame. The site’s only language data is one task instruction per episode, so this page promises no captions or narration.

Validation runs against accept criteria written into the spec before capture. A reject log ships with each batch. The site states these reject thresholds: a cross-stream sync error above a 2.0 ms ceiling, the manipulated object out of frame for more than 15 percent of the episode, and more than 35 percent invalid depth pixels in the manipulation region. On custom collection engagements, rejected items are recaptured at the provider’s cost, and delivery is billed per validated hour. These are reject thresholds, not a stated pass rate.

Delivery is in RLDS, LeRobot, WebDataset, HDF5, zarr or Rerun .rrd, with converters shipped as readable source so you can retarget the schema to your own loader. The license is perpetual, irrevocable and buyer-owned, non-exclusive by default, with exclusivity available as a separate term; the executed agreement controls. Whether a mobility delivery carries robot action data is Not stated; the site describes human-side capture only.

A buyer evaluating care data usually wants numbers and assurances, so it is worth being direct about which ones are missing. For these five rows the site states no patient-handling technique, no clinical outcome, no fall-prevention or rehabilitation effect, no medical-device status, no support or load figure, no cycle time, no episode or hour count, no number of sites and no region. It lists no success, stability or safe-transfer label, and it states no safety practice, standard or certification. It names no mobility-aid or robot brand, and this page reports no benchmark or robot result.

None of that makes the rows unusable. It means the specifics are set per program. You write the aids, the steps, what counts as a finished step and the variation cases into the spec, and the batch is judged against those terms. The last table on this page lists what is delivered and what is not stated, so you can see the boundary in one place.

The site states that capture in healthcare settings happens only in training environments with simulated patients, and that real patient footage is never captured, under any circumstance, regardless of what a spec requests. The Care Room examples add that a participant or a mannequin may be in the scene, and the site does not say which is used for a given row. Who stands in for the person being assisted, and how that person is consented, is settled in the written spec before capture begins.

Every contributor signs a written release granting commercial training rights before capture begins, and is paid a published hourly rate rather than a per-task bounty. Faces, plates and screens are detected and irreversibly blurred at ingest, and a reviewer confirms the result before anything ships. The site states that an un-consented person who is identifiable in a frame means the footage is de-identified or discarded. The anonymization record ships with the data.

The site does not state that any real patient’s health information is captured, and this page does not claim it. It names no facility or provider, and it states no safety practice, protective equipment, standard or certification for these environments.

From signed spec to first validated batch, the published timeline is a median of 48 hours in environments where coverage is already deep, and three to four weeks where coverage is thin and contributors need to be vetted and recruited first. All five mobility rows are Available on request, so they are scoped and recruited to spec when asked for. The site does not say whether these environments count as deep or thin coverage, so which range applies is confirmed when your spec is quoted rather than assumed. A spec conversation happens the same week, and a tight spec is the quickest route to a fast, on-demand dataset.

Describe the assistance steps and their order, the aids involved, who plays which part, what counts as a finished step and the variation cases your pipeline is missing. That becomes a written skill spec, quoted for reach, timeline and price before any capture begins. Most programs begin with a Spec Pilot, a small, fast first batch that proves the spec and the accept criteria on real footage before volume scales. Collections are billed per validated hour.