Software and architecture
Robot systems from prototype to production. Drivers, nodes, lifecycle, and the boundaries that keep parts replaceable. The unglamorous plumbing that decides whether a robot ships.
Freelance robotics engineering · Antwerp, Belgium
Quincy Roco
Cut your robotisation cost.
We design and build robot software that can talk to the world and scales without locking you into one vendor's stack.
Services
Collaborative motion
Arms, cobots and mobile platforms that share their space with people, with machines, with each other. Planning, control and the perception needed to move safely among them.
Vendor-agnostic integration
The right robot for the job, working with what you already own — not with what one vendor happens to sell.
15+ years of robotics
Experience gained from PhD-level research labs to highly automated industrial environments.
Most robot software dies of tangling.
The algorithm knows about the network. The network knows about the schedule. Change one and you rewrite three. The second robot costs what the first one did. We build the other way.
- 01Keep the parts ignorantWhat a component works out shouldn't know how the data reached it, or when it's allowed to run. Those are three different questions and they belong in three different places.
- 02Assemble, don't editAdding a sensor, a cell or a robot should mean composing parts you already have — not opening them up and threading a new case through.
- 03Magic numbers live outsideEvery threshold, timeout and frame lives where an engineer on the floor can tune it. Not buried three files deep behind a rebuild.
- 04Design for the second robotThe first one always works, eventually. Architecture is the thing you're actually buying for the second, the tenth, and the variant nobody mentioned in the kickoff.
None of this is exotic. It's just the difference between a demo and a product, and it's most of what we get hired for.
Working together
How this works.
- Shape of the work
- Ongoing capacity on a team that's short a robotics engineer, a bounded project with a deliverable, or a second opinion on an architecture before you commit to it.
- How it starts
- A conversation, then one bounded piece of real work. You should be able to judge the fit from something running, not from a proposal.
- How we plug in
- Remote, or on-site in Belgium and the Netherlands. Inside your repo, your review process, your standups — not a parallel track that arrives later as a handover.
- What you keep
- Documented as we go, handed over as we leave. If your team can't carry it without us, the job isn't finished.
Let's talk about your robot.
Tell us what you're building and where it's stuck. If we're not the right fit we'll say so quickly, and we usually know who is.