Robotics Engineer

Remote · Fixed price, milestone-based · Hardware access provided

We are building a mobile manipulator that opens electrical panel doors autonomously. We need one engineer to take it from nothing to a working proof of concept: the robot drives a tool into a recessed slide latch, releases it, and swings the door open, with no human intervention.

The bar is a single number — 16 successful opens out of 20 consecutive attempts, under fixed conditions, witnessed.

This is a short, sharply scoped engagement with a clear definition of done and a real possibility of follow-on work. It is hands-on hardware robotics, not a research position.

A Robot (details to be given about the brand) starts from a fixed position facing an electrical panel. On one command, it must:

1. Detect an ArUco marker on the panel and compute the latch pose from a surveyed offset
2. Move to a standoff on the panel normal, aligned to the latch
3. Drive a tool into a recessed slide latch roughly 16 × 10 mm, about 3 mm deep
4. Translate the latch along its axis to release it
5. Confirm release visually — not by assuming the motion worked
6. Pull the door open to at least 45 degrees
7. Retract, and report success or a typed failure code

The interesting problems are physical, not algorithmic. Whether the tool can reliably seat in a shallow recess given your pose accuracy. Whether the omnidirectional base holds position while providing slide motion, or creeps. Whether a flush door with no lip can be pulled open at all.

The latch needs roughly 5 N. The robot has no wrist force/torque sensor. Insertion tolerance is on the order of ±2 mm. Those three facts shape most of the engineering.

In scope: a linear motion sequence with an ArUco-based pose estimate, visual verification, typed failure reporting, all parameters externalized to a config file, and a written findings report covering what you measured.

Explicitly out of scope. These are cost reductions, not oversights. Work spent on them does not count toward acceptance:

Excluded

Instead

Markerless perception

ArUco tag at a surveyed offset

Multiple panel models

One panel, one physical unit

Variable lighting

Fixed work light

Simulation environment

Direct hardware development

Behavior trees, recovery branches

Linear script, abort on any failure

Reinforcement learning, imitation learning, any policy training

Scripted motion

Navigation to the panel

Fixed, marked start position

Test coverage targets, CI

Smoke test only

If you think one of these exclusions cannot hold, say so in your application. We would rather hear it now.

Safety boundary, non-negotiable: the robot operates only on the hinged inner door. It never touches the perimeter screws or the dead front, and the software must actively prevent entering a defined keep-out volume rather than merely not planning into it.

• Real hardware manipulation experience. You have made a robot arm reliably do a physical task, and you have the success rates to prove it. Simulation-only experience is not enough for this role.
• Python and ROS 2. Comfortable with actions, TF2, and the usual debugging.
• Rigid-body transforms. Composing frames, inverting them, and reasoning about error propagation through a chain without hand-waving.
• Camera calibration, including hand-eye, done properly with residual error reported.
• Fiducial markers — ArUco or AprilTag — and an understanding of where their pose estimates are weakest.
• The instinct to measure before claiming. You report what you observed, including when it disagrees with what you hoped.
• Safe hardware practice, especially operating a robot remotely with someone else standing next to it.

• Mechanical design and 3D printing. You will specify the end-effector geometry you need; we fabricate it. Being able to sketch what you want speeds that up considerably.
• Visual servoing.
• Experience with compliant or underactuated grippers.
• Contact-rich assembly or insertion tasks in an industrial setting.

Specific experience is not required, and few people have it. General manipulation experience transfers. What doesn't transfer is overstating it—if you list it, expect one specific question about the platform's kinematics.