Computer Vision Engineer (Robotics)

Computer Vision Engineer (Robotics)

One to two months · temporary · hybrid, 2–3 days on-site

Hybrid: Houston, Texas

Great opportunity to learn with some possiblity of becomign full time

FacilityOps AI

We build a mobile inspection robot for critical facilities — electrical rooms, cooling plant, and the equipment a data centre cannot afford to have fail. The robot drives a defined route, captures thermal and visual evidence from the same position on every visit, and produces a record of what it found that someone else can verify afterwards.

One robot is deployed and running at a customer site. We are a small team, so what you build gets used rather than shelved.

We are hiring a computer vision engineer with real robotics experience for a one-month engagement, building perception features on the robot.

Your work lands in three places at once. It makes the physical demonstration rig we take to customer meetings do what we say it does. It improves what the robot can see at the site where it is already deployed. And it extends the inspection capability we are building out across the categories of equipment a facility contains. Most features contribute to all three, which is unusual and is part of what makes the month worthwhile.

We will agree the specific scope with you before you start, so you arrive ready to work rather than spending the first week deciding.

The remote half is model work, evaluation and code. The on-site half cannot be done anywhere else.

Our demonstration rig is a controlled test bench: a mock electrical panel and cooling section where a fault can be staged in about thirty seconds, the lighting never changes, and the geometry stays fixed. You can create the same awkward case repeatedly and drive the robot over it as many times as you need. That is an evaluation environment a live facility cannot give you, and collecting from it is hands-on work.

Two to three days a week on-site, the rest remote. In practice those days cluster around data collection and hardware verification rather than spreading evenly across the week.

Approximate split: 40% looking at captures and building evaluation, 35% writing code, 15% on the rig and the robot collecting data, 10% documenting.

The first figure is not a mistake, and it is the part most people underestimate. Understanding what is actually in the captures comes before building anything against them.

• Staging cases on the rig, driving the robot over them, and collecting captures.
• Building the evaluation set from those captures before any model work begins.
• Getting a baseline running end to end on real data, however rough.
• Deliberately breaking it — bad angles, glare, dust, partial occlusion, poor standoff.
• Setting the confidence threshold and the withholding behaviour: the point at which the system reports that it could not read something rather than returning a number.
• Verifying against captures from the live site, which are consistently messier than the rig.
• Writing it up so the team can run and extend it without you.

One month is not long enough to learn the toolkit and use it, so these need to be in place on day one.

• Computer vision, applied. Strong Python, OpenCV, and PyTorch or an equivalent framework. Geometric transforms, image operations and camera calibration should be familiar ground.
• Robotics, hands-on. ROS 2 — nodes, topics and transforms. Coordinate frames between a mobile base, an arm and a camera, and why they drift. Experience with a real robot, not only in simulation.
• Sensor reality. Working with lidar, stereo depth or thermal data, and comfort with hardware that does not behave the way the datasheet suggests.
• Evaluation discipline. Building a test set before a model, reporting accuracy honestly, and being specific about where and why something fails.
• Independence. Supervision is light. This is a delivery engagement, not a training one.
• On-site availability. Two to three days a week in person. The data collection cannot be done remotely.

None of these are filters. Take them as an indication of where the work goes, and tell us which you have.

• Calibration between a sensor and a manipulator — hand-eye, or anything equivalent.
• Pose estimation from fiducial markers such as AprilTags.
• OCR, or classical approaches to reading analogue instruments.
• Vision-language models used in practice rather than read about.
• Radiometric thermal imaging and emissivity.
• Point cloud tooling — Open3D, PCL or similar.
• Teleoperation, or any work where a person and a robot shared control of a task.
• Confidence calibration — turning a model score into something that means what it says.

The deliverable is not accuracy. It is calibrated accuracy.

Something that is right 95% of the time and knows which 5% it got wrong is worth more to us than something right 98% of the time and confident throughout. The robot produces evidence that customers make maintenance decisions from, and a confident wrong answer is worse than no answer at all. If that reads as obvious to you, we should talk.

• Not agent or language-model application work. This is perception — images, depth, and the geometry between them.
• You will not design safety limits or decide how the robot behaves near energised equipment. That sits with our engineering lead.
• You will not visit the customer facility. You work on captures from it, and on the rig and robot in our own space.
• No work on live or energised electrical equipment. The rig is low voltage by design.

Duration

One to two months, full time, fixed term

Extension

Possible if it suits both sides

Working pattern

Hybrid — two to three days a week on-site, the rest remote

Rate

Competitive, agreed at offer

Scope

Agreed before your start date

Reporting to

Engineering lead

Start

Flexible

Conditions

A confidentiality agreement and IP assignment are signed before the first day. You will be working with imagery from a live customer facility.

Handover is a deliverable. The final week includes writing the work up so the team can run and extend it. A month of good work nobody can pick up afterwards is a month wasted, and we would rather have a narrower result that is documented and reproducible.

Send a CV and a short note on one thing you have built where the real data was messier than expected, and what you did about it. Links to code are more useful than a long cover lette